The Facilitator’s Guide to PI Planning

Abstract:

The Agile Release Train (ART) is the primary value delivery construct in SAFe. Each ART is a long-
lived, self-organizing team of Agile Teams, a virtual organization (5 – 12 teams) that plans, commits,
and executes together. ARTs are organized around the enterprise’s significant Value Streams and live
solely to realize the promise of that value by building solutions that deliver benefit to the end user.

Integral to the Agile Release Train is PI Planning which occurs at PI boundaries. This guideline
provides a detailed description of a prototypical, first PI planning event, including detailed guidance for
planners and facilitators.

On Solution Trains (coordinated, multi-ART Value Streams), Pre-PI Planning events are held to set the
context and objectives for the ART PI planning events. Post-PI Planning events are used to integrate
the results of the ARTs on the Solution Train. This guide does not include details on Pre-PI Planning
and Post-PI Planning events. Please refer to the framework articles for further information.

© Scaled Agile, Inc. 1

 Table of Contents

The Agile Release Train (ART) ............................................................................................................ 3

The PI Planning Event ......................................................................................................................... 3
Planning Attendance ............................................................................................................................ 3
PI Planning Facilitator .......................................................................................................................... 3
PI Planning Checklist ........................................................................................................................... 4
PI Planning Narrative, Day 1 ................................................................................................................ 4
Opening ............................................................................................................................................... 5
Business Context ................................................................................................................................. 5
Product/Solution Vision ........................................................................................................................ 5
Architecture Vision ............................................................................................................................... 5
Development Practices ........................................................................................................................ 5
Team Planning Breakouts .................................................................................................................... 6
Draft Plan Review ................................................................................................................................ 8
Management Review and Problem-Solving Meeting ............................................................................. 9
PI Planning — Day 2 Narrative........................................................................................................... 10
Day 2 Opening ................................................................................................................................... 10
Planning Adjustments — A United Front............................................................................................. 10
Team Planning Breakouts Continue ................................................................................................... 10
Team PI Objectives............................................................................................................................ 11
Uncommitted Objectives .................................................................................................................... 12
Program Board .................................................................................................................................. 13
Final Plan Review .............................................................................................................................. 14
Addressing Program Risks and Impediments ..................................................................................... 14
The Commitment ............................................................................................................................... 16
Planning Retrospective ...................................................................................................................... 17
Moving Forward and Final Instructions to Teams................................................................................ 17

© Scaled Agile, Inc. 2

 The Agile Release Train (ART)
The Agile Release Train (ART) is the primary value delivery construct in SAFe. Each ART is a long-lived,
self-organizing team of Agile Teams, a virtual organization (5 – 12 teams) that plans, commits, and
executes together. ARTs are organized around the enterprise’s significant Value Streams and live solely
to realize the promise of that value by building solutions that deliver benefit to the end user.

The PI Planning Event

Planning should be done face-to-face. This is consistent with both the Agile Manifesto1 and lean
principles, as face-to-face communication is by far the most efficient way to make transfer information
from product management to the development teams. (One such planning session can replace thousands
of emails and be 10–20 times faster). SAFe takes this to the next level via PI Planning, the seminal,
cadence-based synchronization point of the ART. PI planning is a routine, face-to-face event with a
standardized agenda that includes presentation of business context and vision, followed by team planning
breakouts wherein the teams create the plans for the upcoming Program Increment (PI).

Planning Attendance
Program travel budgets should be optimized around PI Planning sessions so as to make it feasible for as
many members as possible to plan together. Generally speaking, it isn’t “new travel money,” as it likely
replaces a host of ad hoc asynchronous meetings that would have otherwise been necessary.
In the event that the teams who need to plan together are so widely distributed that meeting face-to-face
is impossible due to travel costs or restrictions, then it’s likely that it is a highly inefficient organizational
structure to support new development. In that case, the enterprise should:
1. Continually refactor teams and assignments to support ever higher degrees of collocation
2. Move entire capabilities, features, components or subsystems to locales where a critical mass
already exists, or can quickly be assembled

