You are using an outdated browser. Please upgrade your browser to improve your experience
Posted By - Geoff Watts
Good product owners know what is needed.
Great product owners know what can wait.
Once upon a time a product owner asked me how many items I recommend he had on his product backlog. Naturally I answered with “It depends” but I followed that up with “How many items do you have at the moment?” to which he responded “About 3,000”.
Now I was taken aback by this because it wasn’t a huge product at all; it was simply an internal trading system but perhaps my instinctive response was unwarranted so I enquired further. “About how many product backlog items does the team manage to complete in a typical sprint?”
“Around 20-30. I think we got 40 once” he replied.
“OK…so so quick maths says that this is about 100 sprints worth of work…provided nothing new ever gets added. While there’s no real rule, it feels like at least some of that stuff has a good chance of never getting done and you have to maintain that forever, for no value.”
It turned out he felt the same but felt he needed some kind of validation or permission to start culling the product backlog.
Like I said, there’s no rule that says you have to keep your product backlog to a certain number of items but there are some potential benefits to doing so.
The more items there are the harder it is to work with. It’s harder to find stuff, it takes longer to prioritise, re-prioritise and estimate, and it becomes quite an ominous, imposing and demotivating presence for the product owner and the team.
It’s also a slippery slope. The bigger it gets, the faster it becomes even bigger. It’s much harder to find overlap, it’s easier to accidentally create duplicates and what’s the harm in adding just one more item when there are already 2,999 in there?!
Another benefit to culling the product backlog is to kill hope. Now that might sound strange but so long as something is in the product backlog, someone is living in hope that it will get delivered. They are probably wasting their time lobbying for higher priority, checking in on progress, when in reality there’s no hope it will ever get done. Free that person up from false hope and just tell it like it is.
So if you want to cull the backlog but you’re not sure where to start I have seven tips to help you slash your product backlog into a manageable state.
I’ve worked with a lot of product owners who have just decided to delete 50% of their product backlog because it had become obvious that it was never all going to get done. They figured that if it was really important then someone would shout about it pretty soon. So, in reality, they didn’t actually *delete* them, they just archived them off to a separate list somewhere.
On this note, Mike Cohn recommends having a “Holding Tank” for things that you’re not quite ready to work on but don’t want to lose.
“I think of the difference like this: The product backlog contains all the things the product owner wants and can answer questions about right now. The holding tank contains things the product owner probably wants but either hasn’t thought through in enough detail or may decide aren’t needed after all.” link
One good way to make the Product Backlog more manageable is to filter it according to the sprint or release goal and only show the items relevant to that goal. Move everything else to the Holding Tank.
If you have some empirical data of working with the team then you might be able to use that to only show an “achievable” amount. Say the team, on average, deliver 40 points per sprint then maybe only show the most important 160 points worth of Product Backlog and move the rest to the Holding Tank.
Once you’ve done the big cull, make sure you don’t let it get into that state again. It’s good practice to establish a ritual for refining (or grooming) the product backlog. Set aside a certain time every week to go through and delete a few obsolete items, look for opportunities to merge them or…coming on to tip 6
If you’ve got a number of small but related items sitting around near the bottom of the product backlog consider grouping them together into an “Epic”. The same amount of work is there in fewer items so it’s tidier. Obviously should you come to work on that epic you automatically have a way of splitting it into smaller achievable chunks of value.
Depending on your tool of choice, you could use data to identify the ones most appropriate to archive off. If they haven’t been updated or asked about in x weeks then they are automatically up for archiving. Just set up an automated rule looking at Date Last Accessed or something and time them out.
Great product owners know that it’s easy to just “put it on the product backlog” and can justify it to themselves that we don’t want to forget or lose any ideas about how to make the product better. Great product owners don’t take the easy option and are ruthlessly focussed on what is right for the product.
If you want to become a great product owner, check out our Product Mastery Pathway.