RSSImagine your boss tells you: “Congratulations, we’d like you to take on the product owner role for our important new-product development project! And we’ve done some upfront work for you: Here is the initial product backlog.” You thank her and take the memory stick she hands you, and then walk back to your desk, where you put the stick into your laptop. After opening the product backlog, you discover that it contains 1800 detailed items. “Wow, what a product backlog,” you think and, “where should I start?”
This little story illustrates an interesting conflict: The product backlog is intended as a beautifully simple tool. But real-world product backlogs are often too long and detailed, and therefore difficult to use. 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. I owe the acronym to Mike Cohn by the way. Mike uses it in his latest book Succeeding with Agile and he has also blogged about it. Let’s now explore the four qualities in more detail.
Detailed Appropriately
The product backlog items are detailed appropriately, as illustrated in the figure below. 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. As a consequence, requirements are discovered, decomposed, and refined throughout the entire project.
Product backlog prioritization determines the level of detail.
Estimated
The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the size of the items helps prioritize them and plan 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 they are added to the product backlog. Existing items are modified, reprioritized, refined, or removed on an ongoing basis.
Prioritized
All items in the product backlog are prioritized. 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.
Groom it, Baby!
To ensure that the product backlog is DEEP, we have to regularly groom it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner, ScrumMaster, and team as well as stakeholders. My next post will explore grooming the product backlog in more detail.
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 it 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 vision 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.
Read on
If you enjoyed reading this post, you will love my book Agile Product Management with Scrum: Creating Products that Customers Love. The book provides a whole chapter on working with the product backlog effectively.
Comments RSS
[...] Making the Product Backlog DEEP [...]
[...] emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user [...]
Change Management says: You made some good points there. I did a search on the topic and found most people will agree with your blog.
[...] backlog should be D.E.E.P (some more info on [...]
[...] 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 [...]
[...] your product backlog DEEP. Ensure that is is detailed appropriately, emergent, estimated, and [...]
[...] 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” [...]
[...] 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. [...]
[...] backlog should be D.E.E.P (some more info on [...]
[...] 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 [...]
[...] Roman Pichler Rate this: Like this:LikeBe the first to like this post. Posted by PE in Agile, Requirements, [...]
[...] see a lot of deep backlogs. Teams that practice agile planning usually have a well groomed backlog towards the top [...]
[...] Grooming should result in a DEEP product backlog [...]