Make the Product Backlog DEEP

By Roman Pichler, 8th February 2010
Picture by 贝莉儿 NG, published on Unsplash under the Creative Commons Zero license

The product backlog is intended to be a simple tool. But in reality, product backlogs are often too long, too detailed, and difficult to use. This post explains how you can avoid this common trap by making your backlog DEEP: Detailed appropriately, estimated, emergent, and prioritised.

Going DEEP

Imagine your boss telling you: “Congratulations, we’d like to ask you to take on the product owner role for our new product! And we’ve done some upfront work for you: Here is the initial product backlog.” You thank her and walk back to your desk, where you look at the backlog and discover that it contains several hundred items. “That’s a big product backlog,” you think and “where should I start?”

This little story illustrates a common challenge: Product backlogs are often too long and detailed, and therefore difficult to use. Part of the solution is to ensure that your product backlog is DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. I find that particularly the first and the third property are often overlooked. (Additional, I recommend that you complement your backlog with a product roadmap and focus the product backlog on the next major release, as I discuss in my post The Product Roadmap and the Product Backlog.)

Detailed Appropriately

The product backlog items are detailed appropriately if higher-priority items are described in more detail than lower-priority ones. “The lower the priority, the less detail, until you can barely make out the backlog item,” write Ken Schwaber and Mike Beedle in their book Agile Software Development with Scrum. Following this guideline keeps the backlog concise and ensures that the items likely to be implemented in the next sprint are ready.



The product backlog items–certainly the ones participating in the next major release–should be estimated. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the rough size of the items helps prioritise them and track the progress of the release.


The product backlog has an organic quality: it evolves and its contents change frequently. New items emerge based on customer and user feedback and are added to the backlog. Existing items are modified, reprioritized, refined, or removed on a regular basis.


All items in the product backlog are prioritised (or ordered). The most important and highest-priority items are implemented first. They can be found at the top of the product backlog, as illustrated in the figure above. Once an item is done, it is removed from the product backlog. Note that the Scrum framework does not suggest any prioritisation factors. But I recommend that you first prioritise your backlog by risk. Once the key risks have been addressed, use cost-benefit and dependencies to determine the order in which the items should be implemented.

Groom It!

To ensure that the product backlog is DEEP and stays that way, you have to regularly groom or refine it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team, as I describe in more detail in the post Grooming the Product Backlog

To conclude the story from the beginning of this post, my preferred course of action as the designated product owner is to explain to the boss that the product backlog is too detailed and long, which makes it difficult to evolve based on customer and user feedback. This in turn reduces the likelihood of delivering a successful product. The product backlog resembles a disguised requirements specifications, which is a common trap to fall into. My suggestion is use the product roadmap to derive a new product backlog that fulfils the DEEP criteria and to discard the old one–even if that’s not necessarily what the boss wants to hear.

Article Name
Make the Product Backlog DEEP
Learn how to effectively use the product backlog by making it DEEP, detailed appropriately, estimated, emergent, and prioritised.
Pichler Consulting

Learn More

You can learn more about the product backlog with the following:


One comment on “Make the Product Backlog DEEP

  1. Change Management

    You made some good points there. I did a search on the topic and found most people will agree with your blog.

Leave a Reply

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

RSS Feed

Tags related to this post: