The product backlog is a beautifully simple artifact – a prioritized list of the outstanding work necessary to bring the product to life. To work with the product backlog effectively, it needs regular attention and care; it needs to be carefully managed, or groomed.
The DEEP Qualities of the Product Backlog
The product backlog has four qualities in Scrum: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP. I find that particularly the first and the third property are often overlooked. Let’s explore these qualities in more detail, as grooming aims to ensure that the product backlog always fulfils the four qualities.
The product backlog items are detailed appropriately. Higher-priority items are described in more detail than lower-priority ones; they are smaller are more precise. “The lower the priority, the less detail, until you can barely make out the backlog item,” write Schwaber and Beedle in 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 workable. As a consequence, requirements are discovered, decomposed, and refined throughout the entire project. Product discovery is hence an ongoing process in Scrum. There is no longer a product definition phase where the product functionality is determined once and for all.
The product backlog items are estimated or sized. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the size of the items is a cost indicator. It helps prioritize the product backlog and facilitates planning the release. Note that detailed task-level estimates are created in the sprint planning meeting; tasks and their estimates are captured in the sprint backlog.
The product backlog has a very organic quality. It evolves, and its contents change frequently. New items are discovered and added to the backlog based on customer and user feedback. Existing items are modified, reprioritized, refined, or removed on an ongoing basis. The product backlog is hence a dynamic artifact that changes throughout the entire project. It is by no means fixed.
All items in the product backlog are prioritized. The most important and highest-priority items are implemented first. They are found at the top of the product backlog. Once an item is done, it is removed from the product backlog. Scrum does not mandate how the product backlog is prioritized. But I have found the following prioritization factors useful:
- Value: I consider an item valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. The Scrum team either de-prioritizes the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the Scrum team focused. If the item is important for a future version, it will reemerge.
- Knowledge, uncertainty, and risk: Because risk and uncertainty influence product success, uncertain and risky items should be high-priority. This accelerates the generation of new knowledge, drives out uncertainty, and reduces risk. If the Scrum team, for instance, is unsure about some aspects of the user interface design, the relevant design options should be explored and tested by gathering feedback from customers and users early on.
- Releasability: Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If the Scrum team is uncertain about if and how a feature should be implemented, early