You should always strive to keep your product backlog small and manageable. With too many items on the product backlog, three problems arise:
First, it is harder to work with an excessively large product backlog. Time will be lost looking for items. (“I know it’s in here somewhere.”) Prioritizing the backlog will take longer. Duplicate items will appear as it will be easier to add an item “just in case” rather than be sure it’s not already listed.
Second, the development team barely notices any progress they make. A team that finishes 10 of 50 product backlog items can sense that they’ve made progress. A team that finishes the same 10 but out of 1,000 items will not feel the same sense of accomplishment. They will begin to wonder if it would matter if they had only gotten 9 done instead.
Third, someone spent valuable time creating all those product backlog items. Having visibility into the future a bit is great. How far depends on a lot of factors but many backlogs attempt to provide insight too far into their products’ futures.
Because these problems of an overly large product backlog can be so harmful, I’d like to present four things you can do to keep your product backlog to a more manageable size.
Delete Things You’ll Never Do
The first thing you should do to keep your product backlog small and manageable is delete items you’ll never do.
I fully acknowledge this can be hard to do. For years, I worried that if I deleted things, I’d walk into the office one day and my team would say, “We’re caught up. What next?” and I wouldn’t have an answer because I’d deleted all the long-term items.
I was finally able to let this fear go by realizing: I can come up with new ideas faster than they can develop them.
I encourage being fairly ruthless in purging items from your product backlog. If you don’t think you’ll realistically ever do it, just get rid of it.
Otherwise, a product backlog just accumulates more and more over time. That task of “learn to dance the Macarena” that’s been on my personal backlog since 1995 just got deleted. By this point, it’s not happening.
Keep Items You Aren’t Ready for Off the Product Backlog
For a handful of years, I’ve had a lot of success keeping product backlogs manageable by maintaining a separate list of items that the product owner wants but isn’t truly ready to have the team work on.
I refer to this as a holding tank. A holding tank allows me to restrict the product backlog to items that are desired immediately. The holding tank contains items that are either not quite ready or may not be needed after all.
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.
I’ve found this approach extremely helpful because it leads to an immediate reduction in the size of the product backlog as items are moved from it and into another temporary holding place.
Metaphorically, you can think of the difference between a product backlog and holding tank as simply a line drawn below some item in the product backlog. Above that line are the items the product owner would pay the team tonight to deliver; below it are items that could change or aren’t well understood yet.
More practically, what I’ll do in whatever tool I’m using is create a second project, name it the holding tank, and move items to it from the product backlog.
Doing this allows the team to focus on the much smaller set of items that form their product backlog.
Periodically Review the Product Backlog
The third step in keeping your product backlog to a reasonable size is to institute a regular review process. Nothing fancy is needed here. It can be as simple as the product owner reviewing the product backlog and deleting or moving items as described above. I think doing this quarterly is best.
Don’t Add Things Unless You Plan to Do Them Fairly Soon
Finally, if you want to keep your product backlog small and manageable, you need to be disciplined in not adding items to the backlog unless you fully intend to do them.
Most product backlogs become unwieldy because it was easier for a product owner to say, “I’ll put it on the product backlog” than to tell someone their feature would never see the light of day.
To keep a product backlog in good shape, product owners need to learn to say no or not now. I’ve found that the other tips in this article help them in doing that.
