Imagine 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.
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.
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.
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.
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.
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.