In doing so, the enterprise will continuously lower the transaction costs of the planning event as well as
decrease the costs and accelerate the feedback of the ongoing and continuous information transfer that is
vital to development.
However, in the event that all team members cannot be assembled in one place for PI Planning, then the
program must make plans for communication with remote teammates, so that planning is still
simultaneous, though not to face-to-face. On large programs, this often occurs with a large group of
onshore people in one location and another offshore group also meeting face-to-face.

PI Planning Facilitator
PI planning is a strategic event. As such it is replete with the challenges and inherent conflicts of vision
(what we’d like to accomplish) versus reality (what we actually can accomplish). However, this potential
for conflict is not bad, per se. Rather, when properly managed, the inherent mismatch of expectations
creates a creative friction between product management and development that forces the groups to find
the optimum solution.
And while it’s true that we absolutely need to create product development flow (where input does largely
match output), we can’t simply achieve maximum flow by just “backing off the accelerator” (fewer cars will
go down the freeway than it has capacity for). It may be flowing, but it’s too slow. Rather we want to

1
Agile Manifesto Principle #6—The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.

© Scaled Agile, Inc. 3

 accelerate to the point of most efficient productivity, the point above which congestion (in this case by a
combination of overloaded, multiplexed teams and badly matched expectations) occurs.
Since it’s likely to be a politically-charged event as well, experience has shown that these events are
more successful when a facilitator—someone who is not bound solely in product management or
development—runs the event. It can be someone from inside the company or from outside the company.
This role is sometimes referred to as the Release Train Engineer (RTE).
Often, this is a program manager. Program managers typically have many of the valuable skills necessary
to plan and run such an event. However, they must not conflate that objective with the need to plan and
run the ART. The Agile Release Train largely manages itself—we don’t “program manage” it. However,
we do have to facilitate and manage the process effectively. In any case, from here forward, we’ll use the
word “facilitator” to describe the person that is largely responsible for running the actual PI Planning
event.

PI Planning Checklist
In preparing for a successful event, there are three primary areas of concern:
1) Strategic alignment and organizational readiness for planning
2) Leadership and team preparedness for the event itself - content readiness
3) The actual logistics for the event - facility readiness

Since any one of these can interfere with the potential outcome—an actual, specific and committed set of
PI Objectives—careful consideration of all three factors is warranted. In support of this, Scaled Agile has
developed a checklist (provided in a separate document) to assist those who are responsible for planning
such an event.

PI Planning Narrative, Day 1

While the agenda for the planning event itself will, of course, vary based on the current context of the
program, Figure 1 provides a typical agenda that can be used as a starting template. Each of these
sessions is described in the sections below.

Figure 1. Day 1 Agenda Example

© Scaled Agile, Inc. 4

 Opening
The facilitator opens the event, provides any necessary introductions, then reviews the purpose and
agenda for the event, the working agreements, the planning rules and expectations, amenities, and other
logistics items. The facilitator also presents the upcoming calendar of events including the iteration and PI
cadence, future PI planning dates, any scheduled releases, as well as any company holidays or other
events that may affect planning objectives or team capacity.

Business Context
Next, a senior executive or line-of-business owner typically sets the business context for the planning
session. This may include discussion of current business performance, revenue or market share,
measures of customer satisfaction, etc. It may also include updates to operating plans, organizational
developments, SWOT (Strengths, Weakness, Opportunities, Threats) analysis, strategies and competitive
context. The presenter will typically conclude with a discussion of strategic themes and business
objectives for the upcoming periods.
The meeting organizers should reach as high into the organization as possible for this opening speaker,
as it is an important opportunity to align all development teams to a common vision for the business. It
also gives the teams an opportunity to meet and interact with some of the executives that drive the
business vision.

Product/Solution Vision
Next, the product manager(s) responsible for the Program Backlog present the current vision for the
product and the tentative roadmap going forward. The briefing includes the objectives (or themes) for the
upcoming PIs as well as the specific feature priorities.
If there are multiple product managers, each may need some time in this slot to present the vision for
their area (product, feature, component) of the solution, but presentation time is rigorously time boxed.
After this session, product manager(s) will often provide a handout, pointers to where the Program
Backlog can be found, or otherwise make their feature priorities and descriptions fully visible to the teams,
as those features are the driving elements for the breakout planning sessions.

