The emphasis should be on why we do a job.

—W. Edwards Deming


Program and Solution Backlogs

The Program Backlog is the final state in the Program Kanban, which is also the last state of Continuous Exploration. It’s the holding area for a prioritized list of Features that have been analyzed and 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 solution Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Managing the backlog is the responsibility of Product Management (program backlog) and Solution Management (solution backlog). The items in the backlog result from research activities and an active collaboration with various stakeholders—Customers, Business Owners, Product Management, Product Owners, Architects, and more. The backlog items travel through the Kanban states of funnel and analyzing. 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, capacity allocation is used to help ensure immediate and long-term value delivery, with velocity and quality.


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 the program and Solution Kanbans 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 steady 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. To this end, the time between PI planning events is a busy time for Product and Solution Management, as they are constantly in the process of refining the 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 ART and solution Kanbans. Backlog refinement typically includes:

  • Reviewing and updating backlog item definition and developing acceptance criteria
  • Working with the teams to establish technical feasibility and scope estimates
  • Analyzing ways to split backlog items into smaller chunks of incremental value
  • Determining the enablers spawned by new features and capabilities, and establishing their capacity allocation

Prioritizing the Backlogs

Prioritizing the backlogs is a key 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 below.

Applying the formula requires that the numerator items be ranked only on a relative basis to each other. The denominator, job size, can be either a relative measure or an estimate in story points. (Note: The actual denominator of WSJF is job duration, though we use job size as a proxy. This is because duration depends on who does the work and what capacity allocation they can give the new work; that can be almost impossible to determine in advance of allocating the work. Since large jobs typically take longer to do, job size is a reasonable first approximation.)

With respect to job size, the denominator should represent only the remaining work for any items already under way. Then, if the remaining work for the item is too large to justify further investment relative to other jobs, the item can be called good enough, and the teams can move on to other priorities. This implicitly implements Reinertsen’s key economic “Principle E17: The sunk cost principle: Do not consider money already spent [2].”

Preparing for PI Planning

The week or two prior to PI planning is a very busy time. Product and Solution Management do final backlog preparation, update the vision briefings, and work with Product Owners to further socialize the backlog prior to 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. In order 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 2 shows.

Figure 2. Business versus enabler backlog items dilemma

To address this problem, teams apply capacity allocation, whereby they make a decision about how much of the total effort can be applied for each type of activity for an upcoming PI. Further, they establish an agreement to determine how the work is performed for each activity type. Examples of the results are given in Figure 3 and Table 1.

Figure 3. Capacity allocation for architecture in an Agile Release Train backlog for a single Program Increment
  • At each Program Increment 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 and 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 so as to sequence 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 vary over time 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 decisions 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 backlog, wait times, and flow. The principle, manage queue length, discusses the relationship in detail (refer to that article for more complete understanding). However, it’s important to summarize that discussion here, because the program and solution backlogs are the backlogs that can have the biggest 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. (Think of the line at Starbucks: If the 10 people ahead of you each order a tall coffee, you are going to be out of there in minutes. If each orders 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].
  • Your program and solution backlogs are not queues, as items can leapfrog others for faster delivery, and you can always choose not to service everything in the backlog. (Note that neither of these work 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 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.

Therefore, in order for a development program to be fast and responsive, teams must actively manage the backlogs and keep them short. Teams also must limit 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, they cannot respond quickly, no matter how efficient they 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.

Last update: 20 October, 2017