Faced with an overly long and detailed product backlog, investigate if it does describe one cohesive product. Over time, products can serve an increasingly heterogeneous market and provide a large number of different features, some of which may not be used by all users.
If that’s the case for your product, then you can unbundle one or more features and release them as products in their own right, like Facebook did with Messenger in 2014. The company unbundled the messaging functionality originally included in its Facebook mobile app and made it available as a stand-alone product.
Move the unbundled features to a separate backlog for the new product, and enjoy working with the original product backlog, which is now smaller.
Your second option is to limit the scope of your backlog. To do so, choose a clear, specific, and measurable product goal for the next two to six months, for example, acquire x number of new users or increase engagement by y%. Then use the goal to direct and focus your product backlog: Remove all backlog items that do not help meet this goal.
While this approach may sound radical, it ensures that your product backlog is concise and focused. It avoids looking too far into the future, having speculative items on the backlog, and turning the product backlog into a wish list.
To capture additional ideas of how to progress your product, use a goal-oriented or outcome-based product roadmap and focus the product backlog on the next goal or outcome on the roadmap. This way, the product roadmap complements the product backlog: The former is a longer term, strategic plan; the latter contains the product details and facilitates execution.
Your third option is to structure the product backlog in order to make it more manageable thereby hiding detailed items. A simple way to do this is to group epics into themes, which represent coarse-grained features or user journey steps like registration or search and navigation.
This allows you to work with the following structure: theme → epic → user story. While such a product backlog contains the same number of items, you can now access its contents more easily by using themes and epics to navigate to the corresponding user stories.
Another option to reduce the product backlog size is to combine detailed items. This is achieved by replacing lower-priority, fine-grained items with a coarse-grained one, for example, substituting a number of user stories with a newly created epic. This can be particularly helpful when you inherit an overly long and detailed product backlog.
In addition to reducing the product backlog size, aggregating the details creates an appropriately detailed product backlog. Such as backlog is easier to update and change, which is particularly helpful for young products and those experiencing a major change like a life cycle extension.
Most of us have probably done it: Adding items to the product backlog to please an important stakeholder even though we knew that we would not be able to implement them any time soon. Over time, they’ve turned into zombie items at the bottom of the product backlog, which aren’t dead or alive.
If you’ve followed my earlier advice, you will have already removed those items. But if that’s not the case, then either make them high priority or delete them now. Your product backlog should only contain items that help create value for the users or business—not to appease individuals.
In the future, make sure to decline items that are not helpful to execute the product strategy and meet specific product goals. Attentively listen to and empathise with a stakeholder who requests a feature. But be not afraid to say no once you’ve understood the person’s underlying needs and interests.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Thank you for this article. One problem I have is that I have 3 different teams, each who have a separate backlog, and then we have a combined Portfolio backlog that includes all of the teams together. It can get confusing when looking at priorities on different teams. Is this a good approach? Also, should tech debt be in a separate backlog or does is belong in the backlog with new features and bugs?
You're welcome Etefia and thanks for sharing your question. I generally recommend that every product has its own product backlog and that every backlog describes one product. If several development teams are required to progress a single product, then they should work on the same product backlog. To prioritise different development efforts and products, I like to use a tool like the product portfolio matrix. Hope this helps!
Always a great fan of your work Roman.
I have a question about teams having not just huge, but messy backlog.
Teams beginning their journey by literally dumping all their work onto 'a' tool which then lacks visibility, predictability and transparency. My question is is, how can I help them build a uniform and structured view that provides clarity on vision and objectives. As much I would like to extract all tickets to a whiteboard & use the persona template to define customer and then define steps to solve THAT CUSTOMER's problem. And later, map those extracted tickets to those steps. The challenge here however, and what is confusing me is, if the team has been seeing Agile as a project management methodology, there is potentially a different starting point. And on the second hand, team hardly sees value in investing time if the discussion is not related to their work work.
I hope I could articulate the real world problem. So implementing product backlog reduction workshop might require ten different things to be done before we have the buy in from the team. So what evidences should we build to even say that current backlog is of no value?
Hi Bhavin,
Thank you for sharing your question. When working with a product backlog like the one you described, you have to main option in my experience: First, go through the backlog, assess each item, and keep or remove it. Second, throw away the product backlog and start afresh. While the second option may sound radical, it can be more effective when dealing with a long or very heterogeneous backlog.
Whichever option you choose, you should be able to confidently describe the target users and customers of the product and the value it should create for them, before you create personas and user stories or assess existing ones. It's impossible to capture appropriate personas and stories if we don't know the users and the value the product should create for them. Additionally, I recommend working with product/release goals that describe the outcome the product should achieve in the next two to six months. This usually results in a shorter and less heterogeneous product backlog.
A great way to help the development team members understand and empathise with the users is to involve them in the necessary product discovery and strategy validation work. In other words, it it always tricky for dev teams to make meaningful contributions to the product backlog if they don't understand the product's market and value proposition.
Does this help?
It seems we could also potentially implement the practices you recommended AFTER the backlog is cleaned up?
Yes, you can. But when the majority of product backlog are difficult to relate to user needs or goals, and you are unsure why they are in the backlog, then I would start afresh. My preferred way to derive a product backlog is:
This might sound like a lot of work. But when applied properly, it does ensure that product backlog items are derived in systematic way and create value for the users and the business.
Hope this helps!
Out of curiosity: Why is "stop adding more items to the backlog" not an option to cope with a too large backlog?
If you reduce new items to absolutely necessary ones (security related fixed etc.) and keep on working, the backlog should shrink over time and reach a maintainable size. Then you could start adding new features items again.
Assuming that my team will now double over night, all the other options seem to make the big workload maintainable, but would not keep your log from growing further out of hand, since there are no countermeasures against new/more items.
Thanks for sharing your question Tim. As long as you want to innovate and leverage feedback from users and customers, your product backlog will change. Freezing it is therefore not a generally recommendable option. But you may want to limit its scope, as I suggest in article.
Does this help?