The emphasis should be on why we do a job.

– W. Edwards Deming

Queues delay feedback, and delayed feedback leads to higher costs.

– Donald Reinertsen

Program Backlog Abstract

The Program Backlog is the single, definitive repository for all the upcoming work anticipated to advance the Agile Release Train solution. Like the Team Backlog, it contains all the work under consideration—if a thing is in there, it might get done; if it isn’t, then it isn’t going to happen. While the backlog consists primarily of future features intended to address user needs and deliver business benefits, it also includes new architectural features required to build the architectural runway necessary to host the upcoming feature backlog. Defining and maintaining this backlog is the responsibility of the Product Managers affiliated with the train. Determining the capacity allocation for feature development versus architectural work is a responsibility shared between the system architect and product managers.

Effectively prioritizing this backlog is the key to economic success of the program. To this end, the Framework assumes that the features will be prioritized (and re-prioritized) at planning boundaries using the lean Weighted Shortest Job First (WSJF) prioritization method. Since WSJF has a significant time-based component, this technique provides the best mechanism for feature sequencing, which in turn drives the best possible program return on investment.

Details

The Program Backlog is the single, authoritative source of work for a single Agile Release Train. Contents of the program backlog are managed and prioritized under the auspices of Product Management (or a like function in the enterprise). The program backlog represents a short term holding stage, for the itemized features that are derived from the Program Vision. In that sense, the program backlog is just another representation of the vision, nearer term, tighter focused, and converted to specific Features that are ready for implementation. The program backlog is estimated in Story points as Figure 1 illustrates.

Figure 1 Exploded view of program backlog, with point sizing estimates

Inputs to the Program Backlog

The inputs to the program backlog come exclusively from the Program Vision, which in turn has a number of diverse stakeholder sources as illustrated in Figure 2. These include the features derived from the guiding Investment Theme strategy, Portfolio Epics, customer/value stream feedback, Architectural Features, and Agile Team inputs. Each of these sources is discussed further in Vision.

Figure 2 Sources of Vision and Program Backlog input

Backlog Grooming

Each agile release train runs a steady 8-10 week cadence of planning-implementation-demo/release-inspect and adapt. This steady rhythm is the heartbeat that drives program backlog readiness as well. Appearing at a PSI Planning session without a well-elaborated backlog is a cardinal sin in SAFe, and embarrassing to boot. To this end, the time between PSI planning events is also a busy time for product management and System Architects, as they are constantly in the process of “grooming” the backlog in preparation for the next session. Backlog grooming typically includes:

Reviewing and updating feature definition
Establishing feature acceptance criteria
Analyzing ways to split features into smaller chunks of incremental value (small features go through the system faster)
Working with the teams during their backlog grooming sessions to establish implementation estimates
Determining the Architectural Features spawned by the new features backlog, and establishing the capacity allocation (see below)

Backlog Prioritization

Prioritizing the backlog is a key economic driver for the program. To this end, Product Managers use the lean Weighted Shortest Job First prioritization method for job sequencing. To recap, WSJF ultimately translates to a simple formula:

Applying the formula requires that the numerator items be ranked only on a relative basis to each other. For any jobs that are already underway however, the denominator however should represent only the remaining job size. If the remaining work on the feature (job) cannot make the cut relative to other features in the backlog, then the feature can be called “good enough”, and the teams can move on to other priorities. This implicitly implements Reinertsen’s (Ref [2]) key economic Principle E17: The sunk cost principle: Do not consider money already spent.

Preparing for Release Planning

The week or two prior to PSI/Release planning is a very busy time as well. Product managers do their final backlog preparation, update the vision briefings and work with Product Owners to socialize the backlog prior to the event. System architects update their Analysis Models, architectural feature definitions, and develop explanatory use cases, which illustrate how the features work together to deliver the end user value.

Optimizing Value Delivery and System Health with Capacity Allocation

One of the challenges every program faces is how to balance the backlog of user features with the need to continuously invest in Architectural Runway. In order to avoid velocity reduction and to defer the need for wholesale replacement of the system due to technologic obsolesce, agile teams must invest continuously in evolving the architectural features of the solution This complicates the challenge of prioritizing work as the product managers are constantly striving to deliver new business features to the market. Occasionally, these two perspectives can create a bit of a dilemma, as Figure 2 illustrates:

Figure 3. Features vs architectural runway dilemma

Fortunately, we have other tools that can address this problem. In KANBAN, Anderson [3] notes: “Once we establish WIP limits for the flow through the system, we can consider capacity allocation by work item type or class of service…capacity allocation allows us to guarantee service for each type of work received by the kanban system.” With capacity allocation, the teams simply make a policy decision as to how much of their total effort can be applied by for each type of activity. First, they decide how much capacity is to be allocated to each type for a specific period, and then secondly, the teams establish policies to determine how the work is performed for each type. The result is indicated in Figure 3.

Figure 4 Capacity allocation is a way to separate concerns, so programs can deliver the right mix of new features and architecture

Policies for managing the backlog must then be made explicit. An example appears in Table 1 below.

We agree on the percentage of resources to be devoted to new feature development vs. architecture at each boundary
We agree that the architect has design authority and prioritizes the work in that class
We agree that product management has content authority and prioritizes new feature work
We agree to jointly prioritize our work based on economics
We agree to collaborate so as to sequence work in a way that maximizes customer value

Table 1: Sample policies for managing architecture and feature capacity allocation

While the agreed-to policies can persist for some time, the amount of capacity allocated should vary based on the context. In the context of an ART, this decision can be revisited as part of backlog grooming in preparation for each PSI.

On Backlogs, Queues, Little’s Law, and Wait Times

In Chapter 9 of reference [1], we discussed the relationship between backlogs, queues, lean flow, and Little’s Law at length. This is an important discussion, and I refer you to that for fuller understanding. However, it’s important to summarize that discussion here, because the Program Backlog is THE backlog that can have the biggest impact on delivery time and throughput. Here’s the summary in digestible form.

Little’s Law, a key tenet of lean flow, states that the average wait time for an item in a queue is equal to the average length of the queue, divided by the average processing rate for an item in a queue. The longer the queue, the higher the wait time and the higher the variability. Makes sense. (Think of the line at Starbucks, if the ten people ahead of you order a tall coffee, you are going to be out of there in minutes; if they all order an extra-hot vanilla latte and a heated bagel, you might be late for your meeting!).
Long queues are all bad, causing decreased motivation, poor quality, longer cycle times, higher variability (think Starbucks) and increased risk (Ref [2]).
Your Product Backlog is not a queue, as items can leapfrog others for faster delivery, and you can always choose not to service everything in the backlog. (Neither of these work at Starbucks).
HOWEVER, if the items in your backlog are committed to stakeholders, then your backlog behaves like a queue, and the longer it is, the longer your stakeholders are going to have to wait for service. And if they have to wait too long, they will find another coffee shop, as your shop just can’t meet their rapidly changing market needs.

So in order for your development program to be fast and responsive:

Actively manage your backlog and keep it short. Don’t commit to longer term work in advance of doing the work, because some other item may come along that’s more important than your prior commitment. But if your commitment is your bond, you cannot respond quickly. Sure, you might be reliable, because you do what you committed to, but you might be too slow to compete. You can be both reliable and fast only if you actively manage your backlog and keep it short.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[3] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.

Last update: 24 March, 2013