The emphasis should be on why we do a job.

—W. Edwards Deming, Paraphrased from The New Economics for Industry, Government, Education [1]

ART and Solution Train Backlogs

The ART Backlog is a Kanban system that is used to capture and manage the features and enablers intended to enhance the solution and extend its architectural runway.

The Solution Train Backlog is a Kanban system that is used to capture and manage the capabilities and enablers intended to enhance the large solution and extend its architectural runway.

The ART and Solution backlogs capture the Solution’s upcoming Features, Capabilities, and Nonfunctional Requirements (NFRs). Managing the backlog is a critical economic driver for trains and the portfolio. Product Management has responsibility for the ART Backlog, while Solution Management is responsible for the Solution Train Backlog. These backlogs are visualized and managed in Kanban systems, where features, capabilities, and enablers are captured, defined, evolved, and prioritized to ensure a continuous flow of value to Customers.

Details

Product and Solution Management develop, maintain, and prioritize the ART and Solution Train backlogs. They actively collaborate with stakeholders, including Customers, Business Owners, Product Owners (POs), System and Solution Architects, and others (for example, RTEs/STEs) to discover the features and capabilities needed to advance the solution.

Figure 1 illustrates a view of the ART and Solution Train backlogs with their primary input sources:

1) Portfolio Epics split into features or capabilities
2) Capabilities and enablers arising from the Solution Train’s local context
3) Solution Train capabilities split into features and enablers
4) Features and enablers created from the ART’s local context

Figure 1. Input sources for the ART and Solution Train Backlogs
Figure 1. Input sources for the ART and Solution Train Backlogs

An effective solution must meet all its functional and Nonfunctional Requirements (NFRs). NFRs shown at the bottom of the backlog in Figure 1 serve as constraints or restrictions across the backlog, affecting the solution’s design and performance. They are typically captured in acceptance criteria or as part of the definition of done (DoD). NFRs are persistent qualities, and ARTs often revisit them as part of the DoD.

Building and Refining the Backlog

Product and Solution Management take a continuous, flow-based approach to refine their backlogs, ensuring features and capabilities are ready for implementation within the appropriate level of discovery and risk. Refining the ART and Solution Train backlogs to ensure readiness often involves the following activities:

  • Discovering new features and capabilities
  • Reviewing and updating backlog item definitions, including developing acceptance criteria and benefit hypothesis
  • Identifying the enablers required to support new features and capabilities
  • Applying Behavior-Driven Development (BDD) techniques to help clarify features and capabilities or holding specification workshops
  • Prioritizing the backlogs using Weighted Shortest Job First (WSJF) in collaboration with Business Owners, System Architects, POs, and other stakeholders, such as RTEs/STEs
  • Briefing Agile Teams and stakeholders about upcoming features and capabilities for PI Planning
  • Deleting aging and no longer relevant items

Refinement activities often occur during the PO Sync, where Product Management and Product Owners identify new backlog items, revise others, and remove obsolete items. A well-maintained backlog is a prerequisite for a successful PI planning event and execution.

Managing the Backlog with Kanban

The ART and Solution Train Kanban system facilitates the flow of Features and Capabilities through the Continuous Delivery Pipeline. Figure 2 illustrates a typical ART Kanban with example policies and WIP limits governing each state. While this is a good starting point, the system should be adapted to fit the train’s needs, including the definition of WIP limits and the specific policies for each state.

Figure 2. A typical ART or Solution Train Kanban system
Figure 2. A typical ART or Solution Train Kanban system

The following process states describe the example ART and Solution Train Kanban flow.

Funnel – All new big ideas are welcome here, typically expressed as Features or Capabilities. These ideas may indicate needed new functionality, enhancement of the existing system functions, or Enablers.

Analyzing – New ideas that align with the Solution Vision and Strategic Themes are further explored by Agile Teams when they have available capacity. Analyzing includes Continuous Exploration activities (e.g., Customer Centricity, Design thinking) and collaboration to create one or more well-formed features (see backlog refinement above). The WIP limit for this state considers the availability of Product and Solution Management, the capacity of teams, and other subject matter experts.

Ready – The highest-priority features analyzed and approved by Product Management or Solution Management advance to this state. They are prioritized with WSJF relative to the rest of the backlog and await implementation.

Implementing – Features are pulled into the Implementing state as teams start working on them. Teams implement them throughout the PI.

