SAFe PI Planning | The Burndown

“Plans are things that change” — Fujio Cho, Toyota
“Plans are worthless, but planning is everything” — Dwight D. Eisenhower
“Everyone has a plan until they are punched in the face” — Mike Tyson

PI Planning Goals
SAFe Framework Overview
SAFe Requirements Hierarchy
SAFe Program Backlog Construction & Refinement
PI Planning Formats
PI Planning Preparation
PI Planning Steps:

Align on Objectives
Breakout #1: Teams create draft plans
Plan reviews and Problem Solving
Breakout #2: Plan Updates
Finalize plans & confidence vote

PI Planning Goals

The primary purpose of PI Planning is to gain alignment between business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next PI time-box.

SAFe Framework Overview

The scaled agile framework (SAFe) enables organizations to transform business needs into working software in a consistent, repeatable way, using lean and agile principles. It’s useful to think of this process as one of continuous and progressive refinement from business requirements to user stories that can be accepted by delivery teams for implementation. This is accomplished via a set of transformations through SAFe’s operating levels. If your product requires 10 or less teams to build and support, then 3-level SAFe is sufficient for your needs. The overall framework may summarized as follows:

Simplified Big Picture — Simplified Scaled Agile Framework Big Picture

Each level of the framework represents a transformation into a level of detail required for processing at the next level. Within each level, the transformation process is managed using a Kanban to ensure transparency and optimal flow:

Portfolio Level – Portfolio Management is the highest level process that starts the refinement of business strategy into epics, and from there into features that can be realized by delivery teams. A product portfolio is the collection of all the products or services offered by a company. In SAFe, portfolio items are represented as ‘epics‘, that is, they may require multiple releases (or program increments) to realize the vision and goals for that product. Epics are basically ‘containers’ for everything needed to provide a solution. Each epic should have an MVP definition (minimum feature set). Epics need to be ranked (and funded) by business value. Epics in the business portfolio are refined via an intake Kanban (e.g. Funnel >> Review >> Analysis >> Ready).
Program Level – How do we quickly and incrementally deliver meaningful subsets of each epic to the market? To do this, an epic’s MVP feature set is refined further via story mapping and story estimation. Team velocities are used to estimate the scope of what can be delivered in program increments. Program Increments (PI’s) are standardized around 5 two-week iterations, plus one ‘Planning & Innovation’ Iteration, 12 weeks in all.
Team Level – A set of practices that support incremental feature delivery via short iterations – typically using Scrum– with production-level quality. Once the feature delivery timeline and business objectives are agreed for the next PI time-box, teams work on their feature-sets, collaborating on mutual dependencies, and synchronizing the results of their work on each iteration boundary. The scrum-of-scrums event is used to track progress across the release train, and to adjust plans where necessary to ensure the most important PI objectives are achieved.

PI’s (Program Increments) and ARTs (Agile Release Trains)

ART’s are a scaling arrangement where multiple value stream-aligned development teams plan and execute together.
Optimized for 5-12 teams (50-125 people).
Operate in 5-6 sprint (10-12 week) time-boxes known as Program Increments (PIs).
PI Planning is a 2-day event in the last week of every PI. (Alternative arrangements possible).
A Product Manager owns and manages the Program Backlog – a prioritized list of features, which is the single source of work for the ART.
Program Backlog is mostly a list of features, but can contain other items such as milestones (e.g. trade show event), and technology ‘enablers’.
Features scoped to fit in a single PI.
Architects participate in PI Planning for dependencies, interfaces and enablers.
A Release Train Engineer (RTE) operates as ‘Chief Scrum Master’ for the ART, and facilitates PI Planning and other events to support the operation of the ART.
Teams own story planning and estimates

The SAFe Requirements Hierarchy

The following diagram summarizes the elaboration of business epics into product features and user stories.

Epics represent business initiatives that typically take multiple program increments (PI’s) to fully develop. Features represent product or service capabilities that solve specific problems at the user level, and can be delivered in a single PI. At the lowest level of granularity User Stories are things that deliver thin slices of functionality and can be delivered within the time-box of a single iteration.

SAFe Program Backlog Construction and Refinement

