The Bloated Backlog
Let me describe a situation that almost every product manager has run into at least once:
You’ve just started a new job as a Product Manager and you’ll be responsible for the success of one of the more mature products while the more senior Product Manager you’re replacing moves on to a new project that’s high risk and requires some experienced management. You’re excited to get going and start making an impact in the company and on the product that you’ve just been given.
But this mature product comes with some baggage. Customers have been using it for several years, and it's amassed a giant backlog of hundreds of improvements, bugs and feature requests that would take your team three years to build (assuming you’d want to build them all)! Perhaps it's sitting in Jira, Trello, or ProdPad. You’re feeling overwhelmed. Where do you start? You don’t even know what many of the feature requests mean, let alone their value! What do you do?
I’ve experienced this painful situation on more than one occasion, at more than one company I’ve worked at. This is what I do:
Put the old backlog on ice. Stop using it. Leave it where it is, but don’t remove or delete it. You’ll draw from it over the next few weeks.
Start a new backlog. Put it in a place that’s easily accessible by your stakeholders. It might be right beside the old one. Set it up properly, with the information and requirements that will ensure its actually used and contains useful information. Use this as an opportunity to improve the backlog. Consult your stakeholders to understand what is most important to them in a product backlog. Ensure each backlog item has a problem statement, a set of requirements or acceptance criteria, relevant stakeholders, business value, effort estimation, etc. Take a look at other tools that could work better than the old backlog. I prefer physical cards on a whiteboard.
Populate the new backlog. Be careful with this step. You want the new backlog to be filled with a small list of the highest priority items only. This usually means 5 to 10 things at most. Enough to keep your team(s) busy for 2 or 3 sprints. Do not bulk-import anything. Manually create each backlog item. Work with your stakeholders to identify the highest priority items. You can use the old backlog as inspiration.
One exercise I like to do is print or write each item from the old backlog onto a card and put them all up on a board. Then ask your stakeholders to stop by and identify the most important ones. If you can’t get consensus this way you’ll have to get your key stakeholders (the one’s who have veto power) into a room together and get them to come to an agreement on the top 5–10 items.
Archive the old backlog. Your main goal here is to get the old backlog out of sight from your stakeholders, not because you want them to forget about all their old feature requests, but because you want them to stop using the old backlog and start relying on the new one. Ensure you keep a record of the old backlog. There’s probably a lot of useful information in there that you may need to refer back to at a later time. Let your stakeholders know that they can still access the old backlog if they need to.
I predict you’ll be pleasantly surprised to find that most of the items on the old backlog weren’t that valuable. That’s why they were sitting in the backlog and weren’t built yet.
And that’s it! You now have a new, manageable backlog, that only contains the most important items, and full of items that you actually understand because you went through Step 3 above. Onward and upward!
“Over time, no one will miss your old backlog.”
- Over time, no one will miss your old backlog (assuming you’ve consulted your stakeholders properly while implementing this). I have yet to see a group of stakeholders (including developers) that severely missed the items contained in an old, multi-hundred-long backlog that I’ve archived. Most of the information in it is not that important. And if it was it’ll come up again.
- You can also use this process on an ongoing basis to clean up a backlog on a product that you’ve been managing for a while. It achieves the same results. I’ve done it!
- Try to use physical cards on a board first. Only once you’ve mastered this and it becomes too painful to manage in this manner should you look at an electronic solution to manage your backlog.