Architecture Vision
System level architecture plays an important role in defining cross-cutting aspects of the solution. In this
session, the system architect(s) presents the vision for architecture. This may include descriptions of new
enabler epics for common infrastructure, any large-scale refactors under consideration, new system level
frameworks, or emerging new technologies or platforms, etc.
In addition, any system-level nonfunctional requirements, such as operating platforms, governing
regulatory or industry standards, usability, performance, reliability, and security requirements are also
highlighted in this session.

Development Practices
Agile puts extreme pressure on development practices and infrastructure. In this slot, a technical leader
(often the system architect) informs the teams about changes to standard practices, tools and techniques
for Build and Test automation, expectations for the Definition of Done, etc. Also, if this is not the first
session, many Inspect and Adapt improvement stories will surface here for discussion and resolution.

© Scaled Agile, Inc. 5

 Team Planning Breakouts
The next session is the longest and most critical session of the two-day event. In this session, the teams
break out into separate meetings and draft their initial plan to achieve the goals for the next Program
Increment.

In this session, the teams iterate through a process that proceeds roughly as follows:
• Meet with product managers, etc. to better understand features and feature priorities.
• Estimate the capacity the teams will have during each iteration.
• Brainstorm and identify the user stories and enabler stories that are necessary to meet the goals
and prioritized features of the PI. Stories are kept at “backlog-level of detail.” The objective is to
get a first, high-level feel for how the plans unfold. Too much detail bogs down the process and
creates false precision and excessive WIP.
• Understand the impact of enabler features on the plan and identify stories for those features as
well.
• Incorporate improvement backlog items that came out of previous team retrospectives and the
last PI’s Inspect and Adapt.
• Factor in local dependencies as well as interdependencies with other teams.
• Estimate the stories and place them in iterations in sequenced order until capacity for each
iteration, excluding maintenance allocation, is exhausted.
• Create a backlog of things that can’t be accomplished in the period and will have to be
postponed.

During this process, there will also be variety of interactive discussions with product managers, system
architects, the system team, UX, and other teams to understand scope, priorities, necessary infrastructure
development, interdependencies, potential for common code, etc. It is a very intense and active time.
Plans are created visually with wall charts and story cards so that all plans are visible for all to see.
Teams build their plans with one wall chart sheet per iteration, another sheet for objectives, and one final
sheet to capture risks and impediments.

© Scaled Agile, Inc. 6

 For example, a plan might appear as in Figure 2 as follows:

Figure 2. Team PI Planning deliverables

Note that the IP Iteration should not contain any stories, even though the teams may identify some stories
dedicated to special activities such as load and performance testing, final system documentation, etc.
Teams also use color-coded story cards (sticky notes) to help identify various types of stories. Story cards
include colors for new user value stories, maintenance stories, interdependencies, enablers, etc. These
provide visibility into the relative percentage of backlog item types dedicated to these various activities
within each team and across the ART. One color-coding example follows:

Normalized Estimating
In the initial session, simply give each team 8 points per Iteration for each full-time developer and tester
on the team. Then tell them that when they see something that looks like it will take them about one day,
estimate it at one point. Estimate the rest of the stories relative to that. In addition, if the aggregate points
for any story (including estimates for development and test) is greater than eight, have them split it until
each resulting story is less than eight.

© Scaled Agile, Inc. 7

 This will do two things:
1) Assure that most teams have about the right number of right-sized stories in an Iteration
2) Normalize estimation across all teams. This is important for feature and epic level estimating and for
conversion into cost estimates.

Note: What to do when teams have existing and wildly varying velocities: If teams already have
velocities, a quick check will probably discover that they are already mostly normalized. Small
teams will have about 30, really big teams 50–60. If this is not the case, the facilitator may wish to
have some teams adjust accordingly so that program velocities make sense. While there may be
some emotion around the adjustment, just remind the teams that they are unit-less numbers, so
there can be no harm in making an adjustment to make it easier to manage the program.

