Being a mentor of a lot of startups provided me some insights on how, in general, software teams manage their development process. And almost every startup I know of, at some point in time, struggled to manage its priorities and its backlog. It was supposed to be straight-forward, but it demands a lot of discipline and focused execution in order to get it done right.
One common challenge engineering teams face is to harmonize different (and sometimes conflicting) demands of varying stakeholders. Another one is to balance the energy in developing new features, fixing bugs and paying the technical debt.
So, in this post, I will be talking about some strategies I have successfully used in the past to address this issue.
Have one single backlog per team
Even if you have different categories (like bugs, features, customer tickets, etc), having everything in one single backlog board helps everyone to understand what is being done (and what will/would come next).
In the case you have a “new” issue stepping in all of sudden, having one single backlog helps the team to see what will be affected, so they can communicate the changes properly.
Having one backlog will force you to put in place the meetings necessary to properly manage it. In one of the companies I worked at, after converging all issues to one single backlog board, we started to have weekly meetings with all the groups demanding engineering activities.
If you have different teams serving different organizations (one serving the marketing group, another one serving the sales group, etc), you should have one backlog per team.
My point here concerns the most constrained resource. In most cases it is the team. Most of the startups I know of are understaffed, so there's where you should aim to optimize for.
Have it as visible as possible
Visualization is most of the time downplayed in engineering teams. If your to-do list and your backlog is visible for everyone to see, people start to ask why A is more important than B, and the stakeholders start to understand how their demands impact the other ones and how it affects the overall output.
Another reason to have it visible is to avoid people stopping by just to follow-up. Once it’s available for everyone to see, there is no reason to people stop by to ask. It is visible already.
That is not mere chance that one of Kanban’s pillar is visibility. It may have a huge impact on your operation.
And remember, although it’s fine to have in on Trello or any other tool, in my experience, nothing is more simple and useful than the good and old post-it.
Keep it always prioritized.
This is key. Your backlog has to be prioritized and in absolute terms. What does it mean? Well, it means that, ideally, there will be no 2 activities with the same priority. It also means that is crystal clear to everyone that, for instance, activities demanded by the marketing campaign have a lower priority than the activities demanded by the legal team.
Prioritization is one of the main reasons for project conflict and stress, and I strongly believe sooner you deal with it, and as transparent as possible, the sooner the stress and the conflicts are resolved, and the people start to focus on what matters.
There are a lot of techniques to prioritize stuff. Some people think the best approach is to put some business value in every single activity. Activities that adds value when done, are positive (here are new stories, UX enhancements, etc); activities that subtract value when not done, are negative (here are bugs fixes, technical debts, customer tickets). Another technique used is to have each sprint themed, and thus, some sprints will be themed with bug-fixes or housekeeping themes. Another approach is the MoSCoW technique. These are 3 approaches I have already (successfully) used, but if you googled it, you will find a lot more.
Have someone in the team as “backlog” owner.
Whenever you want anything to be taken care of, you get it an owner. So, here is no different. If you are using Scrum, this is the PO job. If you are not using Scrum, you have to have someone taking care of the backlog. In my experience, when not using Scrum, this is the job of the head of engineering or the Project Management organization. As we are talking about startups, most probably you have no Project Management Organization in place, and it ends up being the responsibility of the head of engineering (as it happened to me in the past).
This one person is the only one with power to change the backlog. In case one of your stakeholders need to chance something, this guy is the one to be informed about it. If the team needs to change something urgently, this guy is the one responsible for assembling all the stakeholders together and communicating with them.
One common mistake is to have more than 1 owner. Sometimes you have 2 owners (the “stories backlog” owner and the “bugs backlog” owner or the “customer tickets” backlog owner). Don`t fool yourself. If you have 2 owners, you have no owner at all. People will do what seems fit for them, or will prioritize the activities of the owner who shouts louder.
Besides, having one single person in charge helps the process to get disciplined and (usually) more simple.
Communicate as often as possible with the stakeholders
Engineering groups sometimes are weird. Software engineers sometimes don’t like to talk to non-engineers type, and sometimes they have a very different thinking method — I worked with a bright developer, whose mind worked in a kind of fuzzy logic. This simple weirdness makes communication critical to the success of any engineering group.
How to do it? I believe in the power of the ceremonies, and in this case, I strongly believe you have to have the proper meetings in place for such communication. It’s not about how, when and how often YOU want to talk to them, but the opposite. It’s about how structured is the process for them to talk to your team. The key point here is figuring out what makes sense for each one of the stakeholders which need information from your team.
Some stakeholders will prefer to have a formal status report meeting, weekly or bi-weekly. Other will just want daily, informal emails. And others will be satisfied with the regular chats in the corridors. But remember, the communication is mostly for them. They can not be left in the dark regarding the progress of your team. They are your friend, not your enemies.
Be as transparent as possible.
Is something not working? Is your team late on schedule? Is the software crashing? Don’t hide it. Explain in plain English what is going one, and what is your plan to get it fixed. Transparency builds trust.
When? Well, I soon as you know it happened. Follow up and keep the people informed about the results of the action plan you did to solve the problem. In some sense, besides being in charge of the process, you need to show the stakeholders that you are in charge. This builds credibility and confidence in your team.
Keep the backlog always updated.
Nothing is more frustrating than have a lot of post-its notes on a wall, just to see they are not updated. Ideally, each “done” activity needs to be updated in the backlog as soon as it is done. Every “new” activity needs to be updated as well. If the board/backlog is not updated with the current progress of the team, the tips above makes no sense.
Who is responsible for getting the backlog updated? Well, again it depends on what software methodology you are using, but a good practice is to have the person finishing the activity being the one responsible for updating the backlog board. In case you have on “backlog owner”, this person can be the one in charge for having it updated as well.
Balancing Features, Bug Fixes, and Debts
Another common issue many teams face are about balancing the energy on new features, bug fixes, customer tickets and paying technical debt. Here, there are no recipes or bullet-prove tips. Depending on the moment your product is, it might be wise to focus more on tech debt, or bug fix, but if you are still discovering your MPV, maybe it is better to go a little bit faster, not worrying too much about your non-critical bugs. Samantha Laing has a good article about it (also about prioritization).
Well, I believe with the above tips, it may be easier for you to manage your team’s backlog.