How Detailed should the Product Backlog be?

By Roman Pichler, 14th July 2015

The product backlog is a great tool. But using it effectively can be difficult. One of the challenges is to get the level of detail right. An overly detailed backlog is unwieldy and hard to manage. But a product backlog that is too coarse-grained is also not helpful: It provides too little guidance for the development team. This post helps you strike the right balance between too much and too little detail. It shows you how determine the right amount of detail for your product backlog.

Theory and Practice

In theory, your product backlog should be prioritised with the high-priority items at the top and the low priority items at the bottom. The top items should be detailed and fine-grained. But as their priority decreases, they should become more and more coarse-grained. You could capture your top items as small user stories that are ready to be implemented in the next sprint. But further down in the backlog you would use epics, which are big sketchy stories. How detailed an items is therefore depends on its priority, as the following picture shows.

If your product backlog does not look like the one above, does this mean it is wrong?

The Product Lifecycle

I find that a product backlog like the one pictured above is optimised for a young product. At this stage, you typically have to experiment with new ideas and change your product frequently, for instance, to discover the right user experience and features or to enhance and optimise them. As a consequence, you want to be able to easily change your backlog, keep it concise, and use only a small amount of detailed items. Otherwise, updates are too much effort and take too long.

But as your product stabilises and eventually matures, you have learned to better understand the market, the customer needs, and how to address them. This increases your ability to anticipate how your product is likely to evolve. Consequently, you can add more details to your backlog.

How detailed your product backlog should be is therefore tied to the lifecycle stage of your product: Young product should have a concise backlog with few details; older, stable products tend to benefit from a more detailed backlog, as the following picture shows.

The product backlog on the left-hand size of the lifecycle curve carries only a few detailed items; most of its contents are coarse-grained. But the backlog on the right-hand side is the opposite: It contains many more detailed items and fewer coarse-grained ones. As a consequence, it is larger and less concise. But watch out that your backlog does not grow in an uncontrolled fashion or morph into a wish list. Complement it with a product roadmap to capture the longer-term outlook of how your product is likely to grow.

While the product lifecycle is great to gauge the right level of detail, it is not enough. You should also consider where your product’s position in the release cycle.

The Release Cycle

As you start working on a new product version or a major release – think of iOS 8.4 or Windows 10 – you typically encounter more unknowns and risks than towards the end of the project. If you address the risks on early, then your product backlog is particularly volatile in the first few sprints. As you test assumptions and address the risks, you are likely to discover that some of your assumptions were wrong and generate new ideas. The new insights and ideas make it necessary to change the product backlog, and some of the change can be rather big, particularly if your product is young. You will therefore benefit from a concise and coarse-grained backlog at the start of a new release.

But once you have addressed the key risks and critical assumptions, your focus shifts to completing and optimising the features, as I explain in my post “Get Your Focus Right: Learning and Execution in Scrum“. At this point your product backlog should start to stabilise and experience fewer and smaller changes. As a consequence, you can add more details to it.

As a rule of thumb, use few details at the start of a project or release and more once you have addressed the key risks and the product backlog has started to stabilise.


Use the product lifecycle and release cycle to determine how detailed the product backlog should be. This is true for traditional backlogs as well as Jeff Patton’s storymaps and my Product Canvas. To put it simple, the more uncertainty and change you experience the more coarse-grained and concise the backlog should be.


As your product develops and grows adjust your product backlog and the way you manage it. There is no one right level of detail.

Learn more

You can learn more about the product backlog by reading my book Agile Product Management with Scrum and by attending my Certified Scrum Product Owner training course.


Article Name
How Detailed should the Product Backlog be?
This article explains how you can determine the right level of detail for your product backlog.


RSS Feed

Tags related to this post:

3 comments on “How Detailed should the Product Backlog be?

  1. Guilhem

    Hi Roman and thank you very much for all your articles and precious information!

    A question is still popping up without any good answer. What about all the ideas that cross our POs/PMs life. Everyone has a good idea and we receive tones of it.
    So either it’s an actionable one and it will be in the “short term” backlog or, if it’s just an idea, and we forget it (at least to follow it up correctly and to give feedback to the person who gave it)

    I have in mind this sentence saying that “if it’s really important, your customers won’t let you forget it. (37 signals)”

    • Roman Pichler

      Thanks for your feedback and your question Guilhem. I like to suggest the following rule: If an idea is helpful to achieve the release/product goal then it should be captured in the product backlog. If that’s not the case but the idea helps progress the product in the future, then capture it on the product roadmap. Otherwise forget about it. If it turns out to be relevant in the future, it’ll come back to you. Hope this helps.

      • Guilhem

        Many thanks! Common sens indeed but helpful to read!

Leave a Reply

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