Hourly Scrum of Scrums Planning Checkpoints

Teams can often become bogged down or derailed by unknowns, interdependencies, and unnecessary
details during the planning process. To keep planning on track, facilitators hold an hourly 5–10 minute
‘Scrum of Scrums’ planning checkpoint. In this short standup meeting, Scrum Masters work out
interdependencies, discuss impediments and ensure that the ART is progressing toward the goals for PI
planning.
When problem solving is required, management and other key stakeholders may attend a ‘Meet After.’
This may require changing assignments, resource adjustments, impediment removal, adjustments to
release scope, or modifications to the planning agenda. While the meeting is intended to be short and
time boxed, the time for problem solving is now, or the plans may not converge.

Draft Plan Review

At the designated time, the group reconvenes in the plenary session to review each of the plans. Many of
the plans will not be complete. However, the preliminary review is still held on time so the groups can see
the planning process and have an initial look at the assumptions, dependencies, and initial PI objectives
that their counterpart teams are putting together. Each team presentation is strictly time boxed, with 5–10
minutes per team, based on the size of the planning domain.

Note: Many executives, managers, and other key stakeholders in the company may be invited to
this portion of the event. This allows for total program visibility and shared business and
development context. In addition, the unfolding plans may well affect their department or area of
interest and they may have input or adjustments to the plan based on their contribution and
perspective. In turn, the development teams may also have dependencies on these functions (e.g.,
marketing, sales, customers, distribution deployment, IT) in the larger enterprise context.

Each team presents using the following agenda:

Sample Draft Plan Review Agenda

1. Capacity and load
2. Draft PI objectives
3. Program risks and impediments
4. Q&A

© Scaled Agile, Inc. 8

 There will typically be a minute or two left for Q&A. During Q&A, the facilitator has to walk a fine line
between abruptly cutting off important discussions about interdependencies, tradeoffs,
misunderstandings, etc., and keeping the plan review sessions, in total, within the allocated time box.
The session proceeds until all teams have presented their draft plans, even at the risk of slipping out of
the allocated time box. For most attendees, this is the end of day one, and they may be dismissed from
the meeting room at that time.

Management Review and Problem-Solving Meeting

The draft plans often present substantial challenges to the management team, product management, and
other key stakeholders. Challenges may come from a number of directions:
• Since development work-in-process has been invisible up to now, it’s likely that there will be far
more of it than the teams can accomplish. Many ARTs are over-scoped by 50-100%, and that will
be obvious now.
• Critical paths, resource constraints, and bottlenecks will also be obvious.
• Team dynamics, inter-team dynamics and dependencies are also obvious.

If these issues are allowed to persist, Day 2 may come out badly: 1) The process will not converge on
agreed-to PI objectives due to these unresolved issues, or 2) convergence will appear to happen, but the
PI is at great risk because underlying problems have not been addressed.
To this end, some set of line managers, scrum masters, product owners, product managers, and business
owners must meet to address the larger challenges identified in the draft review session. This may
involve cuts to scope, rethinking prior commitments, accepting that some critical date will not be met, and
moving resources (or even entire features) from team to team.
The facilitator plays an important role, as many of the challenges noted may be politically-charged or
historical in nature. The facilitator holds the key stakeholders together as long as necessary to make the
decisions necessary to improve the probability of a successful outcome of the next PI (or at least the next
day’s planning session). Any such decisions reached should be carefully and clearly stated, as they will
serve as input to the next day’s session.

© Scaled Agile, Inc. 9

 PI Planning — Day 2 Narrative
In Day 2, the ART must get to a committed plan of action: one which fits the teams’ capacity and which
achieves the maximum value delivery possible in the next PI time box. A typical agenda for Day 2 is
described in the Figure 4.

Figure 3. Day 2 Agenda Example

Day 2 Opening
In the Day 2 opening session, the facilitator provides an overview of the agenda and the objectives for the
final day, including the time boxes in which the teams should complete their plan and be ready for
presentation.

Planning Adjustments — A United Front