Where does the Program Backlog come from? The Program Backlog is a subset of the Product Backlog which is a ranked list of everything needed to achieve the Product Vision. The Program Backlog represents the next set of highest priority items from the Product Backlog targeted for the next Program Increment. In large organizations with potentially very large product backlogs it can be useful to define a strategy for realizing the Product Vision (we can’t do everything at once). This strategy can be can be represented in many ways, but the Product Roadmap is a useful tool to visualize the highest level sequence of goals and objectives believed to effectively advance the product towards the vision. Product Roadmaps comprise a sequenced set of goals, objectives and initiatives that represent what needs to be accomplished over time to make progress on achieving the vision. Product Backlogs capture the how or specific solutions for achieving these objectives. In SAFe we use Epics to represent the what, and we use Features to represent the how.

Here is a more detailed view of the basic flows:

The first stage of planning is the construction of a program backlog from which PI Planning can proceed. The program backlog is derived from the epic backlog where the scope of each epic is defined in terms of a set of features. Features can be extracted from epics and further refined in a process sometimes referred to as the feature intake process. This process is often quite ad-hoc, however we can impose a reasonable degree of discipline by managing it with a simple Kanban workflow. Initial ideas or requirements (perhaps the one-line feature definitions from the epic backlog) are captured through an intake funnel, where they are first vetted for alignment with product strategy and vision, and then for technical viability. Having done that they are then ranked by overall importance using an objective ranking process like Weighted Shortest Job First (WSJF). Imposing a defined workflow on this process removes ambiguity about the degree of readiness of each proposed feature for inclusion in the program backlog. Ultimately we want each item on the backlog to have a good definition, with clearly articulated benefits and acceptance criteria, and to have a rank based on business value, and cost of development. The following diagram illustrates a simple workflow for a feature intake process:

The first state (Funnel) is a holding area for any unrefined features. If epics have been properly defined at the portfolio level, then initial high-level features will be included as part of those epic definitions. This state is WIP-unlimited – that is there can be any number of items in this state. All of the succeeding states are WIP-constrained, that is, limited to the capacity of the next downstream activity. Moving an item from Funnel to Business Review means that the business team (Product Owners and other business stakeholders) are in the process of reviewing this item, with a view to defining it in detail (benefits and acceptance criteria), and deciding it’s initial value relative to other features in the program backlog. The next state (Technical Review) is where the technical stakeholders – architects, data analysts, UX and other required SME’s – will define a solution and implementation approach, and identify any significant technical or technology dependencies required for the implementation of the feature. This step may result in the addition of one or more ‘enabler features’ to the program backlog. These enabler features are needed to build out the so-called architectural runway for the delivery teams to build features on. The earlier the enablers are identified the better, as this will reduce the risk of discovering technical roadblocks mid-flight during the next program increment. During the technical review step a high level estimate for the level of effort or size of the feature should be made. This is needed as input to the final step which is the feature ranking step (described in detail here). Reaching the final state (Backlog) means that the feature has been reviewed and confirmed for delivery, and defined insufficient detail to support PI Planning.

Planning Formats

3 planning formats are possible. The basic steps are the same in each case.

Big Room
Virtual Big Room
Asynchronous

A major objective for PI Planning is to align an ART on goals, priorities and scope for the next Program Increment. A key advantage of the Big Room Planning approach is that we have all the answers available in one place at one time. It is also a great opportunity for face-to-face collaboration and relationship building. In recent times however, mass gatherings of this sort have been out of favor, and organizations have sought to create virtual versions of these events using collaboration and conferencing tools. Alternatives to Big Room are also sought to reduce the time and expense of flying geographically distributed teams to a centralized planning event.

Many have substituted Big Room Planning with Big Room Planning on Video in an attempt to replicate the process virtually. This requires complex logistics and orchestration, and the question arises whether there is a simpler alternative that accomplishes the same purpose. We want to have a planning framework where teams can plan as independently as possible, and where we do not need to tie the entire organization up in lengthy video conference calls. Ideally team breakout sessions can happen independently with checkpoints built in to synchronize on progress. In the example below of a distributed planning framework, steps 1, 3 and 5 are synchronization events where all teams and business stakeholders convene (a 1-2 hour conference call) to align on goals and progress. Meanwhile the team breakouts (steps 2 and 4), teams work independently to create and adjust plans. The input to the entire process is a clear set of business objectives for the next delivery cycle, and at least some initial alignment on team goals (represented by team backlogs). For example:

The first time trying out this process allow at least 1 week end-to-end. This should take place within the IP (Innovation & Planning) sprint of a PI. The process should not consume teams for an entire sprint but their delivery capacity will be reduced while the work of planning is being carried out. The entire process can be accomplished within a one-week timebox with experience.

PI Planning Inputs and Outputs

Inputs (Pre-Work):

