© 2010 Roman Pichler, romanpichler.com
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. Business analysts can play an important role to ensure that this is done well.
The Well-groomed Product Backlog
A well-groomed product backlog has four qualities in Scrum: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP.
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 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 and 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.
Estimated
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 relevant sprint planning meeting; tasks and their estimates are captured in the sprint backlog.
Emergent
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.
Prioritized
All items in the product backlog are prioritized. 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 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 several teams working together can create further dependencies in the backlog. 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.
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. Note that 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: They 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. Instead, they agree 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. Items are best 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. Stakeholders are also involved as appropriate. Product definition is hence a team effort in Scrum. There is no longer one person who is solely charged with identifying and detailing requirements.
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.
Grooming and the Business Analyst
If grooming is teamwork, what’s then left to do for the business analyst? The answer depends on the role business analysts play in Scrum. As an analyst acting as the product owner, you are not only in charge of the grooming process but you are also in a great position to guide and teach the team and the stakeholders. As a business analyst working on the team you engage in the grooming activities together with the product owner and the other team members who will greatly benefit from your skills and your experience.
Be careful though to involve your fellow Scrum team members properly. Help and guide your colleagues but do not to take over – even if you are best qualified to capture and refine requirements. This would not only turn you into a bottleneck but also waste the benefits of a team-based grooming approach discussed above.
Summary
Grooming the product is an ongoing process to ensure that the product backlog is DEEP. Product owner, ScrumMaster, team should groom the backlog collaboratively involving the stakeholders as appropriate. As a business analyst, your skills and your experience will be important to groom the backlog well.
Find out more about working with the product backlog projects in my new book Agile Product Management with Scrum: Creating Products that Customers Love. The book is the product owner’s guide to creating successful products with Scrum; it discusses the product owner role together with essential product owner practises increasing envisioning the product, grooming the product backlog, and planning the release.
Author: Roman Pichler is a leading Scrum and agile product management expert. He is the author of Agile Product Management with Scrum: Creating Products that Customers Love. Roman has a long track record in teaching and coaching product owners and in helping companies apply effective product management practices. Find out more at romanpichler.com.
NOTE: top image © Nikolai Sorokin - Fotolia.com