This chapter is from the book
This chapter is from the book
This chapter is from the book
Flow Management
The product backlog is a crucial tool that enables the Scrum team to achieve fast, flexible value-delivery flow in the presence of uncertainty. Uncertainty cannot be eliminated from product development. We must assume that a stream of economically important information will be constantly arriving and that we need to organize and manage the work (manage the product backlog) so that this information can be processed in a rapid, cost-effective way while maintaining good flow. Let’s examine the role of the product backlog in supporting good release flow and sprint flow.
Release Flow Management
The product backlog must be groomed in a way that supports ongoing release planning (the flow of features within a release). As illustrated in Figure 6.5, a release can be visualized as a line through the product backlog. All of the PBIs above the release line are targeted to be in that release; the items below the line are not.
){kind=link}
I have found it useful to actually partition the product backlog using two lines for each release, as illustrated in Figure 6.11.
){kind=link}
Figure 6.11. Release-level view of the product backlog
These two lines partition the backlog into three areas: must have, nice to have, and won’t have. The must-have features represent the items that we simply must have in the upcoming release or else we don’t have a viable customer release. The nice-to-have features represent items we are targeting for the next release and would like to include. If, however, we run short of time or other resources, we could drop nice-to-have features and still be able to ship a viable product. The won’t-have features are items that we’re declaring won’t be included in the current release. The second line, the one that separates the won’t-have items from the others, is the same as the Release 1 line shown in Figure 6.5.
Maintaining the backlog in this fashion helps us better perform ongoing release planning, as I will discuss in Chapter 18.
Sprint Flow Management
Product backlog grooming is essential for effective sprint planning and the resulting flow of features into a sprint. If the product backlog has been detailed appropriately, the items at the top of the backlog should be clearly described and testable.
When grooming for good sprint flow, it is helpful to view the product backlog as a pipeline of requirements that are flowing into sprints to be designed, built, and tested by the team (see Figure 6.12).
)
Figure 6.12. The product backlog as a pipeline of requirements
In this figure we see that larger, less-well-understood requirements are being inserted into the pipeline. As they progress through the pipeline and move closer to the time when they will flow out to be worked on, they are progressively refined through the grooming activity. At the right side of the pipeline is the team. By the time an item flows out of the pipeline, it must be ready—detailed enough that the team can understand it and be comfortable delivering it during a sprint.
If there is ever a mismatch or unevenness between the inflow and outflow of items, we have a problem. If the flow of groomed, detailed, ready-to-implement items is too slow, eventually the pipeline will run dry and the team won’t be able to plan and execute the next sprint (a major flow disruption or waste in Scrum). On the other hand, putting too many items into the pipeline for refinement creates a large inventory of detailed requirements that we may have to rework or throw away once we learn more (a major source of waste). Therefore, the ideal situation is to have just enough product backlog items in inventory to create an even flow but not so many as to create waste.
One approach that Scrum teams use is to have an appropriate inventory of groomed and ready-to-implement items in the backlog. A heuristic that seems to work for many teams is to have about two to three sprints’ worth of stories ready to go. So, for example, if the team can normally do about 5 PBIs per sprint, the team grooms its backlog to always have about 10 to 15 PBIs ready to go at any point in time. This extra inventory ensures that the pipeline won’t run dry, and it also provides the team with flexibility if it needs to select PBIs out of order for capacity reasons or other sprint-specific constraints (see Chapter 19 for a deeper discussion of this topic).