Objectives for next PI defined (The next set of major problems to be solved to advance the Product Vision).
Objectives elaborated into features, and for each feature:
- Business review of each feature completed
- Technical analysis done, feasibility established, architecture and solution understood, enabler features identified.
- Features ranked (for example using WSJF) – single common stack for the entire program
Features sufficiently defined to support PI Planning
(A feature intake Kanban can be a useful to get this done in a consistent way).

Planning Process Steps – Scope Estimation:

Story Mapping: Features elaborated into user stories
Story Sizing: Stories roughly estimated via bulk estimation
Story Scheduling: Initial allocation of stories to sprints, taking into account team velocities and dependencies.
Feature estimates (rolled up story estimates) and feature delivery dates estimated (to nearest sprint)
PI scope set based on team velocities and feature estimates.

Outputs:

PI scope defined for next timebox
Consolidated PI plan showing feature delivery plans from all teams.
Business objectives defined (or confirmed) for the PI.
PI objectives reviewed and scored by business stakeholders
Program risks reviewed and actions identified to solidify the plan
Team and program confidence vote on the plan
Collective ownership of the plan

To summarize, the PI planning event takes as input the highest priority feature list from the program backlog, and performs sufficient analysis (story mapping, sizing and scheduling), resulting in a reasonably good commitment on what can be delivered – Features, PI objectives plus timelines – for the next program increment:

PI objectives may be expressed as a list of features and/or higher-level business objectives, but can contain other items such as milestones (e.g. trade show events), and significant technical ‘enablers’. BV (Business Value) – A score between 0-10, set by business stakeholders .
The consolidated Program Board shows the feature delivery timeline by team.

PI I&A Event

This event immediately precedes planning for the next PI. The event has 3 parts:

Demo/Review accomplishments by team from the last delivery cycle. Stakeholders score PI Objectives.
PI Retrospective
Problem-Solving Workshop.

Details here.

PI Planning Part 1: Align on Objectives for Next PI

This is the kickoff event for planning the next PI. This event should happen during the last sprint of the current cycle. Input is a Ready Program Backlog with features defined to a definition of ready (acceptance criteria, and stack-ranked by business value), and aligned with specific delivery teams. The goal for the event is twofold:

State of the Business Update from Leadership
Align on business goals and priorities for the upcoming cycle.

At this event the ART will hear state of the business update from leadership, and then a review of goals and priorities for the upcoming PI. Each team will then present their goals and priorities and confirm alignment with leadership and stakeholders. As much discussion should have already happened during the preparation stage, there should not be any major surprises at this point, but some minor adjustments may be in order.

PI Planning Part 2: Create Draft Plans (Team Breakouts #1)

The assumption at this point is that we have a Program Backlog sufficiently refined to support story writing and sizing. (Some teams may actually do story writing ahead of the planning event). PI Planning is carried out in 2 basic steps (with usually 1 day devoted to each). Each team will first create draft plans. These plans include 3 basic things: a feature delivery timeline, a set of PI Objectives, and a risk assessment. In this section we will describe the sequence of activities required to accomplish each major step. We will summarize the steps and then go through each one in detail:

Create Stories from Features
Story Size Estimates
Story & Feature Scheduling – Assign Stories to Iterations
Identify Risks and Dependencies
Align Team Deliverables with Program Objectives

Teams will separate into break-out sessions to work on these steps, using their team wallboards to capture the results of their planning work. Teams will then make a presentation of their draft plans to the entire gathering of teams and stakeholders.

1. Create Stories From Features

Sometimes known as Story Mapping, this activity involves taking a set of features and breaking each one down into small slices of functionality that can be delivered in a single sprint. It is not necessary at this stage to define stories to the extent that they meet a definition of ready – that can be done closer to the delivery sprint via the backlog refinement process.

Story Mapping Step-By-Step:

Create the “backbone” of the story map. These are the large activities or basic business process steps that the users need to carry out. Capture the end-to-end user process flow. Consider these as functional steps or ‘features’.
Start defining potential actions the user will take to accomplish each function. Some of these steps may be optional. These can be considered the ‘user stories’. (They may need to be split into smaller items later during backlog refinement).
Create the “MVP”. This is where you select a set of user stories or options that can give you the minimum end-to end value of customer experience for a viable initial solution.

2. Story Size Estimates

Since we may have a large number of stories to estimate, we need a faster method than holding a planning poker session for each individual story. One approach that can be used is estimation by linear affinity:

Affinity Estimating is good for generating initial estimates for large Product Backlogs, e.g. for PI Planning. Stories not necessarily fully defined (Ready)
Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended).
SM facilitates
PO available to take questions and clarify stories
Further refinement happens via Planning Poker later when stories are ‘Ready’

