Program and Solution Backlogs

The emphasis should be on why we do a job.

—W. Edwards Deming

The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the Enabler features necessary to build the Architectural Runway.

The Solution Backlog is the holding area for upcoming Capabilities and enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Product Management has responsibility for the Program Backlog, while Solution Management is responsible for the Solution Backlog. The items in these backlogs result from research activities and active collaboration involving various stakeholders—Customers, Business Owners, Product Management, Product Owners, System and Solution Architects/Engineering, and more.

The backlog items are managed through their respective Program and Solution Kanban systems. The work travels through the states of ‘funnel’ and ‘analyzing,’ with the highest-priority features and capabilities, after being sufficiently elaborated and approved, then moving to the ‘backlog’ state. There, these items are prioritized relative to the rest of the backlog and await implementation.

Effectively identifying, refining, prioritizing, and sequencing backlog items using Weighted Shortest Job First (WSJF) is the key to the economic success of the solution. Since the backlog contains both new business functionality and the enablement work necessary to extend the architectural runway, a ‘capacity allocation’ is used to help ensure immediate and long-term value delivery, combined with adequate velocity and quality.

Details

The program and solution backlogs are the repositories for all the upcoming work that affects the behavior of the Solution. Product and Solution Management develop, maintain, and prioritize the program and solution backlogs, respectively. The backlogs are essentially short-term holding areas for features and capabilities that have gone through their respective Kanban systems and been approved for implementation. Backlog items are estimated in story points, as Figure 1 illustrates.

The diagram shows a stack of seven layers with an oval at the bottom labeled NFRs representing the program backlog. Except the fourth layer, all the other layers are shown in blue. The fourth layer is shown in red. In the exploded view, the layers in blue read, feature (40) and the layer in red reads, enabler (100).

Figure 1. Exploded view of Program Backlog, with story point size estimates

Refining the Backlog

ARTs and Solution Trains maintain a steady 8- to 12-week Program Increment (PI) cadence of planning, execution, demo, and Inspect and Adapt (I&A) events. This regular rhythm is the heartbeat that drives backlog readiness as well. Appearing at a Pre-PI Planning or a PI Planning without a well-elaborated backlog adds unacceptable risk to the upcoming PI.

The time between PI planning events is a busy time for Product and Solution Management, as these managers are always in the process of refining their backlogs in preparation for the next PI planning. Making this process visible and achieving backlog readiness for the upcoming PI are the primary purposes of the program and solution Kanbans.

Backlog refinement typically includes the following activities:

• Reviewing and updating backlog item definitions and developing acceptance criteria and benefit hypotheses

• Working with the teams to establish technical feasibility and scope estimates

• Analyzing ways to split backlog items into smaller chunks of incremental value

• Identifying the enablers required to support new features and capabilities and establishing their capacity allocation

Prioritizing the Backlogs

Prioritizing the program and solution backlogs is a critical economic driver for the solution. To this end, Product and Solution Management use the WSJF prioritization method for job sequencing. To recap, WSJF ultimately translates to a simple formula, shown in Figure 2.

Figure 2. A formula for calculating WSJF

Preparing for PI Planning

The week or two before PI planning is a hectic time. Product and Solution Management personnel do the final backlog preparation, update the vision briefings, and work with Product Owners to further discuss the backlog before the event. System and Solution Architect/Engineering personnel update enabler definitions and models and often develop use cases that illustrate how the features and capabilities work together to deliver the end-user value.

Optimizing Value and Solution Integrity with Capacity Allocation

One challenge that every ART and Solution Train faces is how to balance the backlog of business features and capabilities with the need to continuously invest in the architectural runway, provide time for exploration of requirements and design for future PIs, and create prototypes and models to enhance visibility into any problem areas. To avoid velocity reduction and to defer the need for wholesale replacement of components due to technological obsolescence, ARTs must invest continuously in implementing the enablers of the solution. This complicates the prioritization of work, as different people may pull the teams in different directions (see Figure 3).