Even though management will have attempted to communicate most of the key decisions prior to the
meeting, it is inevitable that in the “frenzy of the last responsible moment,” some of the decisions reached
in the prior day will come as a surprise to some team members. Many decisions will be greeted with
enthusiasm, since they often simplify scope, assign additional resources to critical bottlenecks, or resolve
key impediments. Some decisions, however, may be received less enthusiastically, as many are the
results of compromises amongst key stakeholders or even between teams.
In order to make management’s full support for the key decisions unambiguously clear, a senior manager,
or perhaps the management team as a group, takes responsibility for describing the results of the review
meeting at the end of Day 1, highlighting those decisions that may affect the planning process,
organization, or objectives. This presents a united front in support of the key decisions and changes,
controversial or not. After all, we are going to need a united effort from the development teams to
accomplish the release. The least we can do is know that management stands behind them, also united
as a team.

Team Planning Breakouts Continue

With planning adjustments in hand, this next session is a continuation of the prior day’s team breakouts.
By now the teams should be planning smoothly. The facilitator’s role is the same as the day before: keep

© Scaled Agile, Inc. 10

 the teams moving forward; keep the business owners, product managers, engineering managers, and
architects circling; watch for new developments that require additional decision-making; provide
assistance to the teams whose work is being refactored or are still struggling with estimating, or who are
still over-scoped, etc.
The business owners will be able to assign business value to the teams’ PI objectives.
And, like the day before, the planning Scrum-of-Scrums convenes hourly to assure that plans and
timelines converge for the final review.

Team PI Objectives
Towards the end of the planning session, the teams should be focused on discussing the final team PI
objectives with their product managers and business owners. The team PI objectives are a key artifact of
the PI Planning session and are an important element of ART governance and tracking.
Team PI objectives are brief summaries, in business terms, of what the team is prepared to commit to in
the upcoming PI.
Many of the objectives will be features from the backlog, which are stated just like they were described in
the vision briefing of Day 1. As such, their importance and the value they deliver are immediately
recognizable.
Others, may not be value delivering or enabling features, but may be an aggregation of a set of features,
or less tangible items that still deserve notice and attention at this top-level output of the PI Planning
process.

Team PI Objectives are SMART

When writing PI objectives, teams should use the SMART Framework to make sure their objectives are:

• Specific - States the intended outcome as simply, concisely, and explicitly as possible. (Hint: Try
starting with an action verb.)

• Measurable - It should be clear what a team needs to do to achieve the objective. The measures
may be descriptive, yes/no, quantitative, or provide a range.

• Achievable - Achieving the objective should be within the team’s control and influence.
• Realistic - Recognize factors that cannot be controlled. (Hint: Avoid making “happy path”
assumptions.)

• Time-bound - The time period for achievement must be within the PI, and therefore all objectives
must be scoped appropriately.

© Scaled Agile, Inc. 11

 PI Objectives are assigned Business Value
The primary measure of the Agile Release Train is a predictability/reliability measure which tracks the
percent of business value achieved for each PI objective relative to the plan. In order to achieve this, the
business value of each PI objective is set by the business owners towards the end of the PI Planning
session.
Of course, not all objectives deliver equal value and the business owners are likely to put higher numbers
on externally visible objectives than they will on infrastructure and architectural enablers. Yet, mature
business owners know that these technical concerns will also increase the capacity of the teams in
producing future business value, so placing some business value on those items is a sign of maturity by
the business owner, and a sign of support for the teams.
As the road after PI planning takes its inevitable twists and turns, having objectives with defined business
value gives the teams guidance in making tradeoffs, minor scope adjustments, etc., in a manner which
delivers the maximum possible business benefits.

Uncommitted Objectives
Gaining a meaningful commitment from the team is a tricky proposition culturally. Without it, no one is
committed to anything, all are on a “best efforts” basis. Some prefer that. After all, one can argue that a
fixed set of release commitments puts the team back in the iron triangle. However, without any
commitments, the enterprise can’t plan, even for the short term, and that is unacceptable. To this end,
mature programs have learned to make commitments meaningful in two ways:
1. The expectation is that teams will meet “most” of their objectives. A yield of anywhere above 80%
should be acceptable. This gives the teams the flex they need to stretch and commit, without
negative consequences.2
2. Mature teams will soon learn that they need a set of committed goals, but given the variability of
R&D, the teams will also establish a set of uncommitted objectives. These objectives are also
assigned business value as is illustrated in Figure 5 on the next page.

