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.
Estimated
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.
Emergent
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.
Prioritised
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.
Post a Comment or Ask a Question
1 Comment
You made some good points there. I did a search on the topic and found most people will agree with your blog.
14 Trackbacks
[…] Deep […]
[…] Grooming should result in a DEEP product backlog […]
[…] see a lot of deep backlogs. Teams that practice agile planning usually have a well groomed backlog towards the top […]
[…] Roman Pichler Rate this: Like this:LikeBe the first to like this post. Posted by PE in Agile, Requirements, […]
[…] little pieces. It does mean to keep the Product Backlog „detailed appropriately“ (see DEEP acronym). So keep your top requirements sliced into small pieces and wait with slicing the rest until it is […]
[…] backlog should be D.E.E.P (some more info on […]
[…] Roman re-iterated an idea (from Mike Cohn) that the product backlog would ideally be DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. More on that from his blog. […]
[…] allgemein zur aktuellen (Projekt-) Situation getätigt werden. Roman Pichler spricht vom “DEEP Backlog” und wie viele andere Scrum-Experten rät auch er zum regelmäßigen “grooming” […]
[…] your product backlog DEEP. Ensure that is is detailed appropriately, emergent, estimated, and […]
[…] recommends in his book Agile Project Management with Scrum that a product vision and an initial product backlog should be available before the first sprint starts. Applying this advice results in the following […]
[…] backlog should be D.E.E.P (some more info on […]
You made some good points there. I did a search on the topic and found most people will agree with your blog.
[…] emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user […]
[…] emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user […]
[…] Making the Product Backlog DEEP […]