A stack of four layers (blue) on the left read, feature. Next, to the stack, product and solution management icon is shown. A stack of seven layers with an oval below the stack labeled “NFRs” at the center represents the program backlog. Next, to the program backlog, system and solution architect/engineering icon is shown. A stack of four layers (red) on the right read, enabler. A question mark symbol is shown above the stacks on the left and right. A thought bubble pointing to the product and solution management reads, “if we let the Architects have their way, they’ll re-architect this thing until hell freezes over, and then we’ll all be out of a job.” A thought bubble pointing to the system and solution architect/engineering reads, “if we let product and solution management have their way, they’ll make us band-aid this thing until hell freezes over, and then we’ll all be out of a job.”

Figure 3. Business versus enabler backlog items dilemma

To address this problem, teams apply capacity allocation—a process by which they decide how much of the total effort can be used for each type of activity for an upcoming PI. Further, they agree to determine how the work is performed for each activity type. Examples of the results are given in Figure 4 and Table 1.

The figure shows a pie chart divided into two sections. Three-quarters of the pie chart is shown in blue and it represents new features, and the other quarter of the pie chart is shown in red and it represents enablers. A stack of 10 layers representing program backlog is shown. The top three layers are shown in red. A line from the layers points to the enablers portion of the pie chart and another line points to the System and Solution Architect/Engineer (Design Authority) WSJF Prioritization icon. The bottom seven layers are shown in red. A line from the layers points to the new features portion of the pie chart and another line points to the Product and Solution Management (Content Authority) WSJF Prioritization icon.

Figure 4. Capacity allocation for a single PI

 

• At each PI boundary, we agree on the percentage of resources to be devoted to new features or capabilities versus enablers.

• We agree that System and Solution Architects/Engineering have authority to prioritize enabler work.

• We agree that Product and Solution Management have authority to prioritize business backlog items.

• We agree to jointly prioritize our work based on economics. We agree to collaborate on sequencing work in a way that maximizes customer value.

Table 1. Sample policies for managing enabler and feature capacity allocation

While the agreed-to policies can persist for some time, the amount of capacity allocated should change periodically based on the context. In the context of an ART, this decision can be revisited as part of backlog refinement in preparation for each PI planning session, while Solution Management and Solution Architect/Engineering make similar choices for the solution as a whole before pre-PI planning.

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

At this point, we’ll take a brief detour to discuss the relationships among a backlog, wait times, and flow. Principle #6, Visualize and limit WIP, reduce batch sizes, and manage queue lengths, explains these relationships in detail. We’ll summarize that discussion here, because the program and solution backlogs can have the most significant impact on delivery time and throughput:

• Little’s law illustrates 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 (see Figure 5). Thus, the longer the queue, the longer the wait time, and the higher the variability.

  

  Figure 5. Little’s law

• Think of the line at Starbucks: If each of the 10 people ahead of you orders a tall coffee, you are going to be out of there in minutes. If each buys an extra-hot vanilla latte and a toasted bagel, you might be late for your meeting. Ultimately, the outcome is not under your control.

• Long queues are all bad, causing decreased motivation, poor quality, longer cycle times, higher variability (think Starbucks), and increased risk [2] (Figure 6).

A rectangular box titled “long queues: all bad” is shown. A block labeled “long queues create” is shown within the box, on the left. Five arrows from the block point to five smaller sub-blocks on the right that read, longer cycle times, increased risk, more variability, lower quality, and less motivation.

Figure 6. Long queues are bad

Your program and solution backlogs are not queues, as some items can leapfrog others for faster delivery, and you can always choose not to service everything in the backlog. (Note that neither of these tactics works at Starbucks.)

However, if all 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 will have to wait for service. Of course, if they have to wait too long, they are likely to seek out another coffee shop, as your shop just can’t meet their rapidly changing market needs.

For this reason, teams must actively manage their backlogs and keep them short so that the development program is both fast and responsive. Teams also must limit their commitment to longer-term work, because some other item may come along that’s more important than a prior commitment. If a team has too many fixed and committed requirements in the backlog, it cannot respond quickly, no matter how efficient the team members are.

Teams can be both reliable and fast only if they actively manage the 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.