3. Story and Feature Scheduling

We now have features broken into user stories with size estimates. The next step is to allocate stories to sprints by taking into account story size (in points) and team velocity (points per iteration). In the following example, Team Vikings has 2 features, Feature 1 has 5 user stories with a total of 16 points, and Feature 2 with 4 stories and a total of 11 points. Each team will need to set up a Team Wall Board which they will use to assign stories to sprints based on priorities, dependencies and velocity. In this example, given team Vikings’ velocity is 15 points, then we can estimate that Feature 1 will be fully delivered in Sprint 2 at the earliest.

As the team continues to populate their sprints with stories, they will also begin to identify risks and/or dependencies. These should be captured on a separate sheet on their wall board for later discussion. Once all stories have been scheduled into iterations, the team should then be in a position to identify when each feature will be delivered (to the nearest iteration). This information will be used later to populate the overall Program Wall Board.

What if a team does not have an established velocity? Use capacity-based estimation via the following steps:

Estimate Team Capacity: (e.g. 5 Dev/QA/DA/UI * 10 days = 50). 50 staff-days of available capacity per iteration. Total PI capacity = 5 * 50 = 250 effort-days’
Story Discovery: Features to Stories as described in an earlier section.
Story Sizing: Stories should be 1,2,3 or 5 days of effort (split if bigger than 5 days). (Do not break stories into tasks to estimate!)
Story Scheduling:
- Assign stories to iterations based on size/capacity
- Update iteration flip-charts, reconcile load vs. capacity
- Determine when features are done (to nearest iteration)
Update the Program Board. Once each team has completed story scheduling they should have an idea to the nearest iteration when each of their features will be completed. The Program Board is intended to show the feature delivery timelines per team. This should be updated so that the program team and stakeholders have a complete program view as input to the leadership review and problem-solving session at the conclusion of PI Planning Part 1.

4. Risks & Dependencies

As teams work through the process of allocating stories to sprints and reconciling feature sizes with velocity or capacity they will inevitably discover dependencies and areas where they do not have sufficient capacity. Dependencies constitute risk in that they represent items on which the team has no direct control over. Dependencies may be on teams inside the same train, on teams outside the train, and even on teams outside the company, each representing increasing levels of risk. Teams may need to consult with other teams to get commitments on dependencies and may need to adjust delivery schedules based on these commitments. Other risks may simply be that a team has insufficient capacity to delivery everything that was asked for. In this case a team may need to de-scope features or even defer entire features. The overall risk, based on a team’s ability to resolve, or mitigate these risks will play directly into their confidence vote on their PI Plans. These risks are presented to the stakeholder team as part of their overall draft plan presentation.

5. Setting Team PI Objectives

PI objective setting gives teams the opportunity to validate with stakeholders that they have clearly understood the intent and priorities defined for the PI in terms of business value. This step will help ensure that there is a high degree of alignment between business stakeholders and delivery teams. What we want to see here are objectives and not features. What’s the difference? Formulate objectives by thinking about the problems that are being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems.

This step is about assigning overall business value to the PI.
The intent of this exercise is to summarize the PI in terms of meaningful business objectives, and to confirm alignment between teams and stakeholders. Features deliver benefits that are aligned with business goals.
PI objectives should be SMART: Specific, Measurable, Achievable, Realistic, Time-Bound.
Business stakeholders circulate and score the team’s objectives, assigning a ‘business value’ between 0-10, where 10 represents the highest business value. Each team starts with their most valuable PI Objective as a ’10’, then all remaining PI Objectives are scored relative to that first 10. BV can either scored as relative within the team, or relative to the overall train.
At the next PI planning event, following the PI demo’s, business stakeholders will rate objectives based on what was actually achieved – this data is the basis of the Program Predictability Metric. (Pass out a printed list of PI objectives with original rankings to the stakeholders with additional column for actuals).

PI Planning Part 3: Leadership Review & Problem Solving

Once all teams have presented their draft plans, including any risks that have been identified, that basically wraps up the first day for everyone except for the leadership team. The teams will typically head out to dinner at this point, while the leadership team remains at the event venue to work on the following questions:

What have we learned so far?
Where do need to adjust: Vision, Scope, People?
Where are the bottlenecks?
What features must be de-scoped, or deferred?
Decisions needed before tomorrow?

