Photo by K8 on Unsplash

How to Reduce the Product Backlog Size

Published on 13th August 2019

While it's normal that a product backlog changes, some backlogs grow too big and become overly long and detailed. Consequently, they are difficult to update, prioritise, and refine. The following tips help you simplify such a backlog 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 reduce the product backlog size by unbundling one or more features and releasing 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.

To use this technique to make your product backlog smaller, create a separate backlog for the new product and move the unbundled features from the old to the new product backlog.


Reduce the Product Backlog Scope

Your second option is to limit the scope of your backlog. To do so, choose a clear, specific, and measurable 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 the 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 complement your product backlog with a product roadmap, you can do two things: First, you can use the upcoming roadmap goal to scope your backlog. Secondly, you can capture important backlog items that do not serve the goal as coarse-grained features on the roadmap (together with their appropriate goals). This way, they are not forgotten or lost. But don’t make the mistake of overloading your product roadmap with features and don’t add any epics or user stories to your product roadmap. Otherwise, the roadmap will become overly detailed and volatile.


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 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 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 tends to be 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 requests and empathise with the individual. But be not afraid to say no once you’ve understood the person’s 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 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 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 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 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 to How to Reduce the Product Backlog Size – Matteo Borghesi Cancel reply

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