Validating On Staging – The validating on staging step has two sub-states, In Progress and Ready: 

  • In Progress – Features that are implemented and ready for feedback get pulled into this state. Teams integrate and test them with the rest of the system in a staging environment and present them for approval.
  • Ready – Approved features move to this state’s ‘Ready’ buffer, where they are prioritized again using WSJF to await deployment.

Deploying To Production – The deploying to production step also has two sub-states, In Progress and Ready:

  • In Progress – Features get moved to production immediately in an automated Continuous Delivery environment or to the in-progress state for manual deployment when capacity exists.
  • Ready – ARTs that separate deployment from release move the item to the ready buffer of deploying to production to await release. In other cases, features are automatically released, and users can immediately access them. This state is WIP limited to avoid the buildup of deployed—but not yet released—features.

Releasing – When there’s sufficient value, market needs, and opportunity, features are released to some or all customers to evaluate their benefit hypothesis.

Done – After a feature has been released and evaluated, it moves to the done state. However, new work items may be created based on customer feedback.

Managing ART and Solution Train Epics

Some ART and Solution Train initiatives are too big to be completed in a single PI. These ART or Solution Train Epics are typically identified and managed in a separate Kanban system, as shown in Figure 3. Also, some portfolio epics may require splitting into ART and Solution Train epics to facilitate incremental implementation. While mainly a local concern, these epics may impact financial, human, and other resources that might be large enough to warrant a Lean business case, discussion, and financial approval from Lean Portfolio Management (LPM). Epics that exceed the portfolio epic threshold require review and approval. This is a critical Guardrail on budgetary spending.

The primary purpose of this Kanban system is to analyze and approve ART and Solution Train epics, splitting them into features or capabilities that will be further explored and implemented using the ART or Solution Train Kanban. These Kanban systems may not be required depending on how frequently ART and Solution Train epics occur in the local context.

Figure 3. A typical ART or Solution Train Epic Kanban
Figure 3. A typical ART or Solution Train Epic Kanban

The process states in the ART or Solution Train Epic Kanban are like the Portfolio Kanban, for example:

Funnel – All big initiatives are welcome in the ‘Funnel’ state. There is no WIP limit.

Reviewing – Subject Matter experts (SMEs) and stakeholders review the epics and prioritize them using WSJF and other criteria to determine which ones should move on for more in-depth exploration. If the item exceeds the portfolio epic threshold established by LPM, they move to the Portfolio Kanban. The WIP limit for this state considers the availability of SMEs.

Analyzing – During this exploration state, SMEs and stakeholders do the following types of analysis:

  • Refine size estimates, and WSJF relative to other epics
  • Consider solution alternatives
  • Identify possible Minimum Marketable Features (MMF) or Minimum Viable Products (MVPs)
  • Forecast the costs, and identify technology, architectural enablement, and infrastructure using a Lean business case (described in the epics article)

Guided by analysis and insights, Product and Solution Management and Business Owners (and LPM where required) approve or reject the epics. Approved epics are split into features or capabilities and moved to the ART or Solution Train Kanban funnel, where they will be prioritized based on WSJF. WIP limits apply to the analyzing state.

Like the portfolio Kanban, ART and Solution Train epics typically require Epic Owners to help define, explore, and implement them.

Balancing Value Delivery and Solution Health with Capacity Allocation

Every train needs to balance the backlog of business features or capabilities with continuous investment in enablers to build and maintain the architectural runway, avoiding velocity reduction and technology obsolescence. Further, these enablers support exploring requirements and applying design thinking for future PIs, creating prototypes and models, and enhancing visibility into opportunities and problem areas.

The collaboration during WSJF prioritization is often sufficient to communicate concerns and arrive at a good balance of work. When that approach is insufficient, Product and Solution Management may work with Architects to apply capacity allocation to decide how much of the total effort the ART will reserve for each activity type for the upcoming PI. Figure 4 illustrates an example of capacity allocation.

Figure 4. Example capacity allocation for a PI
Figure 4. Example capacity allocation for a PI

While the agreed-to capacity allocation can persist for several PIs, it should be periodically reviewed and adjusted during backlog refinement in preparation for PI planning.

Learn More

[1] Deming, W. Edwards. The New Economics for Industry, Government, Education. The MIT Press, 2018.

Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley Professional, 2020.

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

Reinertsen, Donald G. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 9 October 2023