SAFe 3: Program Backlog Construction

The scaled agile framework (SAFe) enables organizations to transform business needs into working software in a consistent, repeatable way, using lean principles. It’s useful to think of this process as one of continuous and progressive refinement of business requirements until discrete items of value can be accepted by delivery teams for implementation. This is accomplished via a set of transformations through SAFe’s operating levels.

A program backlog is a ranked list of features required for delivery in a product release, (aka program increment or PI in SAFe jargon). This backlog is primarily derived from the Portfolio Backlog, however features from other sources could be added directly. Construction of a program backlog is intended to be a continuous process (vs. a single big-bang planning event), and runs concurrently with the execution of the current PI. The target feature set for the next PI should be in the ready state well ahead of the next PI planning event. The amount of time and effort required for the PI event will depend entirely on the degree of readiness of this feature set. The Program Backlog construction and refinement process can be managed effectively using a program kanban, where different levels of feature refinement are reflected in a series of workflow states, each showing more detail than the previous one, until the final state contains features that are considered ready for pulling into a program for translation into working software.

Getting to a committed feature set for a release or PI is a 2-part process:

• Feature Intake and Refinement (Step 2a in the above diagram): output is a ranked list of ready features targeted for the next PI. (Ideally deep enough to supply enough features for at least 1.5 PI’s).
• PI/Release Planning Event (Step 2b in the above diagram): output is a reconciliation of both dependencies and software production capacity to understand how much can be actually committed in the forthcoming PI.

The focus of this article will be on the first part of this process.

Program Backlog Refinement Process

Just as teams need to hold regular backlog refinement sessions to get user stories sufficiently refined to meet a definition of ready, the Program Backlog also needs to be refined to the point where it is amenable to elaboration of features into user stories. SAFe does not prescribe a specific workflow for program backlog refinement. What follows is one way to accomplish the refinement process using a kanban. The goal is to provide sufficient granularity about the actual state of refinement of any feature so that program teams are properly aligned and surprises are minimized. Key states in the intake workflow:

Funnel

• Placeholder for unreviewed features. Features may be pulled here from epic definitions in the epic backlog, or directly from other sources. This state is WIP-unlimited.

Business Analysis:

• Features are reviewed for alignment with strategy, product vision and customer needs, and may be rejected if not considered a good fit.
• Features are more formally defined with stated benefits and acceptance criteria.
• Features are assigned an initial ranking based on business value and estimated development effort. (Relative ranking, see WSJF Simplified).

Technical Analysis:

• Technical analysis by product architects or domain technical exsperts. Outline implementation approach identified together with any additional ‘architectural runway’ or ‘enablers’.
• Feature size estimate is updated based on additional information from technical analysis.

Ranking:

• Feature ranking determined objectively using WSJF (or other equivalent method). Basically, the numerator (business value) and denominator (feature size 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.

Backlog

• Features that 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 planned for the next PI, are considered Program Backlog items, and are now ready for consumption by delivery teams for user story creation and sizing.

The kanban used in the above discussion can be visualized as follows:

All workflow states except Funnel are WIP-limited, with WIP levels determined by the capacity of the next downstream state. The goal should be to produce a program backlog with enough ready features to supply approximately 1.5 PI’s. Details of the workflow are as follows:

This level of feature refinement should be sufficient to support a 2-day PI planning event, where on the first day, features will be elaborated into user stories and sized more accurately during team breakout sessions. I have worked with some teams who have completed story mapping/story sizing as part of the feature intake process, then requiring only a 1-day PI planning event. (For a 1-day PI planning event, you will need an additional state – Story mapping/sizing – inserted after the Tech. Review state and before Ranking state).

If you do not have a Kanban tool, simply use a spreadsheet.

The Feature Intake, (or Program Backlog refinement), process should operate continuously, say as a weekly event facilitated by a ‘Program Scrum Master’ (or, ‘Release Train Engineer’ in SAFe). Attendees should include the Product Manager (or Chief Product Owner) – the individual responsible for the Program Backlog, team PO’s and Architects. These individuals can advance  feature requests across the Kanban board by contributing increasing amounts of detail about the feature. The goal is to have at least 1.5 PI’s worth of ready features available at least a couple of weeks ahead of the next PI Planning event.

References:

• Program Backlog Construction: http://www.scaledagileframework.com/program-and-solution-backlogs/
• Feature Intake Kanban: http://www.scaledagileframework.com/program-and-solution-kanbans/
• WSJF (Simplified): http://theburndown.com/2017/01/25/wsjf-simplified/