Characteristics of the Product Backlog

The analogy of the horizon that I brought up in the chapter Why Scrum? well describes the nature of the Product Backlog (see Plan using only as much detail as possible in Waste reduction). This analogy shows us that the Product Backlog is ordered, plannable, emergent, and detailed gradually.

Ordered

The items in the Product Backlog are ordered based on the order in which they will be implemented and, consequently, delivered. This ordering is, in principle, performed by the Product Owner. It is intended to enable the Developers to incrementally realize the Product Goal while satisfying the needs of the product’s users and generating business value for its customers.

Based on the ordering, the features that users need the most at any given moment can reach their hands. And with their use, the Scrum Team obtains feedback and metrics that allow items to be added to the Product Backlog with adjustments and new features, again ordered to maximize value generation.

At the Sprint Planning meeting, the Product Owner and the Developers select a number of items from the top of the Product Backlog to be implemented during the Sprint. As we see in the following figure, the items below these can be implemented in subsequent Sprints, while items further down the Product Backlog may be implemented in future Sprints.

The higher the item is in the Product Backlog, the more likely it is to be implemented and the sooner it can occur. On the other hand, the lower an item is in the Product Backlog, the lower its implementation order and, therefore, the lower its chances of being developed, since eventual changes could make it lose relevance or be significantly modified.

The Product Backlog is ordered

Discussion: ordered or prioritized?

In the 2011 edition of the official Scrum Guide, the terms “prioritize,” “prioritized” and “prioritization” related to the Product Backlog were replaced by “order,” “ordered” and “ordering” (SCHWABER; SUTHERLAND, 2011). James Coplien (2011) wrote an article explaining the reasons for this at the request of Scrum creators Ken Schwaber and Jeff Sutherland.

According to Coplien, prioritizing a list means arranging its items based on the relative importance between them. Thus, when prioritizing items in the Product Backlog, we perform two-by-two comparisons, such as “this item is more important than that item” or “this item has greater value (or a greater return) than that item.” Or, similarly, we compare groups of items, assigning them labels such as “high priority,” “medium priority” and “low priority” or suchlike. These are, therefore, local comparisons, without a broader view that would consider the Product Goal and its context. Prioritization, in this sense, trivializes the Product Owner’s complex job of determining the order in which items in the Product Backlog will be implemented and released.

To order the items in the Product Backlog, the Product Owner needs to use a more holistic view aimed at maximizing the generated value. By ordering rather than prioritizing, the Product Owner understands this value as the result of the product’s use over time and considers what she can see regarding its future. Hence this ordering is directly influenced by important issues such as risks, opportunities, external dependencies, the knowledge available to implement these items and changes in market conditions.

The ordering of items in the Product Backlog is an ongoing process that takes place throughout the entire product development work. To determine the order of the items, the Product Owner considers various factors, including:

the business value and implementation cost of each item.
the interdependences between the items and dependences on external factors.
the risks associated with each item.
uncertainty regarding user behaviors.
technical issues brought up by the team or teams.
market urgency.
bureaucratic or political issues.
the Developers’ current knowledge of the necessary technologies or rules.
the customers’ business strategies.
the organization’s business strategies.

The ordering work is not simple and requires knowledge of the business, market opportunities and risks, competition, the Developers’ ability to implement, techniques for validating and invalidating hypotheses and a number of other factors. The Product Owner gradually seeks the knowledge and assistance needed to perform this work.

Plannable

A plannable Product Backlog allows the Developers and the Product Owner to be able to plan the work for the Sprint that is beginning based on the information contained in the Product Backlog, in addition to envisioning at a higher level what can be performed in future Sprints.

In general, to say that the Product Backlog is plannable means that it allows:

establishing the most likely scope of the current Sprint. That is, what is most likely to be within the Increments of the product resulting from a Sprint or, at a higher level, within a set of Increments to be implemented next.
defining when the next Increments of the product to be implemented can be released to the customers, i.e., the release date, given a likely scope.
calculating the likely implementation capacity of the set of Developers, in general based on the average of what they were able to implement in recent Sprints, also called the Velocity (see Velocity, in the chapter Story Points: estimating the work).
monitoring the progress of work towards a planned date (end of the Sprint or a release date, for example), given the amount of work and time remaining. Work Monitoring Graphs are tools that can be used for this purpose (see chapter Burndown and Burnup: monitoring work).

Emergent

The Product Backlog is a continually evolving list and is thus never finished or complete. As the Developers work on the items in the Product Backlog chosen for the Sprint, transforming them into working parts of the product, other items are added, removed, modified, refined, and reordered. Moreover, this effort occurs continuously as long as the Scrum Team is working on the product and potentially as long as the product exists.

The Product Backlog evolves through a continuous process of discovery, reflected in the inspection and adaptation of the product based on the feedback of customers and other stakeholders on the Increments of the product that have been implemented and shown to them, and with usage metrics on what has already been released to its users until then.

Gradually detailed

The Product Backlog is progressively refined throughout the product development work, so that its items have adequate detail and granularity.

Items at the top of the Product Backlog are always the next to be implemented and should thus have sufficient and necessary detail to be eligible to be implemented. These items have a fine granularity – that is, they require less implementation effort.

Only items with fine granularity can be implemented. I’ve got used to talk about slices, in reference to the Cake Analogy (see Scrum is iterative and incremental in the chapter What is Scrum?). Each slice represents value to the user, something they can directly use. In this way, only thin slices of a feature can be part of a Sprint Backlog.

Definition: thin slices

Thinly slicing the items to be implemented has various advantages. Among them, I can mention:

Allows for better ordering, since slices that originate from different items that were originally larger may have very different priorities between them.
Allows – with more than one slice – the most important part of a problem to be solved more quickly, from end to end.
Allows the end-to-end solving of a problem to fit more easily into a Sprint.
As a result, more value can be released more quickly.
Generates less complexity associated with the feature to be implemented.
As a consequence, allows for faster and better understanding, as much by the team as the customers and users.
Also, as a consequence, allows better estimates to be made.
Generates hypotheses that require less implementation effort, and thus generate less waste if invalidated.

Items further down in the Product Backlog have gradually a coarser granularity and represent less detail. As an item approaches its implementation, it moves up the Product Backlog and can evolve into smaller items, with the details that will be needed for its implementation becoming clarified and elaborated.

Discussion: what is the best Product Backlog?

In the following figure, I present three possible formats for the Product Backlog.

The Product Backlog is gradually detailed

In Product Backlog (I), all items have fine granularity and carry details. More details than are sufficient and necessary constitute waste, since, given the emergent nature of the Product Backlog, the details are known and modified as the product is developed.

In Product Backlog (III), an item at the top has coarse granularity, which means that putting it to be implemented could bring risks, as it would take longer to do it, and with a poor ordering and greater uncertainty associated with it. To correct this problem, it would be necessary to slice this item into one or more small, detailed items that include the most important parts and keep the high order. The rest should be moved – in a single, large, and less detailed item – further down the Product Backlog, perhaps to be implemented in the future.

In addition to this item with coarse granularity at the top, Product Backlog (III) includes various other items further down that have finer granularity and more detail than necessary, which again can be wasteful, as there is a high chance that these details could change by the time the items are implemented. Refining this Product Backlog would be necessary.

Product Backlog (II) is what I consider ideal, as it is gradually detailed – that is, it has sufficient and necessary details, based on the items’ order.