The last question is key. The leadership team must work through enough of the list of issues and risks so that teams can move forward again the next day. The overarching goal is to optimize the amount of business value that can be produced by the entire release train. This may involve scope adjustments and/or rebalancing of team capacity.

PI Planning Part 4: Make Adjustments and Finalize Plans (Team Breakouts #2)

Once the leadership team have communicated any required changes to feature priorities or team capacity changes the teams go into another round of breakout sessions and make any required adjustments to their plans.

The basic steps for the second team breakouts will look like:

Teams adjust & finalize plans – incorporate adjustments from leadership review: priorities, scope changes, people moves
Stretch objectives setting
Teams identify remaining issues needing help from outside team
Be prepared to present updated plans in Part 5

1. Team Breakouts 2 – Plan Adjustments

Having heard from the leadership team, teams conduct a second round of breakouts to incorporate changes in priorities, scope, people moves into their plans. This involves updating team wall boards to reflect any scope changes and with feature delivery timelines, updating the team’s list of risks, and potentially revising the teams list of program objectives. At this time, teams also identify any ‘stretch objectives’ and add them to their list of program objectives:

2. Scoring PI Objectives

Each team summarizes their overall PI in terms of objectives, and these are then reviewed by the business stakeholders. Business value is assigned to each objective (scored 1-10). Note what we want to see here is objectives and not just a list of features. What’s the difference? Formulate objectives by thinking about the problems that are being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic ‘value statement’ and from there back to at least one of the strategic themes identified for the business. At least be able to articulate the answer to why the feature is needed in terms that a business stakeholder can understand.

At the beginning of the next PI planning event, completed objectives will be demonstrated to the business stakeholders, and each one should be scored based on the perceived value actually delivered. These scores are compared with the original scores. The number of completed objectives is compared with the plan and the Predictability Metric score is derived. This can be displayed using a control chart: (See below).

3. Program Risk Review

Teams will conduct a ROAM’ing exercise on their list of risks, that is, they will review each risk and assign them to one of 4 categories:

R: Resolved. The team has resolved (or knows how to resolve) the risk.
O: Owned. The teams decides to ‘own’ the risk, that is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.
A: Accepted: The team accepts the risk as something that is ‘part of life’, or part of the cost of doing business.
M: Mitigated: The team believes they can take specific actions to reduce the impact of the risk.

Those remaining risks that each team feels they need help with are consolidated in a single list at the front of the room, and are reviewed by the program team and stakeholders. Further attempts will be made to resolve or at least mitigate these risks, else they will be carried outside the event (by the RTE) to be worked on further.

4. Program Wall Board Update

The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of features completion dates, enabler items, dependencies and major program milestones.

Here is an example:

In this example we have a program board with 8 teams (Vikings, Gauls, Celts, …) and 5 iterations, and a program board that shows the planned completion dates for each feature included in the PI. Red string is used to show dependencies between features or between features and enablers. Also included are any major milestones planned during the PI. Some teams make the mistake of placing user stories on the board. This is not necessary and only serves to clutter up the board. Once PI Planning is over, the program board can be a key information radiator for use at Scrum-Of-Scrums.

PI Planning Part 5: Align on Updated Plans and Objectives

Teams present updated plans and PI Objectives.
Business stakeholders score PI Objectives
Team-level confidence votes.
Program wall-board: Consolidate all team feature delivery timelines into a single view.
Each team risks ROAM’ed
Program confidence vote.
Event retrospective.

Program Confidence Vote

The Program confidence vote is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially re-worked until all team members vote at least a 3.

Team members indicate their level of confidence in meeting their objectives by raising hands with 1, 2, 3, 4 or 5 fingers raised:

Little or No Confidence: Will not happen
Little Confidence: Probably will not happen
Good Confidence: Team is likely to meet its objectives
High Confidence: Should happen
Very High Confidence: Will happen

6. PI Planning Event Retrospective

The final step before wrapping up the event is to conduct a retrospective of the event itself. It can be as simple as a 2-column table drawn on a whiteboard or flip-chart with a column for ‘what went well’ and another for ‘needs improving’. Participants invited to add their comments via post-its. Once all comments have been posted, a dot-voting exercise can be done to identify the issues most important to the gathered teams. This is to generate feedback and identify improvement actions for the next event. This exercise can be done fairly quickly with the RTE facilitating.

SAFe 4: PI Planning Step-By-Step

Contents