Summary
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.
Conclusion
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.
| Reference: | How Detailed should the Product Backlog be? from our JCG partner Roman Pichler at the Pichler’s blog blog. |
