Program and Solution Backlogs

Program and Solution Backlogs, estimated in story points, are lists (repositories) of prioritised items managed through their respective Kanban systems.

 

Program Backlog

  • Holding area for upcoming features
  • Intended to address user needs and deliver business benefits for a single ART (Agile Release Train)
  • Contains enabler features necessary to build the Architectural Runway
  • Responsibility: Program Management

 

 

Solution Backlog

  • Holding area for upcoming Capabilities and enablers
    • Each of which can span multiple ARTs
    • Intended to advance the solution and build its architectural runway
  • Responsibility: Solution Management

 

Refining the Backlog

  • ARTs & Solutions Trains run at a steady 8-12 weeks PI cadence
    • of: planning, execution, demo and I&A
  • Appearing at a Pre-PI Planning or PI Planning without a well elaborated backlog adds unacceptable risk to the upcoming PI
  • Refinement typically includes:
    • Reviewing & updating backlog item definitions and developing Acceptance Criteria and benefit hypothesis
    • Working with teams to establish technical feasibility and scope estimates
    • Analysing ways to split the backlog items into smaller chunks of incremental value
    • Identifying the enablers to support new features and capabilities and estimating their capacity allocation

 

Prioritising the Backlogs

  • Critical economic driver for the solution
  • Product and Solution management utilise WSJF prioritisation for job sequencing

 

WSJF - Weighted Shortest Job First

 

Preparing for PI Planning

  • Product and Solution Management:
    • Carry out final backlog preparation
    • Update the Vision briefings
    • Work with Product Owners to further socialise the backlog before the event
  • System and Solution Architect/Engineering:
    • Update enabler definitions and models
    • Develop use cases that illustrate how the features and capabilities work together to deliver value to the end user

 

Optimising Value and Solution Integrity with Capacity Allocation

  • Challenges for every ART and Solution Train:
    • 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
      • create prototypes and models to enhance visibility into problem areas
  • To avoid velocity reduction ARTs must invest continuously in implementing the Enablers of the solution

 

To address this problem, teams apply capacity allocation, where they decide how much of the total effort can be used for each type of activity in the upcoming PI.

 

At each PI boundary, we agree:

  • Percentage of resources to be devoted to new features or capabilities versus enablers
  • System and Solution Architects/Engineering have authority to prioritise Enabler work
  • Product and Solution Management have authority to prioritise business backlog items
  • Jointly prioritise work based on economics
  • Collaborate on sequencing work that maximises customer value

 

Backlogs, Queues, Little's Law and Wait Times

  • Program and Solution Backlogs can have the most significant impact on delivery time and throughput.
  • Little’s Law (Principle 6) 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.
  • Long queues are bad (Principle 6), causing decreased motivation, poor quality, longer cycle times, higher variability (think Starbucks), and increased risk.
  • Teams must:
    • Actively manage their backlogs and keep them short for a development program to be fast and responsive
    • Limit commitment to longer term work, since other more important items might arise

 

The Program Kanban facilitates the flow of Features through the Continuous Delivery Pipeline: