SAFe 6.0: PI Planning: Step-By-Step

Please Read First:

Re-Cap: The SAFe Delivery Model

PI Planning Preparation: ART backlog creation, refinement & ranking.
ART Backlog: Represents highest priority objectives for next PI.
PI Planning: Teams estimate ART Backlog items, confirm what can be delivered in next PI.
PI Execution: Teams produce working increments of the solution as the output of each iteration.
Inspect and Adapt mechanisms operate continuously throughput the PI for potential course corrections. These include ART-level synchronization events and System Demos.
A common definition of done applies for features and stories across all teams in an ART.

PI Planning Inputs and Outputs

Inputs (Pre-Work):

Top objectives for next PI defined by the Product Manager.
Objectives elaborated into features and captured in the ART Backlog. 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 stack-ranked list.
Features sufficiently refined to support PI Planning. More details here, including a Feature Template.

Outputs:

PI scope estimated for next timebox – how much of the ART backlog can be delivered.
Consolidated PI plan showing feature delivery plans from all teams – ART Planning Board.
PI Objectives defined – business summaries of what will be accomplished.
PI Objectives scored by business stakeholders.
Program risks reviewed and actions identified to solidify the plan.
Confidence vote. Collective alignment and ownership of the plan.

To summarize, the PI Planning event takes as input the highest priority feature list from the ART Backlog, and performs sufficient analysis (story mapping, sizing and scheduling), resulting in a reasonably good estimate of what can be delivered – Features, PI objectives plus timelines – for the next Planning Increment:

The consolidated delivery plan is captured on the ‘ART Planning Board’ and shows the feature delivery timeline by team plus any major dependencies:

It’s worth emphasizing here the intended shift from planning by features to planning by value. The setting and scoring of PI Objectives in the PI Planning process specifically supports that goal, and differentiates SAFe PI Planning from other planning frameworks.

The PI Planning Event Agenda

The standard agenda and process flow is shown below. Specifics on format, logistics, time per agenda item will vary (Big Room vs. Virtual/Distributed). PI Planning is typically a 2-day event (whether physical or virtual). This event should happen during the last sprint of the current PI. Input is a Ready ART Backlog with features defined to a definition of ready: acceptance criteria, and stack-ranked by business value.

PI Planning Part 1: Teams create draft plans.

Introductions & Agenda Review
Business Context: Vision, Strategy & Roadmap
Architecture Updates
Team Breakouts #1: Create draft plans
1. Story Mapping (create stories from features)
2. Story Sizing, Feature Sizing
3. Story & Feature Scheduling
4. Identify Risks & Dependencies
5. Draft PI Objectives
Teams present draft plans with risks & impediments.
Leadership review & problem solving

PI Planning Part 2: Finalize plans & confidence vote

Planning Adjustments from leadership team
Team Breakouts #2: Update plans
1. Team plan adjustments
2. Updated Feature Scheduling
3. Updated Objectives
4. Risks ROAM ’ed
Stakeholder review of plans and objectives scoring
ART Planning Board finalized.
Risk Review
Confidence Vote
PI Planning Event Retrospective

PI Planning Part 1/Day 1

In Part 1 the ART plus stakeholders will hear a state of the business update from business leadership, and then a review of goals and priorities for the upcoming PI from the ART Product Manager. Each delivery 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 Scope Estimation

This step assumes that the necessary PI Planning preparation work has been completed – the ART Backlog has been sufficiently refined to support story writing and sizing. Draft 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.

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. If teams are physically together this is typically done with flip charts and post-its. For virtual planning formats collaboration tools like Mural are an option. Once draft plans are completed, 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’. In the above example: Find Product, Product Details, Shopping Cart, Checkout.
Start defining potential actions the user will take to accomplish each function. Search For Item, View Product, View Photo and so on. 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. Or, in our case, achieve the objectives defined for the PI.

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.
Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended).
Team SM facilitates.
Team PO and/or PM available to take questions and clarify stories.

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 13 points. 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 ART Planning Board.

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

Estimate Team Capacity: (e.g. Team of 5 Dev/QA * 10 days * 80% = 40 points). See below.
Story Discovery: Break Features into Stories as described above.
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 will be done (to nearest iteration)
Update the ART Planning 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 ART Planning Board is intended to show feature delivery timelines per team. This should be updated so that the ART and stakeholders have a complete view of the PI as input to the leadership review and problem-solving session at the end of Day 1.

SAFe Capacity-Based Planning

Give every full-time developer and tester on the team 8 points (assume 2-week sprints). Thus, assume only 80% of capacity is available for productive work. Basically 1 point per day per person, up to 80% of available capacity in a 10-day iteration. For example, the capacity per sprint for a team of 5 developers/testers is 40 points.
Subtract 1 point for every vacation day and holiday.
Select a small story that would take roughly half a day to code and half a day to test – 1 day of total effort. Call it a 1-point story.
Estimate all other stories relative to that one.

4. Risks & Dependencies

As teams work through the process of allocating stories to sprints 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 ART, on teams outside the ART, 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 deliver 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 Objectives are business summaries of what each delivery team in an ART intends to deliver in the next PI. PI Objectives are a refined version of the business goals defined by the business stakeholders as an input to PI Planning. These refinements are based on the results of each team’s planning deliberations.

Organizational readiness for PI Planning requires alignment on goals and priorities between all business stakeholders before a PI Planning event. PI Objectives represent a refined version of those objectives based on the results of the planning process.

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.

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).

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 2/Day 2:

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.
Teams identify remaining issues needing help from outside team.
Be prepared to present updated plans.

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, capacity into their plans. This involves updating team planning tools to reflect any scope changes and with feature delivery timelines, updating the team’s list of risks, and potentially revising the teams list of PI 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 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. PI 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. ART Planning Board Update

The ART Planning 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.

Once teams have arrived at close to the final versions of their plans, the ART Planning Board should be updated. This should ideally happen before the updated plan presentations, and the team should walk through their feature delivery timeline as part of their presentation. To recap, at this point all teams should have made the following planning progress:

Features estimated in story points (or in capacity units).
Dependencies between teams identified.
Feature completion dates understood to nearest sprint.

Here is an example:

In the above example we have a Planning Board with 8 teams (Vikings, Gauls, Celts, …) and 5 iterations. The board shows the planned completion dates for each feature to the nearest sprint. 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 ART Planning Board can be an important artifact for use throughout PI execution – for example ART Syncs and System Demos.

5. Align on Updated Plans and Objectives

Teams present updated plans and PI Objectives.
Business stakeholders score PI Objectives
Team-level confidence votes.
ART Planning 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.

Five Finger Consensus: 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.