Figure 4. Objectives and Uncommitted Objectives and Business Value

2
We must be careful what we wish for. In my experience, teams that reliably meet 100% of their commitments without uncommitted
objectives are often not very high performing teams in the aggregate. After all, they couldn’t afford to take any risks, could they?

© Scaled Agile, Inc. 12

 This gives the teams the opportunity to meet or exceed 100%, without fear of being in the penalty box for
stretching their objectives to the maximum. In addition, if we want teams to operate reliability in the 80%
plus process control range, then the ability to achieve over 100% on occasion helps achieve that.

Program Board
The Release Train Engineer also keeps a Program Board, such as the one picture below, updated during
the session. The program board highlights the following:
1) Any system level features and the anticipated completion date
2) Any program milestones, release dates, or important external events
3) Dependencies between the features and teams

Figure 5. Program Board Example

The implementation of the program board will depend on factors like program complexity, team
dependencies, and the number of teams involved. However, one method of implementation is as follows:

• Features (Blue): For features that can be implemented by a single team, the feature is
placed in the team’s swim lane. For features with dependencies on one or more teams,
the Feature is placed in the team’s swim lane and the dependencies are place in the
associated team(s)’ swim lane(s).
• Significant Dependencies (Red/Pink): These are components or other inputs required
for the completion of a feature with inputs.
• Milestones/Events (Orange): These are key events during the PI such as a trade show
demo or a release which happens within rather than at the end of the PI.
• Dependencies (Red String): These represent dependencies between features and
feature inputs.

© Scaled Agile, Inc. 13

 Final Plan Review
This session is a repeat of the session of the prior day, but by now the teams should have completed their
plans and are able to present them in final form:
• All iterations are planned. Work fits in the capacity available.
• Out of scope work has been identified on a backlog sheet.
• Team has a final set of PI objectives.
• Business owner/product managers have reviewed and agreed to the team’s plan and objectives
• Teams have also identified all critical dates and have updated the Program Board with milestones
and features.
Teams have identified the key risks and impediments that are outside of their local control, but that have
the potential to cause the team to fail to meet the objectives.
A specific agenda relies on context, but below is a sample template:

Sample Final Plan Review Agenda

1. Changes to capacity and load
2. Final PI objectives with business value
3. Program risks and impediments
4. Q&A

In a manner, similar to the day before, each team presents their plan to the group in the allotted time box.
While so doing, the facilitator is looking for agreement—within the teams, across the teams, and among
the business owners—as to the sensibility and appropriateness of the plan. Questions from the reviewers
are asked and answered.
At the end of each team’s time slot, the team states their risks and impediments. There is no attempt to
resolve them in this short time slot.
If the plan is acceptable to the business owners, the team brings their release objective sheet and
remaining program risks sheet to the front of the room so that everyone can see the aggregate release
objectives unfold in real time.
This process continues until all teams have presented their plan.

Addressing Program Risks and Impediments

Even though the plans are complete, there is still work to do. During the planning, teams have been
asked to identify the most critical risks and impediments: those issues they identify that could affect their
ability to meet the agreed-to objectives. Addressing these is a must for the ART, as they typically
represent those things that can—and if not addressed, likely would—interfere with the success of the PI.
By now, the teams should have been coached to address those risks that are under their control,
otherwise they couldn’t be responsible for their own plan. So the risks and impediments that remain in the
final review will need to be addressed in a broader, management context.
This is an important time for the management team and the facilitator. Every program risk that has been
identified by the team will be discussed and addressed in front of the full group. Each item is discussed
until the group agrees that the item can be categorized in one of the following (ROAM) categories:
• Resolved – The teams agree that the issue is no longer a concern and the item moves to the
Resolved sheet.

