Tips For a Healthy Backlog in 2018
It’s 2018, many of us have new year’s resolutions to start being healthier. Maybe we should start with our backlogs
Before beginning any type of development process, you need a backlog. Without a backlog you have no plan. You might not need a rock solid plan for the entire year, but you need an idea of where we are going to keep moving on toward your product vision.
Backlogs are hard
There are two common problems I see the most often for backlogs. The first is that backlogs are too large. The team has work that hangs around for years that they are never going to get to. Another issue with too much work on the backlog is wasted time. The team has spent so much time reviewing work for development that they are never going to get to.
The second common problem is that the backlog is sparse and there isn’t enough to keep the team busy. This causes the team to become reactive each week rushing to try and get work ready. Often times items that the team starts to work on are not actually ready for development.
Two main issues:
- Backlogs are too big
- Backlogs are too sparse
Our goal is to have a backlog that can be used by our team to clearly see what is coming up, what is ready, and what we have planned for the future. We don’t want to be reactive rushing around to find work we want to do, and we also we don’t want to waste extra effort on refining items we are never going to get around to. We want to get our backlog in a healthy state.
What does a healthy backlog look like?
- A healthy backlog (for a team of 5–9) has less than 100 items
- The items are less than 9 month old
- There are 1–2 months of work ready to go for the team to work on
- Includes tech debt, bugs, and new feature work
But like most of us and our health, we are not hitting the gym each morning, eating clean 24/7, and getting regular exercise with outdoor activities. To those that are, more props to you and I’ll drink a beer after work to your health.
How can you start to clear the clutter or ramp up your backlog? Check out a few tips below.
Close out old tickets
If tickets are 6 months or older you are probably not going to get to them. Set a reminder to delete everything that is 9 months old, or even a year old. If it’s important, it will come back around again. I recommend this for bugs as well if you’ve only had one issue reported in 6–9 months and you haven’t resolved it. If it’s important it will come around again and it can be linked the old closed ticket and the team can address it in a appropriate manner if they decide to.
Organize in a way that works for you
Epics or Themes — You can use epics to group related tickets depending on the software you are using. Do not use an epic as a label, it is a larger feature that should close at some point.
Labels — I use them for smaller labels to sort types of work like “techdebt” or “us-debt”, but you can use them as you see fit with your team.
Color code — Being a very visual person I like to be able to look at a backlog and see how many bugs vs tech debt and story work you have at a glance.
Ready for Dev — If you don’t have a status to denote ready for dev or work that is ready for the team to work on it I would use a label and then a color code, but beside that, you should have a way to decipher which work on the board is ready for development and which work still needs to be refined.
Put Check Points In Place
- If you aren’t reserving time on a weekly or bi-weekly basis to review the backlog start putting in a half hour here or there, or even an hour to review the backlog with your team.
- Once it starts to get over 100 set up some time to review the backlog starting with the oldest first and close out appropriate tickets that the team doesn’t think they’ll ever actually tackle.
- Don’t forget about tech debt. Tech debt should be prioritized like any other work. If tech debt makes up 50% or more of your ready for development backlog, and you are not a tech focused or maintenance team, you should work with your PM on upcoming product goals to work on beefing up your business value delivered.
A Spoonful of Reality
It sounds easy enough to do all of this, but what if your team has a unique situation that causes managing the backlog to be quite difficult? All hope is not lost, however it might take a little more work.
Many common issues I see with product backlogs relate to how the team interacts, or doesn’t interact with the product owner. One of these might be just what your team is dealing with.
- Product owner doesn’t have a strong vision
- There’s not a product owner
- Too many product owners
To learn more about how these scenarios can effect teams, and how to work them, check out my article on Product Owner Backlog Blues.
Backlogs are important, but not always easy. I hope that a few of these tips may come in handy for you and your situation, but of course it would be great to hear recommendations from others of how they address backlog concerns or problems that have risen with their backlogs. Please comment below.