The emphasis should be on why we do a job.

—W. Edwards Deming

Program and Solution Backlogs

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 with various stakeholders—Customers, Business Owners, Product Management, Product Owners, System and Solution Architects/Engineering, and more, that are part of the Continuous Exploration process.

The backlog items are managed through their respective Program and Solution Kanban systems. The work travels through the states of ‘funnel’ and ‘analyzing’ and the highest-priority features and capabilities that were sufficiently elaborated and approved, move to the ‘backlog’ state. Then they’re prioritized relative to the rest of the backlog to 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, with 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 a short-term holding area for features and capabilities that have gone through their respective Kanban systems and have been approved for implementation. Backlog items are estimated in story points, as Figure 1 illustrates.

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

Refining the Backlog

Agile Release Trains and Solution Trains run a steady 8-12 week Program Increment (PI) cadence of planning, execution, demo, and Inspect and Adapt (I&A). 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 they 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 is one of the primary purposes of the program and solution Kanbans.

Backlog refinement typically includes:

  • Reviewing and updating backlog item definition and developing acceptance criteria and benefit hypothesis
  • 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, as shown in Figure 2.

Figure 2. A formula for calculating WSJF

Preparing for PI Planning

The week or two before PI planning is a critical time. Product and Solution Management do final backlog preparation, update the vision briefings, and work with Product Owners to further socialize the backlog before the event. System and Solution Architect/Engineering 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 of the challenges 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 the 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 challenge of prioritizing work, since different people can pull the teams in different directions, as Figure 3 shows.

Figure 3. Business versus enabler backlog items dilemma

The collaboration that occurs during WSJF prioritization is often sufficient to communicate concerns and arrive at a good balance of work. When that approach is insufficient, ARTs may apply capacity allocation, where they decide how much of the total effort will be used for each type of activity for the upcoming PI. Further, they establish an agreement to determine how the work is performed for each activity type. This can also include specific reserves for ongoing maintenance as well as reduction of any technical debt that may have accumulated. Examples of the results are given in Figure 4 and Table 1.

Figure 4. Example capacity allocation for a single PI
  • At each PI boundary, we agree on the percentage of work be devoted to new features or capabilities versus enablers.
  • We agree that System and Solution Architects/Engineering have the authority to prioritize enabler work.
  • We agree that Product and Solution Management have the 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, 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

It’s important to take a brief aside and discuss the relationship between a backlog, wait times, and flow. Principle #6, Visualize and limit WIP, reduce batch sizes and manage queue lengths, explains the relationship in detail. However, it’s important to summarize that discussion here, because the program and solution backlogs can have the most significant impact on delivery time and throughput.

Here’s a summary:

  • 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. The longer the queue, the higher the wait time, and the higher the variability.
Figure 5. Little’s Law

Think of the line at Starbucks: If the ten people ahead of you each order a tall coffee, you are going to be out of there in minutes. If each buys an extra-hot vanilla latte and a heated bagel, you might be late for your meeting, and it 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] as illustrated in Figure 6.
Figure 6. Long queues are bad

Program and solution backlogs are not queues, as items can leapfrog others for faster delivery. If, however, all the items in a backlog are committed to stakeholders, then the 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 the current shop can’t meet their rapidly changing market needs.

Therefore, teams and ARTs must actively manage their backlogs and keep them short to be fast and responsive. They must also limit commitment to longer-term work because some other item may come along that’s more important than a prior commitment. If an ART has too many fixed and committed requirements in the backlog, it cannot respond quickly, no matter how efficient it is.

Teams and ARTs 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.

Last update: 10 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.