Topics covered:
- The role of the ART Backlog.
- ART Backlog Refinement and PI Planning Readiness.
- ART Backlog Ranking using WSJF.
The Role of the ART Backlog
An ART Backlog is a stack-ranked list of deliverables – product features and supporting technology infrastructure items targeted for the next PI. In preparation for PI Planning, backlog items must be sufficiently refined and stack-ranked by business value. The ART Backlog is the single source of work for the Agile Release Train (ART). The ART Product Manager is responsible for creating and managing the ART Backlog.
The ART Backlog may be derived from multiple sources including a Portfolio Backlog or a product strategy (sometimes laid out as a Product Roadmap). Ultimately, everything in the ART Backlog exists to support the realization of the Product Vision.
The time and effort needed for PI planning will depend on the refinement of this backlog. This is a critical step for PI Planning success and will be the focus for this chapter.
The general flow from Product Vision to Product Backlog can be represented as:
For our purposes we will use the following definitions:
Product Vision: The ultimate solution we want to provide for customers. The Product Vision describes a future state of the product which can serve as a target for the ART to plan against. Those things needed to realize the Product Vision are reflected in the ART Backlog.
Strategic Themes/Product Roadmap: Strategic Themes communicate how the Vision will be realized. A Product Roadmap is sometimes used to communicate priorities and sequencing of product objectives. Specificity is tailored to the time horizon. Strategy/Roadmap can be used to set priorities and to align stakeholders.
Portfolio Backlog: A set of prioritized initiatives (epics) that support the strategy and reflects the investment allocation across all the Value Streams in the portfolio. The Portfolio Backlog, and the role of portfolio epics in supporting strategy is addressed in the Lean Portfolio Management core competency.
ART Backlog: There is one ART backlog for each Value Stream in the portfolio. (Exception: very large value streams may need multiple ARTs). An ART Backlog contains a list of everything needed to deliver on the initiatives (epics) in the portfolio backlog. ART Backlog items reflect the elaboration of epics into features and technology enabler items, that is, solutions for the goals and objectives stated in the Portfolio Backlog. The ART backlog contains the highest priority items needed in the next PI to support the strategy. ART Backlog items will have been refined and stack ranked as a prerequisite step to support PI Planning.
One can see that solution delivery flows through a series of interconnected backlogs from strategy to delivery, from epics to features to user stories.
ART Backlog Refinement
There is no single best way for refining the ART Backlog, however SAFe does recommend an approach based on an Intake Kanban. What follows is one example.
The goal is to provide a continuous flow of ready work to the ART Backlog. Features that evolve to the ART Backlog state are considered sufficiently well-defined for PI Planning.
Key states in the intake workflow:
Funnel: Initial placeholder for proposed features. Features may be pulled here from epic definitions in the Portfolio Backlog, or directly from other sources.
Business Review: Features are reviewed for alignment with strategy, product vision and customer needs, and may be rejected if not considered a good fit. Upon exit from this state features should be more formally defined with stated benefits and acceptance criteria. Features are given an initial ranking relative to other features in the backlog based on business value and estimated development effort. (More below).
Technical Analysis: Technical review and analysis led by the System Architect. An outline implementation approach is identified together with any additional ‘architectural runway’ or ‘enabler’ items. Feature size estimate is updated based on additional information from technical analysis. Omission or skimping of this step can lead to serious problems in the execution of the PI. Teams need to be able to hit the ground running once the PI commences, and not be required to invest large amounts of time in solving major architectural questions during the PI.
Ranking: Feature ranking is determined objectively using Weighted Shortest Job First (WSJF, or other equivalent method). Basically, the numerator (business value and other factors) and denominator (feature size or cost estimate) are both estimated relative to all other features in the backlog using Fibonacci. The resulting rank is calculated as the ratio of business value / size (cost).
ART Backlog: Features have completed all workflow steps, and are fully defined with benefits, acceptance criteria, and architectural dependencies, and have been ranked with respect to all other features in the ART Backlog. These features are considered ART Backlog items, and ready for PI Planning.
Just as delivery teams continuously refine their backlogs ahead of sprint planning, ART Backlog refinement is intended to be a cadenced event (vs. a single big-bang planning event) that runs throughout the PI cycle. The event is led by the Product Manager. Attendees should include all team PO’s, Architects and business stakeholders who can contribute to moving feature requests across the Kanban board by contributing increasing amounts of detail about each feature. The goal is to have at least one PI’s worth of ready features available at least 2-4 weeks ahead of the next PI Planning event.
Features that have made it all the way to the ART Backlog state, should have the following information:
Benefits. Spelling out benefits helps ensure that delivery teams understand the actual value is being provided to the user. For example, the benefit of a smartphone feature, ‘Favorites’ might be to make it unnecessary for a user to search through a long list of contacts, making the process faster and more convenient.
Acceptance Criteria. Acceptance criteria are recommended for all levels of requirements (epics, features, stories). They should provide an unambiguous definition of expected behavior of the feature and serve to delineate the scope boundary of what is required or not required. Both functional and non-functional (e.g., performance) requirements should be defined.
Architectural Runway Needs. It is important to spell out any architectural or technical infrastructure prerequisites required to support the feature. This also acts as a check to confirm that these topics have been reviewed and agreed to as part of the feature refinement process.
Feature Template Example:
| Feature | High Quality Product Images |
| Description | Provide high resolution product images from multiple perspectives |
| Benefits | Good quality images are a key determinant to move products on eCommerce websites and increase conversion rates and sales. |
| Acceptance Criteria |
|
| Value Driver | Increase revenue per visitor |
| KPI | Conversion Rate |
ART Backlog Ranking With WSJF
ART Backlogs should be stack-ranked – not simply prioritized. This is all about realizing the highest value at the earliest opportunity and minimizing work in progress. Many product owners and their teams simply prioritize features as High, Medium, or Low priority. Inevitably, we frequently end up with multiple high priority features, which offers little guidance on delivery sequencing. This results in teams having multiple backlog items in progress at the same time which can delay getting any individual feature to done. Further, it also delays getting feedback from users and stakeholders on finished work, which impedes the ability to iterate, adapt and continuously innovate. Limiting WIP by having an objectively ranked and sequenced backlog is the key to optimal delivery lead times.
By adopting the practice of rank-ordering the ART Backlog, the team has total clarity about which item they should be working on. When work on the highest ranked item is done, the team moves to the next item on the list. When things change, resulting in re-ranking items or even adding new ones, that is not a problem because the team can finish the current item and now has the flexibility to start working on something else.
Feature ranking is done on a relative basis against other features in the backlog. One technique for doing this is Weighted Shortest Job First (WSJF). WSJF is basically a scheduling algorithm that strives to ensure features of highest value and lowest cost (lowest consumption of development capacity) are ranked highest for delivery.
Weighted Shortest Job First (WSJF) Ranking
Weighted Shortest Job First (WSJF) is a technique first popularized by Don Reinertsen in his book: The Principles of Product Development Flow. It provides a method to prioritize a list of features or initiatives in an objective way based on business value and relative return on investment. Each feature is scored based on its Cost of Delay divided by its size or development effort.
How is WSJF calculated?
WSJF = Cost of Delay (COD)/Effort, where
- COD = Business Value + Time Criticality + Risk Reduction Opportunity
- Rank = COD/Effort
WSJF parameters for each feature are scored relative to all other features using the Fibonacci Series (1, 2, 3, 5, 8, 13 …):
The underlying rationale for WSJF is 2-fold:
- Prioritize work that has the highest cost of delay or highest overall value in terms of business value, time criticality and risk reduction.
- When all jobs have the same delay cost, or same overall value, do the one with least effort first (The fastest way to realize value).
ART Backlog Creation Checklist
ART Backlog Creation Checklist
|
With an ART Backlog comprising a ranked list of ready features, we are now ready for PI Planning.
For more, download the eBook: Agile Delivery at Scale with SAFe.
eBook Contents:
- Chapter 1. Introduction to the Scaled Agile Framework. This provides an overview of the SAFe framework.
- Chapter 2. Organizing for scaled delivery. Describes the organizational prerequisites for successful SAFe adoption.
- Chapter 3. Constructing an ART Backlog. The ART Backlog is the starting point for PI Planning. This chapter describes how to create a backlog that is aligned with product vision and strategy and has product features sufficiently well-refined to support PI Planning.
- Chapter 4. PI Planning Step-By-Step, takes you through each of the basic steps of planning a PI.
- Chapter 5. PI Execution Practices explains the essential roles, practices, and artifacts necessary for successful execution and delivery throughout a PI.
