Photo by K8 on Unsplash

Tips for Reducing the Product Backlog Size

Published on 13th August 2019

It's normal that a product backlog changes over time. But some backlogs grow too big and become overly long, detailed, and complex. Consequently, they are difficult to update, prioritise, and refine. The following five tips help you simplify such a backlog and reduce its size so you can manage with it more easily.

Split the Product Backlog

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.


Limit the Product Backlog Scope

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 three to six months, for example, acquire x number of new users or increase engagement by y%. Then use the goal to 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.

If you use a goal-oriented or outcome-based product roadmap, consider generally focussing the product backlog on the next goal or outcome on the roadmap. This is particularly useful as long as change, uncertainty, and innovation are present, which is the case for new and young products and for those offerings that are experiencing a major update.


Hide the Details

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.

If you also relate user stories to the epic they belong to, you will create the following structure: theme –> epic –> user story. While a product backlog that is structured this way contains the same number of items, of course, you can now access its contents more easily by using themes and epics to navigate to the detailed user stories.


Aggregate the Details

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. 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.


Eliminate Zombie Items

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 implement 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.

Post a Comment or Ask a Question

6 Comments

  • Bhavin says:

    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?

    • Roman Pichler says:

      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?

      • Bhavin says:

        It seems we could also potentially implement the practices you recommended AFTER the backlog is cleaned up?

        • Roman Pichler says:

          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:

          • Start with a shared, inspiring product vision.
          • Find an effective product strategy and create personas that describe the target group.
          • Derive an actionable product roadmaps with goals/outcomes.
          • With the help of the next goal/outcome on your roadmap and your personas, determine the right product backlog items and capture the right user stories.

          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!

  • Tim Hemig says:

    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.

1 Trackback

  • Bhavin says:

    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?

    • Roman Pichler says:

      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?

      • Bhavin says:

        It seems we could also potentially implement the practices you recommended AFTER the backlog is cleaned up?

        • Roman Pichler says:

          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:

          • Start with a shared, inspiring product vision.
          • Find an effective product strategy and create personas that describe the target group.
          • Derive an actionable product roadmaps with goals/outcomes.
          • With the help of the next goal/outcome on your roadmap and your personas, determine the right product backlog items and capture the right user stories.

          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!

  • Tim Hemig says:

    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.

  • […] post How to Reduce the Product Backlog Size appeared first on Roman […]

Leave a Reply

Your email address will not be published. Required fields are marked *