Chapter 6: Product Backlog

This chapter describes the important role that the product backlog plays on a Scrum development project.

PRODUCT BACKLOG Overview

The product backlog is a prioritized list of desired product functionality. It provides a centralized and shared understanding of what to build and the order in which to build it. For more background, you might also want to read my blog post, “Demystifying Product Backlog Concepts.”

Product Backlog Items

The product backlog is composed of product backlog items, or PBIs. Most PBIs are features, items of functionality that will have tangible value to the user and customer. These are often written as user stories (or sometimes use cases or free form text). Other PBIs include defects needing repair, technical improvements, knowledge-acquisition work, and any other work the product owner deems valuable. The figure below illustrates the product backlog.

Good Product Backlog Characteristics

Good product backlogs share similar characteristics, which Mike Cohn and Roman Pichler captured with the acronym DEEP: Detailed appropriately, Emergent, Estimated, Prioritized. Let's look more closely at each of these characteristics.

Detailed Appropriately

The product backlog items will differ in their level of detail. Those that we will work on sooner, those at the top off the product backlog, will be more detailed. Those that we won't work on for some time will be less detailed. We want to refine (add detail to) backlog items as they rise in priority, adding details in a just-enough, just-in-time fashion.

Emergent

As discussed in earlier chapters, the product backlog is a living document, constantly changing as the product is being developed or maintained. As the team and product owner learn more about the product and the marketplace, they might add new items, discard some, and change others. The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog. 

Estimated

At the appropriate time, each product backlog should have a size estimate that corresponds to the effort required to develop that item. The product owner uses these estimates to help determine a product backlog item's priority. Ideally most of items at the top of the product backlog will be sprint-sized, small enough to be worked on during a single sprint. Large, high-priority items should be broken into smaller stories prior to being declared sprint-ready (see Definition of Ready for more on this concept).

Prioritized

A product backlog should be a prioritized list of PBIs, but not every PBI needs to be prioritized. I recommend prioritizing about a release worth of PBIs. Prioritizing beyond that is likely a waste of effort, as too much might change by the time the first release is out. Instead, prioritize new items as they emerge and save the “someday” or “future release” items for later.

Grooming

To create a DEEP product backlog, we must take the time to groom the product backlog. Let's look briefly at what that entails. Grooming is made up of three principal activities: creating and refining PBIs, estimating PBIs, and prioritizing PBIs. These activities take place throughout the product development effort.

Grooming is a collaborative effort led by the product owner (the decision maker) and including significant participation from the ScrumMaster, the development team, and key internal and external stakeholders. In Scrum, grooming can happen at many times, but most often happens initially during release planning, after sprint reviews, and as a regular part of each sprint (ad hoc, weekly, or once-a-sprint, depending on what makes sense for the product owner and team). As a general rule, the development team should expect to spend up to 10% of its time each sprint assisting with grooming activities.

Definition of Ready

The end result of grooming should be that the items at the top of the backlog are ready to be moved into a sprint. Some teams formalize this state using a definition-of-ready checklist for product backlog items. A sample definition of ready is shown in the following table:

Flow Management

A good product backlog enables the Scrum team to deliver with fast, flexible, flow in the presence of uncertainty. 

Release Flow Management

Grooming supports ongoing release planning, the flow of features within a release. Each release can be visualized by two lines that run through the product backlog, partitioning it into 3 distinct areas: must have, nice to have, and won't have. The PBIs above the top line are ones that must be in the release. Those that fall between the top line and the bottom line are ones that would be “nice to have.” And those features that fall below the bottom line will likely not make it into the release. I'll talk more about release planning in Chapter 18.

Sprint Flow Management

Product backlog grooming should ensure good sprint flow. Picture the product backlog as a pipeline through which the product features flow into sprints, where they are designed, built, and tested by the team. Notice that as a proposed feature nears the end of the pipeline, it becomes progressively smaller and more refined. By the time a feature leaves the product backlog pipeline, it must be ready—detailed enough that the team can understand it and be comfortable delivering it during a sprint. Product owners should never let the pipeline run dry—teams need enough potential items to fill the sprint in the optimum way.

By the same token, product owners shouldn't overfill the pipeline with too many small items, because it easily could result in too much detailed inventory (requirements) that might need to be reworked or thrown away if and when the situation changes. As such many follow a rule of thumb of having 2-3 sprints worth of sprint-ready features in the backlog at all times. 

Which and How Many Product Backlogs?

In general, each product should have one single backlog that describes the work needed to build the product. Occasionally, however, this rule can be broken. To understand how and why, let's start by defining the term product.

What Is a Product?

It isn't always clear what constitutes a product. Is Microsoft Excel the product or is instead one component of the larger product called Microsoft Office? I contend that it depends on what the customer is willing to buy and you are willing to sell. In other words, a product is something of value that a customer would be willing to pay for and something we're willing to package up and sell. This definition can grow more complicated, as discussed in Chapter 12, but it is good enough for this initial discussion.

Large Products—Hierarchical Backlogs

Whenever possible I prefer one product backlog, even for a large product such as Microsoft Office. However, sometimes this isn't practical. In those cases, some organizations use hierarchal backlogs, which have one backlog at the top that describes and prioritizes the large-scale features of the product. That top-level backlog is managed by the chief product owner. Then beneath the highest-level backlog are multiple area backlogs, which each describe a specific feature area and are managed by a designated product owner. 

Multiple Teams—One Product Backlog

The one-product-one-backlog rule is designed to allow all of the teams on the product to share a product backlog. This optimizes economics because all of the features compete for priority against all other features, ensuring that the highest-priority features from the full-product perspective are identified and prioritized accordingly. Then, if all of our teams are interchangeable, any team can work on any PBI in the one backlog, ensuring the highest priority items are always developed first.

Sometimes, however, our teams are not interchangeable—they have more specialized skills and knowledge. In these cases, we need team-specific views into the backlog, so that teams see and choose from only the features that are relevant to their skillsets. This works, but has the unfortunate side effect of having some teams work on much lower priority features than other teams. That's one reason why organizations should strive for a high level of shared ownership and more interchangeable teams.

One Team—Multiple Products

If a company has multiple products it will have multiple product backlogs. The best way to handle multiple product backlogs is to assign one or more teams to work exclusively on each product backlog. If organizational impediments make this impossible, and one team must work on multiple products concurrently, consider merging the PBIs for the affected products into one product backlog. This would require the product owners from each affected backlog to come together to reach a single prioritization for all the upcoming items. 

Closing

The product backlog plays a crucial role in achieving a fast, flexible flow of value delivery in the presence of uncertainty. The next chapter discusses how product backlog items are estimated and how those estimates are used to measure velocity.

Good product backlog management is essential to success with Scrum. If you struggle with product backlog management and release planning, consider training from Innolution.com. Our Agile Estimating and Planning course and Certified Scrum Product Owner training deal with these concepts in depth. You might also want to inquire about on-site workshops and coaching from Essential Scrum author Ken Rubin.