Grooming the Product Backlog

The product backlog is the ultimate resource to making sure that your project sees the light of day, and of the highest quality possible. That is, as long as your backlog is given the attention it deserves, and needs. In this article we help you keep your backlog groomed to perfection.

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.

Detailed Appropriately
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 releases can help answer this question.
    • Dependencies: Weather we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even nonfunctional requirements. And if several teams work together, dependencies between them can influence the prioritization. Dependencies that cannot be removed restrict the freedom to prioritize the product backlog and influence the effort estimates; the item on which others depend has to be implemented first.

Prioritization is imperative as it directs the team’s work by focusing the team on the most important items. It also freezes the backlog contents progressively – items in the product backlog are detailed according to their priority.

The Grooming Steps
To ensure that the product backlog is DEEP, we have to regularly groom it. Grooming the product backlog is an ongoing process that comprises the four steps listed below. These are not necessarily carried out in the order stated:

    • New items are discovered and described, and existing ones are changed or removed as appropriate. A great technique to capture functional requirements on the product backlog is user stories. User stories describe functionality form a user’s perspective, are easy to use and can be smoothly refined incrementally.
    • The product backlog is prioritized. The most important items are now found at the top. The lower-priority items are found at the bottom. It’s clear which items will participate in the next release or product version and in which order the items will be implemented.
    • The high-priority items are prepared for the upcoming sprint planning meeting; they are decomposed and refined until they are ready: The are clear – the entire Scrum team has a common understanding of the items. They are feasible – small enough to fit into the next sprint so they can be transformed into a product increment according to the definition of done. And they are testable – they can be validated so that the product owner can assess if an item was successfully implemented or not at the end of the sprint.
    • The team sizes product backlog items. Adding new items to the product backlog, changing existing ones, and correcting estimates make sizing necessary. Common measures of size are story points and ideal days. A great technique to facilitate team estimations is planning poker. Note that team members don’t estimate the work individually. The team agrees on the likely team effort.

Grooming is Teamwork
Although the product owner is responsible for making sure that the product backlog is in good shape, grooming is teamwork in Scrum. Items are discovered and described, prioritized, decomposed, and refined by the entire Scrum team – Scrum allocates up to 10% of the team’s availability for grooming activities (Schwaber 2007). Stakeholders are also involved as appropriate. Grooming the product backlog collaboratively creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members coauthor them. This increases the clarity of the requirements, leverages the Scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.

Some teams like to do a bit of grooming after their Daily Scrum. Others prefer weekly grooming sessions or a longer grooming workshop toward the end of the sprint. Grooming activities also take place in the sprint review meeting when the Scrum team and the stakeholders discuss the way forward; new backlog items are identified and old ones are removed. 

My favorite tool to support product backlog grooming are paper cards. They are cheap and easy to use. They facilitate collaboration; everyone can grab a card and write down an idea. They can also be grouped on the table or wall to check for consistency and completeness. Cards and electronic product backlog tools, such as spreadsheets, complement each other: Print out existing requirements on paper cards prior to a grooming workshop, and transfer the information on the cards back into the electronic tool afterward.

Grooming the product is an ongoing process that ensures that the product backlog is DEEP. The product owner, ScrumMaster, and team should groom the backlog collaboratively involving the stakeholders as appropriate. Make sure you establish a grooming process so that the activities are carried out reliably, for instance, by starting with weekly grooming workshops. A well-groomed backlog is a prerequisite for a successful sprint planning meeting as well as for creating a successful product.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.