© Scaled Agile, Inc. 14

 • Owned- the item cannot be resolved in the course of the event but someone (usually a manager
or a specific team) takes ownership of the item. Ownership means that the responsible party will
take whatever action is necessary to assure that the issue will not negatively affect the release
commitment. An owned item is moved to the owned sheet and its ownership is recorded.
• Accepted – some risks or impediments are simply facts or potential occurrences that must simply
be understood and accepted. Nothing further can be done about it at this time. For example,
‘extraordinary support requirements’ for a prior release often appear on the list and can potentially
cause a team to miss a future commitment. However, allocating excessive resources just to
assure that these types of risk do not happen will lower value delivery for the release and may not
be prudent. Another type of potentially accepted risk might be the ‘late delivery of a component
from a supplier.’
• Mitigated – Often, the teams can identify a plan to mitigate the impact of an item. This may be a
work around plan, a minor de-scoping or any other such actions that the teams can take to lessen
the impact of a potential problem. If so, the mitigation plan is identified as notes on the back of the
risk card as it is moved to the Mitigated sheet.

Note: The facilitator’s role depends on the management team’s strength, cohesiveness and
culture. Sometimes the facilitator must be very active in order to drive consensus between a)
managers amongst themselves b) teams to managers, or c) teams to teams. In other cases, the
facilitator can step back and let management do the work. This is the preferred outcome as the
teams then see that one of management’s primary roles in the agile enterprise is the elimination of
impediments and the mitigation of risks.

In any case, the facilitator should assure that the issues are being addressed in a clear, honest, and
visible manner or the commitment that (hopefully) follows will be flawed.

© Scaled Agile, Inc. 15

 The Commitment
At some point the ‘backlog of risks and impediments’ sheet is empty, as they have all been moved into a
ROAM category. The consolidated statement of objectives is apparent and visible in the front of the room.
Now is the time to ask for a commitment.
However, commitment is actually not quite the right thing to ask for, since participants are often reluctant
to indicate that they are not committed to the team’s PI objectives in front of their managers. Instead, we
establish commitment by asking teams to vote on their confidence in their team’s ability to meet the
objectives.
For example, the question is often stated as “How confident are you that you and your teams will be able
to meet the objectives of this release?”
A public, ‘show of hands, five finger vote’ is then prompted:
1 — No confidence; will not happen
2 — Little confidence; probably will not happen
3 — Good confidence; the team should be able to meet the objectives
4 — High confidence; should happen
5 — Very high confidence; will happen

Once each team have voted, another vote is taken, this time involving everyone on the ART, on the
confidence of meeting the combined program plan
If the average is 3–4 fingers or above, that’s about as good as can be expected, and management should
accept the commitment and move forward. If the average is below three fingers, then the work is not yet
complete. Scope and resources are adjusted again as necessary and planning continues—that day, into
the evening, or even rolling over into the next morning—until a commitment can be reached. Alignment
and commitment are valued here more than strict adherence to a time box.

Assuming, however, that commitment has been achieved, the facilitator and managers should thank the
attendees for their participation in planning, because a commitment represents a job well done. With
objectives clearly defined, the Product Manager can then update the program roadmap for the next PI.

© Scaled Agile, Inc. 16

 Planning Retrospective
The next session is a brief retrospective led by the facilitator. A simple format to capture such data, along
with a few example comments, is seen in the figure below.

Figure 6. Retrospective Template Example

This session should last no longer than about 15–20 minutes, and towards the end of the time box, the
facilitator may ask the teams to rank the items in the third column (what we could do better) in order to
focus on the process improvement steps that can be taken before the next planning meeting.

Moving Forward and Final Instructions to Teams

The final session is typically a discussion about the next steps along with final instructions to the teams.
This might include:
• Capturing the PI objectives and stories in the Agile project management tooling
• Aggregating Team PI Objectives to Program PI Objectives
• Setting Scrum of Scrum cadence, Release Management Team cadence, System Demo cadence, etc.
• Program backlog refinement and next PI Planning preparation events
• Summarizing changes to engineering practices
• Cleaning up the room

Thereafter, the event is adjourned. Good luck!

© Scaled Agile, Inc. 17