A Facilitator’s Guide to Distributed PI
Planning
Abstract:
The Agile Release Train (ART) is the primary value delivery construct in SAFe. Each ART is a longlived, self-organizing team of Agile teams – a virtual organization of 50 - 125 people, that plans,
commits, and executes together. ARTs are organized around the enterprise’s significant value
streams and deliver value by building solutions that provide benefit to their customers. Integral to
the ART is PI planning, a typically face-to-face event for everyone on the ART every 8 - 12 weeks.
While both the Agile manifesto and SAFe highlight the benefits of such face-to-face planning,
organizations will often need to run these events across multiple locations. The reasons for a
distributed PI planning event can be varied. It may be due to financial constraints, very large teams
in highly distributed locations, extensive travel time and cost commitments, difficulties with visas,
or even as the result of unplanned travel restrictions.
This facilitators guide provides recommendations for running a geographically distributed PI
planning event based on our own experiences and those of our customers, partners and the SPCT
community. It assumes that there is familiarity with how to facilitate a standard face-to-face PI
planning, and therefore only highlights the specific recommendations for managing this event in a
distributed environment.
Throughout the guide the preparation activities have been marked with a checkbox, to help
identify them and allow them to be marked as complete. Additional guidance can be found in the
accompanying advanced topic article: Distributed PI Planning with SAFe
© Scaled Agile, Inc.
1
Table of Contents
LEAN-AGILE MINDSET .........................................................................................................................3
PI PLANNING PREPARATION .................................................................................................................4
Facilities Readiness....................................................................................................................4
Day 1 Briefings ..........................................................................................................................5
Communication Channels and Conference Lines ........................................................................5
Team Plans, Risks, and PI Objectives .........................................................................................6
Program Board..........................................................................................................................7
Tooling Cheat Sheet ..................................................................................................................8
Preparing the Distributed PI Planning Agenda ...........................................................................8
Booking time with Key Stakeholders ........................................................................................10
Information Preparation, Distribution and Storage..................................................................11
PI Planning Facilitators ............................................................................................................12
Working from Home................................................................................................................13
PI PLANNING, DAY 1 ........................................................................................................................14
Opening ..................................................................................................................................14
Business Briefings ....................................................................................................................16
Planning Requirements ...........................................................................................................16
Team Breakouts 1 of 2.............................................................................................................17
Draft Plan Review....................................................................................................................21
Management Review and Problem-Solving Meeting ...............................................................21
Facilitator Debrief ...................................................................................................................23
PI PLANNING, DAY 2 ........................................................................................................................23
Scrum of Scums .......................................................................................................................23
Day 2 Opening.........................................................................................................................23
Planning Adjustments .............................................................................................................23
Team Breakouts 2 of 2.............................................................................................................24
Final Plan Review ....................................................................................................................24
Confidence Vote and Plan Rework ...........................................................................................25
Planning Retrospective ............................................................................................................26
© Scaled Agile, Inc.
2
Lean-Agile Mindset
Although a significant amount of this guide describes the activities and tasks that need to be
facilitated, perhaps the most important determinant of success in a distributed PI planning event is
the mindset. Specifically, a Lean-Agile mindset as described by the SAFe House of Lean and the
Agile Manifesto, Figure 1 below.
Figure 1 Lean-Agile Mindset
A Lean-Agile mindset helps to guide our behaviors throughout the event and prevents us falling
back into our more accustomed ways of working. With the distributed PI Planning in mind the
following elements from the SAFe House of Lean are of particular importance:
-
-
Respect for people and culture, reminds us all to empathize with those who are working
remotely and potentially late into the night. Efforts should always be made to ensure no
one is planning from a disadvantaged position in terms of access to information and
opportunities to collaborate.
Relentless improvement not only describes our intent to improve the experience of
distributed planning over time, but also to identify improvement opportunities throughout
the planning itself.
From the Agile manifesto we are reminded to do our best to value individuals and interactions
over processes and tools. In a distributed PI planning this also means making the integration of
tooling as seamless and pain free as possible. And of course, any facilitator of a distributed PI
planning event knows from experience that they must be open to responding to change.
Opportunities are built into the recommendations below to do just that.
© Scaled Agile, Inc.
3
PI Planning Preparation
Although the full preparation for PI planning is outside the scope of this guide, distributed PI
planning requires some additional activities as described in this section.
Facilities Readiness
Facilities readiness is a key concern for PI planning events. Scaled Agile has developed a PI planning
checklist (provided as a spreadsheet in the PI planning toolkit available to SPCs from the
Community Platform) to ensure these items are in place. The specific requirements for a
distributed PI planning event are reproduced below:
□ Facilities roomy enough in each location for all attendees with separate breakout rooms for
teams to conduct team to team or 1:1 conversation as needed.
□ Facility access before and after hours in case teams need to stay and continue planning. It is
highly recommended to have access to the facilities the day before for setup.
□ Multiple connectivity options to fully engage remote participants including phone, instant
messaging, and videoconferencing.
□ For a distributed event a dedicated high bandwidth internet connection is recommended.
□ Prepare and test all audio/video conference lines and document and distribute details of
the purpose of each one and the details for joining.
□ Provide support to attendees who may be working from home to ensure they have the
required infrastructure and an appropriate home office space.
□ Ensure that both the slides and the presenters are visible where connecting multiple
locations. This may require the use of multiple conference lines or computers.
□ Additional handheld microphones will be needed for passing between presenters and
attendees if a main location is being used.
□ Dedicated tech support personnel available that understand, own and manage the
communications environment so that the ART may fully concentrate on PI planning. Tech
support personnel should be available 1 hour before the start of each day for testing and
troubleshooting.
© Scaled Agile, Inc.
4
Day 1 Briefings
The presentations for the first day of PI planning typically act as a backdrop to the narrative that is
being delivered. In a distributed PI planning event, they provide substantial additional value as a
reference document for the teams who don’t have in-person access to those stakeholders. For this
reason, additional detail on the slides, or in the speaker notes, can be useful for conveying the key
messages.
□ Additional detail added to the briefing slides as required to ensure clarity of information for
remote attendees.
□ Make an electronic version of the presentation available online or via a shared drive with
access rights for all the event attendees.
□ Make a recording of the presentation available to all participants.
Some of the audio/video conferencing technologies that will be discussed later, support
automatically generated closed captions. In situations where audio clarity may be compromised
this can be one possible solution.
□ Configure, test and activate closed captions during presentations
Communication Channels and Conference Lines
Ensuring that information can flow freely during the event is critical. Using an appropriate instant
messaging tool (Slack, Microsoft Teams, Chatter, etc.) will support this. In addition to its typical use
for two people to communicate directly, creating ‘channels’ where everyone can see the answers
to questions is valuable. The following channels are recommended:
□ A ‘facilitators’ channel which includes the RTE, Scrum Masters, and any additional
facilitators. This will be used, among other things, to alert that group to prepare for
upcoming activities such as the Scrum of Scrums and plan reviews.
□ A ‘support’ channel for everyone in the event to be able to request help if they are having
technical issues or need general assistance from support staff in various locations. Make
sure this channel is constantly monitored.
□ A general ‘PI planning event’ channel for announcements to be broadcast to all attendees,
such as alerts when shared documents have been uploaded.
□ Channels for the key stakeholders such as Product Management, System
Architecture/Engineering, and Business Owners.
© Scaled Agile, Inc.
5
□ Public channels for each of the teams where questions and issues can be posted from other
teams.
□ A ‘continuous feedback’ channel. Although the PI Planning event concludes with a
retrospective, continuous feedback enables facilitators to respond to feedback in a timely
manner.
SAFe Tip: The event facilitators should take it in turns to monitor the shared channels to reduce the
delay the teams experience before receiving a response, or before an action is taken.
Audio/video conferencing tools are an important part of the communication protocol and there are
plenty of options available (Google Meet, Zoom, WebEx etc.). As well as attendees being able to
open conference lines on demand, it is recommended to have some ready to go with the links for
accessing them distributed to the attendees ahead of time:
□ There should be a single conference line for the activities in the agenda which involve all the
ART attendees coming together.
□ Additional conference lines are recommended for the scrum of scums and management and
problem-solving meeting.
□ Each team should have a conference line that they can use when they need to collaborate
with others.
Some conferencing technologies allow ‘rooms’ to be accessed from a common foyer, further
reducing the friction of moving between them.
Team Plans, Risks, and PI Objectives
Perhaps one of the most important areas of preparation is deciding how the teams will plan their
work. For teams that are co-located, continuing to use physical team planning boards makes sense.
If the teams themselves are distributed, then additional digital collaboration tools will be required.
Although these decisions would normally be decentralized to each team, operating in a distributed
environment, especially in an extreme case such as when many of the attendees may be working
from home, requires a greater emphasis on system thinking. One approach is for the RTE and SMs
to collaborate with all the teams in advance to get input, discuss advantages and disadvantages on
different tooling options and approaches (ALM tooling, spreadsheets, online collaboration tools,
© Scaled Agile, Inc.
6
etc.). From the subsequent list of options, any that would disadvantage a group or location should
be removed, and ultimately a consensus and buy-in on the best option is reached.
Each attendee should have access to the tooling choice and be given the option to receive
orientation on how the solution will be used. Ideally each team should do a dry run before the
event to make sure the tool does not become a blocker or delaying factor.
□ RTEs and Scrum Masters work with the teams ahead of PI planning to agree on the tools
that will be used for planning.
□ Check that all attendees have access to the tooling and appropriate permissions levels.
□ If a more advanced tool is used be sure to provide orientation and instructions for use
(ideally with the ability to practice hands-on) in advance.
Consideration should also be given to the information that will be shared during the plan reviews
i.e. capacity and load, team PI objectives and risks. The previously selected tooling may include this
capability but if not, an online spreadsheet works very well for this.
□ Create an online spreadsheet with a tab for each team and pre-formatted space for adding
the team capacity and load, team PI objectives and risks.
Because of the importance to track dependencies, teams sometimes indicate them directly on their
planning boards. Stories that require an external dependency are tagged, commonly with a red
‘sticky’. Once the dependent team is identified and accepts the work, they update the ‘sticky’ with
that team’s name. And the dependent team has a story for the dependent work along with the
team(s) that depend on it. This practice can be even more useful in distributed planning to ensure
conversations are documented.
Program Board
In terms of managing the program board we have observed several patterns. If the number of
locations is minimal, perhaps 2 or 3, many organizations choose to replicate a physical board across
the different locations, kept up to date by the facilitators at each site.
However, more and more we are seeing digital collaboration tools being developed specifically to
replicate this artifact. Indeed, the popularity of PI planning has led to the creation of dedicated
program board tools that combine the best of both worlds – a touch screen providing the tactile
experience of moving sticky notes around with the requisite connectivity that ensures data is
shared across all sites.
© Scaled Agile, Inc.
7
Another trick we have observed is teams using tables to represent the information normally
captured on the program board. On a program board, each string identifies one ‘receiver’ of
dependent work and one ‘giver’ of that work. Therefore, all this data can be represented as a table
of ‘giver’/ ’receiver’ pairs which is easy to represent electronically using a spreadsheet for example,
to support distributed planning.
While one could make a single, large table for the ART, most make a table for each team as shown
in Table 1. below. In this example the first two dependencies describe work the Iguanas are doing
for other teams, for example dependency A, being worked on in iteration 1.1, is needed to support
a dependency that the Dolphins are working on in iteration 1.2. The final row shows a situation
where the Iguanas are reliant on the Eagles for feature 4 that they are delivering in iteration 1.5.
Giver
Iguanas Dependency
A
Iguanas Dependency
B
Eagles Dependency C
Giver Iteration
1.1
1.2
Iguanas
Receiver
Dolphins Dependency F
Dolphins Feature 2
1.4
Iguanas Feature 4
Table 1. Example dependency table for Iguanas
Receiver Iteration
1.2
1.4
1.5
The most important consideration is whatever solution is chosen it should not disadvantage any of
the planning locations. Keep in mind that the same rules apply – a conversation, whether in person
or online, is needed before adding work for another team.
□ Agree and communicate how the program board will be managed and maintained.
Tooling Cheat Sheet
Since distributed PI planning relies on the use of several different tools, each with specific use
cases, it can be useful to create a ‘cheat sheet’ that can be distributed to all the attendees. This
should include an overview of how the various tools are being employed and any policies or
practices that have been agreed ahead of time governing their use.
□ Create a ‘cheat sheet’ outlining the policies and practices of the tools being employed.
Preparing the Distributed PI Planning Agenda
Distributed PI Planning often, although not always, includes multiple time zones. In extreme cases
such as when the teams are working in India and the US these time differences can be one of the
most challenging parts of facilitating a distributed PI planning.
© Scaled Agile, Inc.
8
In the PI planning toolkit, there is an editable version of the PI planning agenda that is designed for
these scenarios. With large differences in time zones the typical 2-day PI planning agenda may
need to be extended across three days, ensuring there is enough time for overlap when everyone is
available. Figure 2, below, provides such an example.
Figure 2 Example distributed PI planning agenda
When preparing this agenda, the following guidance is prudent:
-
Where possible ensure that all the locations are sharing the challenges of having to start
early or work late. Alternate those challenges between locations for future planning events.
Pay close attention to all the times in the agenda where all the teams attend at the same
time. Try and make sure that these occur at a reasonable time of day.
Maximize the amount of time the teams have for the team synchronization points. These
are the specific times identified in the agenda when all teams will be available for cross
team collaboration and dependency resolution.
Since the agenda itself is more complex, add each individual element as a meeting invite in the
relevant calendars of the event attendees. Make it clear in the invites if this is an activity just for
the team or if they should be joining the main room audio/video conference line along with
everyone else. Include all the connectivity details in the invites.
Additionally, request that all attendees adjust their ‘working hours’ in their calendars so it is very
easy for attendees to see when someone will be available, as shown in Figure 3.
□ Add the PI planning event activities to all attendees’ calendars with all the relevant
connectivity information.
□ All attendees change their core working hours in their calendars to match the agreed start
and end times for their location.
© Scaled Agile, Inc.
9
SAFe Tip: Identify the ‘team synchronization’ points separately from the team breakouts in the
agenda. This allows them to be added as separate entries in the attendee’s calendars, emphasizing
their importance. In the example below they have been color coded to improve visibility.
Figure 3 Calendar showing core working hours and team synchronization points
Booking time with Key Stakeholders
The ability for distributed participants to ‘book’ time with key individuals such as Business Owners,
key stakeholders, shared services etc. during the event is critical, given they may be operating on
different time zones from those who need them most, or at least from a different location.
□ Ensure that these individuals make their calendars available so attendees can book time
with them. Agreements may be put in place to constrain time slots to 15 mins to ensure
everyone has equal access.
© Scaled Agile, Inc.
10
Information Preparation, Distribution and Storage
In a distributed PI planning scenario, successful facilitation in part relies on all the attendees having
equal access to information. The recommendation is to use networked or online storage for the
more stable and static artifacts that are not regularly changing.
SAFe Tip: Although wikis can be useful for maintaining more structured information and permanent
information, the added effort to edit pages during the planning, and the potential conflicts that may
arise due to multiple people editing at one, may outweigh the benefits.
When preparing the location where the information will be stored, it is recommended to have at
least:
□ A central folder for distribution of the master copies of all documents.
□ Folders for each of the teams which they can use flexibly.
Suggested information to prepare in each of these folders is as follows, much of which has been
previously mentioned above:
All-hands folder:
□ Working agreements
□ Day 1 briefing slides
□ Day 1 briefing recordings (to be added once the presentations are complete).
□ Completed team and ART rosters, showing locations of all teams and key stakeholders and
their contact details. This should also include who is the nominated ‘facilitator’ in each
location.
□ Communication quick reference sheet, providing details of the various communication
channels and their purpose along with the links for the various conference lines.
□ ‘Cheat sheets’ with the practices and policies for using the tooling being employed.
□ Scrum of Scrums spreadsheet
□ Document for adding capacity and load, team PI objectives and risks (unless this is being
managed within online tooling).
© Scaled Agile, Inc.
11
□ Document representing program board dependencies as a table as discussed earlier (unless
this is being managed within online tooling).
□ ART and Team calendar detailing PI and iteration start and end dates as well as any other
key milestones occurring during the PI.
Team folders:
□ Day 1 briefing slides (also made available in the team folder so they can make appropriate
notes and annotations).
□ Any specific documents the team have prepared ahead of the event.
These team folders will be used throughout the event to exchange information between the teams.
PI Planning Facilitators
The term ‘facilitator’ is used in this distributed PI planning guide, since support will likely be needed
from several different people. For each location where there is a significant number of teams
present, a local facilitator is recommended.
Additionally, if there is a ‘main’ location where many of the activities are being coordinated from, it
is recommended to have a pair of facilitators. Requiring the RTE to both facilitate the event as well
as monitor requests and issues coming in from the other external facilitators is too much cognitive
load for one person. Have 1 or 2 additional people dedicated to assisting the RTE at this location.
□ Agree upon and communicate who the facilitators are for each location.
□ Identify additional facilitators to support the RTE at the ‘main’ location.
The Scrum Masters have an important role to play in a distributed PI planning event since they are
supporting the team with their local planning and helping them get access to other teams and
stakeholders they need to plan with. They may also be supporting individuals from the team who
are working in a remote location from the rest of that team.
With this in mind, preparation for a distributed PI planning should include time for the facilitators
and Scrum Masters to perform a dry run of the event to ensure they understand the processes and
tools that will be used throughout as well as surfacing, and addressing, any concerns they may
have.
□ Do a dry run of the PI planning event with the facilitators and Scrum Masters to ensure they
understand the process.
© Scaled Agile, Inc.
12
□ If needed, create a facilitator and Scrum Master ‘cheat sheet’ with critical information and
timings and any agreed upon policies for effectively running the event.
SAFe Tip: At Scaled Agile we ‘buddy up’ the Scrum Masters. This way they can give each other
greater support and ensure they help each other with being on time for the various activities in the
agenda, without the need for the facilitators to spend time locating them.
Working from Home
An extreme case of distributed PI planning, which many enterprises are facing with Covid-19, is that
every attendee is remotely working from home. In this situation there is no ‘main’ location.
Although this presents additional challenges, it provides the benefit that all attendees share the
same experience. In some cases, it can improve communication clarity as home offices are often
quieter than remotely joining a central PI planning location.
When the whole ART is present consider these factors:
□ A suitable audio/video conferencing tool should be chosen that can handle concurrent
connections from everyone on the ART.
□ All attendees should mute their line on joining the conference call.
□ Everyone who will be presenting should have a local copy of their slides ready to go.
□ An onscreen timer should be used to ensure that the speakers are aware of their time
boxes.
SAFe tip: Rather than asking, ‘What questions do people have?’ and lots of people speaking over
one another, simply ask those who are online to add their name in the chat window if they have a
question, and then the facilitator can go around one by one.
© Scaled Agile, Inc.
13
PI Planning, Day 1
Opening a distributed planning event requires all the teams to successfully connect to the
audio/video conference line. For this reason, it is recommended to have the facilitators and Scrum
Masters at each location join earlier to get these connections initiated.
Additionally, if there are some remote sites that are starting their day earlier than a regular
working day, the facilitators may have an additional task to make sure the planning rooms are
accessible to the teams.
□ Take the time to go around each location and ensure that the audio and video are working
and clear.
□ Make sure each location can see both the slides that are being shared as well as see and
hear the person who will present.
□ Test the microphones and recording capabilities from the main location.
Opening
Logistics
Once the facilitator has provided the necessary introductions, the next step is to run through the
logistics. The logistics should include the event timings and arrangements for food, since many of
the locations will be planning well into the night and may also include arrangements for transport
home after the event if this is needed.
□ Present the logistics for the event, paying attention to the start and end times for each day
and the provisions made for food and transport.
Although the specific PI Planning guidance will come later, including a more detailed presentation
of the agenda, the facilitator should take the time now to:
□ Introduce the facilitators on every site so it is clear who will support any local concerns and
how to reach them.
□ The available communication channels, including the support channel (as technical
problems can and often do occur immediately).
□ The online locations for accessing information and documents. Some attendees may want
to follow along with the briefings while accessing these documents.
© Scaled Agile, Inc.
14
Working agreements
Although we would encourage all PI planning events to have a set of working agreements, they are
a must when running a distributed PI planning. Given the scale of this event it is recommended to
start with a seeded list (some of the working agreements may also require preparation).
Suggested working agreements for such an event might include:
-
Only speak when you have the microphone
-
One conversation at a time
-
Facilitators should repeat questions to ensure they are heard clearly
-
Respect the time boxes
□ Talk through the working agreements one at a time, ensuring that they are understood and
agreed to.
□ Allow some additional time for attendees to suggest any additions to the working
agreements.
The working agreements should be displayed prominently in the main planning location and made
available to the remote teams via the chosen online storage solution.
Asking questions
Decide how the remote teams will ‘raise their hands’ in order to ask a question or gain clarification.
With so many remote participants it can be challenging to find time to interject. Many of the
conferencing tools include such a function.
□ Decide on, and share, the procedure for ensuring that the distributed attendees can
interject with a question or point of clarification.
SAFe tip: Keep in mind that people may feel uncomfortable asking a question in a scenario where
they are dialing into a room with 50+ people in it. To counter this, consider letting them post their
question directly to one of the communication channels and assign one of the facilitators in the
main location to ask the question on their behalf.
© Scaled Agile, Inc.
15
Business Briefings
The morning of day 1 of PI planning includes the business briefings which provide the business
context, the product/solution vision and the architecture vision.
SAFe Tip: In case connectivity is lost it is important that these recordings can be uploaded to the
remote location so attendees can re-watch them as necessary. Make sure there is a clearly labelled,
and separate file, for each presentation.
□ Start the recording on the audio/video conferencing line before each presentation.
During the briefings, in addition to the working agreements above, several key facilitation tips
apply.
□ Ask the presenters to inject some natural pauses into the presentations to check for
understanding and ensuring clarity of audio is being maintained.
□ The location of specific information, such as that relating to features, should be highlighted,
with links directly embedded in the presentations.
□ After each presentation the facilitators should ask each remote site what questions they
may have.
This last point is a more manageable and structured approach than simply asking what questions
the whole group has. It also ensures one group, most likely in the main room, does not have most
of the airtime.
Planning Requirements
At this point in the agenda the facilitator will run through the planning process. In addition to
reviewing the PI planning process (depending on the experience of the group) they should also
cover:
□ The different locations and time zones that they are planning across highlighting specifically
the times when everyone is available such as the team synchronization points.
□ Where the shared information of capacity and load, team PI objectives and risks will be
stored.
□ The solution that has been employed for the program board and any rules governing it.
© Scaled Agile, Inc.
16
□ The key time boxes for the first day of planning.
□ The process for booking time in with the Business Owners and other key stakeholders and
the suggested maximum time slots.
Team Breakouts 1 of 2
Depending on the number of time zones, the team breakouts may or may not have much overlap.
The guidance below will help with the situation where there is minimal overlap, and as such can be
adjusted as needed.
Preparing for the Team Planning Breakout
Although the temptation is often to jump straight into the activity of planning, several success
patterns have emerged that involve the team taking a short amount of time at the beginning of the
breakouts to ensure alignment:
□ Before beginning to plan their work, the Scrum Master who is working with each team
should check that the team understand the planning process that they will be following.
The team should then review the features they are working on, and for each one look to identify
the other teams that they will need to collaborate with. By comparing this to the agenda they can
consider when that team will be available in terms of their local time zone. In addition, if the
features are likely to require any conversations with Business Owners or other stakeholders who
will also only be available at specific times, then these should also be planned.
□ The team review their features, identifying key conversations that need to take place.
□ The team plan timeboxes with key stakeholders and other teams as required to review
these.
SAFe Tip: By taking this additional time to consider who needs to work together to plan the
features, the teams can optimize the overlapping time they have available with other teams and
stakeholders. Often the temptation is to start the conversation with those who are on hand, but
these may not be the most critical discussions to have if there are other teams who are only
available for a short period of time.
To support transparency, it is important everyone in attendance is aware of the features the teams
are planning. One approach is to have an additional ‘unplanned’ column on the program board
© Scaled Agile, Inc.
17
where the features allocated to a team can reside in their swim lane until they are planned into the
iteration they will be delivered.
Figure 4 A program board with an 'unplanned' column showing feature assignment
□ Add the features assigned to the team to the unplanned column on the program board to
ensure visibility for the other teams.
Collaborating with other teams
Of course, one of the biggest challenges during a distributed PI planning event is maintaining the
level of collaboration required between the teams. To support this, everyone must share the
responsibility of taking a proactive approach and driving the needed conversations.
Team members can and should be encouraged to use available communication channels to resolve
questions or request face-to-face time with individuals they need to work with. The Scrum Master
is not there to manage these interactions, but rather to facilitate when support is needed.
If a larger meeting is required, the Scrum Master, potentially with the support of the local
facilitator for that location, can help to organize this. Team breakout rooms with ‘always open’
conference lines make this a seamless process.
© Scaled Agile, Inc.
18
SAFe tip: Ahead of the team synchronization points the Scrum Master, along with the team, should
review any questions or issues that have been posted in theirs team communication channel. If
there are some that require resolution, they should plan out a schedule of conversations or
meetings to achieve this.
Maintaining engagement and taking breaks
If the teams, or team members, are continuously having to communicate via conference calls and
the like, it can often get tiring and maintaining focus can be a challenge. The local facilitators or
Scrum Masters should build in some breaks where the technology is turned off and energizing
activities offered to get the teams refocused alongside regular doses of fresh air.
□ Plan in breaks and ‘energizers’ at each location, especially where there is a heavy
dependence on technology.
Of course, successful planning also requires that teams and individuals should have periods of
uninterrupted time for focus on their own work. There should be a way for people to mark
themselves as busy on the various communication channels and some appropriate working
agreements for how to override these when there is an urgency. At the very least alerts can be
turned off and the expectation should not be that a reply is actioned immediately.
□ Determine a process for people marking themselves as busy to prevent constant
interruptions. (These time periods should not be too long but should be respected).
Hourly Scrum of Scrums
The Scrum of Scrums serves two main purposes. It prevents the teams getting derailed by
unknowns or unnecessary levels of detail and brings the Scrum Masters together to share issues or
challenges they and their teams may be facing. The purpose of the Scrum of Scums remains the
same in a distributed PI planning event. Of course, one main difference is that only a subset of
teams may be able to attend at the same time depending on whether their team breakouts are
overlapping. A mitigation to this is to also run a Scrum of Scums at the beginning of each team
synchronization point in the agenda.
□ Run a Scrum of Scrums at the beginning of each team synchronization point in the agenda.
Because of the asynchronous nature of the scrum of scums in a distributed PI planning event, it is
important to have the Scrum of Scrums information radiator as an online document so everyone
can track the progress across the ART and make their updates.
© Scaled Agile, Inc.
19
SAFe Tip: Encourage the Scrum Masters to keep the Scrum of Scrums information radiator up to
date regardless of when the Scrum of Scums itself is taking place. Remember, this is as much a
document for the teams to track their own progress as it is to synchronize across the teams. This
will bring early visibility to any potential planning problems.
Continuous risk roaming
ROAMing risks typically happens at the end of the second day of PI planning, although we have
seen many enterprises run this activity at the end of both days. In a distributed event addressing
the risks more often will certainly provide benefits.
Options include doing this as part of the Scrum of Scrums, where the accumulated risks to date are
reviewed and followed up with the team who raised them, either proceeding to ROAM them or
agreeing with the team that they will be managed later during the formal ROAMing activity.
Another alternative is to run a short all attendee risk ROAMing activity at the beginning of each of
the Team Synchronization points in the agenda.
□ Agree on the process for addressing risks more often throughout the event.
Preparing for the Draft Plan Review
It makes good sense for the teams to spend some of the time at towards the end of their breakouts
to prepare, ensuring the draft plan review runs smoothly and takes no longer than it needs to.
These preparations include:
□ The team have added their capacity and load, draft team PI objectives and risks to the
online document that will be used to present from.
□ They have given some consideration to their current confidence level about the draft plan.
□ They have discussed any challenges with the distributed PI planning process that they want
to raise.
(More on these last two points shortly).
© Scaled Agile, Inc.
20
Draft Plan Review
The draft plan should be presented from the online document (or tooling), regardless of how many
teams are present in the room. This will ensure that everyone has the same access to information
and a similar experience. As with the previous business briefings, the facilitator should go around
to each location to check for questions after each plan review. Timeboxing is important here as it is
often the case that the draft plan review is late into the night for at least one of the distributed
teams.
One behavior that many organizations have benefited from is to ask the teams to present their
confidence vote as part of the draft plans, they have created so far. This will help to identify teams
who may need more support the following day (or later that day depending on the agenda in
place). This is a good practice in a distributed PI planning event.
□ Ask the teams their current confidence vote during the draft plans.
With everyone together during this draft plan it can be an opportune time for teams to raise
challenges they are having connecting with a stakeholder or team, and then arrangements can be
made to ensure these collaborations take place the following day.
□ At the end of their draft plan review, ask each team if they are facing any challenges with
the planning process and who they need to collaborate with on the following day.
SAFe Tip: When going through the draft plan review and the associated risks and impediments, it
can be useful considering who else might be needed in the management review and problemsolving meeting which follows. Because clarity of information can be a challenge in distributed
environments, having the ‘source’ of the information in this meeting can be useful if they are
available.
Management Review and Problem-Solving Meeting
Sometimes the management review may fall in the middle of the second day if a 3-day agenda, like
the one shown in Figure 2, is being employed. If this is the case then, unlike the standard PI
planning agenda which allows this meeting to expand as required, it will need to be tightly
timeboxed.
© Scaled Agile, Inc.
21
Teams can use this additional time to continue to work on their own plans, being mindful to stay
away from anything that might be adjusted based on the output from the management review, but
might be better served to take a well-earned break.
Of course, the management review itself will likely need to be conducted as an online event. Make
sure all of those who are required to attend have the event in their calendar with the necessary
connectivity information.
□ Send out invites to the management review and problem-solving meeting.
The outputs from the management review should be added into an online document so it can be
presented back to the teams. Add these planning adjustments into the remote folders immediately
after the meeting so they are ready for the teams to access the next day.
□ Add the planning adjustments into the online folder for the teams to access and notify
everyone via the PI planning communication channel.
It could also be the case that some teams will need to begin their second team breakouts before
the planning adjustments have been presented to the ART. If this is the case a specific Business
Owner, who can talk to the adjustments that affect that team, should contact them directly or
alternatively a recording should be made for the team.
□ If required (as described in the scenario above), organize for Business Owners to contact the
teams who are affected by the planning adjustments. If this is not possible, a recording
should be distributed.
SAFe Tip: Since all the key stakeholders are at the management review and problem-solving
meeting, why not take some time at the end to reflect with them on how the day went. Discuss how
the interactions were between them and the teams. Were there any teams that they did not
interact with, and how can this be resolved for the next day?
© Scaled Agile, Inc.
22
Facilitator Debrief
The facilitators, and the Scrum Masters if they are available, should find time at the end of the first
day to discuss and reflect on the planning so far, as well as reviewing some of the feedback that has
come into the communication channels. Based on this feedback they can decide what ‘facilitating
adjustments’ need to be made for the next day.
□ Add some ‘facilitating adjustments’ to the planning adjustments document.
PI Planning, Day 2
Scrum of Scums
Running an additional Scrum of Scrums before the day begins provides an opportunity for the
facilitators and Scrum Masters to assess the progress of the previous day’s planning, create specific
actions for the day ahead and make any required adjustments to the timeboxes.
□ Start the day with a Scrum of Scrums to assess planning progress and identify actions.
Day 2 Opening
As well as providing an overview of the planning process for the second day of PI planning, the
facilitator should also take some time to review the working agreements again, as well as any new
working agreements that have been added based on the feedback from the previous day.
□ Review working agreements and ask the attendees for any additions they would like to
make.
□ Explain the process for booking time with the Business Owners for scoring the final team PI
objectives (described below).
Planning Adjustments
As with previous presentations the planning adjustments should be presented, recorded and
placed into the online folder on completion. After the presentation of the planning adjustments
clarifying questions should be taken from the teams. From this discussion it is often the case that
meetings are planned between specific teams and Business Owners.
© Scaled Agile, Inc.
23
□ Check for understanding of the planning adjustments from all the teams.
□ If available, add the recording of the planning adjustments into the online folder.
□ Organize meet-afters for the teams and specific Business Owners as required.
Additionally, run through the previously mentioned adjustments to how the day 2 will be facilitated
as well as any changes planned to the timeboxes.
□ Communicate any facilitation planning changes and any modifications to the agenda.
Team Breakouts 2 of 2
Team breakouts will follow a similar process on day 2. Additionally, during the second breakout the
teams will have their PI objectives scored by the Business Owners.
A sensible way to manage this is to use the Business Owner calendar, previously mentioned, and
ask the Scrum Masters to work with their team and the RTE to book an appropriate slot for when
they feel they will be ready.
□ Teams book time with the Business Owners when they are ready for the business value
assignment.
□ Share the conference link to be used for the teams to join the Business Owners.
Although the confidence vote is still to come, to reduce some of the time it takes to go around each
individual team it is common practice to have the teams conduct this confidence vote ahead of
time and integrate the results into the final plan review.
□ Consider asking the teams to prepare their team confidence vote ahead of time and
incorporate it into the upcoming final plan review.
□ Ensure that the teams update their capacity and load, final team PI objectives and risks into
the online plan review document.
Final Plan Review
This is conducted in a similar manner to the draft plan review, with the exception that at the end of
the presentation the teams will ask the Business Owners if they accept the plan. As before, each
location should be asked what questions they have, after each team have presented their plans.
□ Go around the various locations asking what questions they have for the team who have
presented their final plans.
© Scaled Agile, Inc.
24
SAFe tip: An alternative approach for reducing some of the complexity of the upcoming confidence
vote is to ask the teams to do their team confidence vote immediately after presenting their plans
whilst the team themselves are all visible on the conference line.
□ Optionally ask the team to present their confidence vote on conclusion of their final plan
review.
The presented risks will be ROAMed afterwards, in much the normal way, the difference of course
that they will be done on a shared online document.
Confidence Vote and Plan Rework
SAFe Tip: If possible, make sure that the whole ART is visible on the audio/video conference line
during confidence vote. It is important for everyone in attendance to have the ability to ‘stop the
train’ if they have identified something amiss with the plans.
□ Ensure all locations have their webcams on ahead of the ART confidence vote on the video
conferencing.
The ART confidence vote should be done with everyone simultaneously, with the facilitator taking
time to review each of the locations and allowing anyone who voted 1 or 2 to express their
opinions.
If the ART is fully distributed with all attendees working from home, it may not be feasible to go
around each connection checking on their vote. In these circumstances asking every to enter their
vote into one of the online communication channels makes it easier for the RTE to scan for 1s and
2s and then ask those individuals for further information. Alternatively adding ‘stickies’ to an online
retrospective tool with designated areas for the 5 possible votes works well.
□ Request attendees to add their vote into one of the communication channels or into an
online retrospective tool.
□ Allow time for anyone who voted 1 or 2 to express their opinions and share their concerns.
© Scaled Agile, Inc.
25
If planned rework is required, due to the time zone differences, this may need to be an activity that
is postponed to the following day, potentially with the support of stakeholders.
□ If needed, agree the time when the planned rework will take place and who needs to be in
attendance.
Planning Retrospective
The planning retrospective is important to continually improve the experience of these distributed
PI planning events. It can be useful to add some time at the beginning of this activity for attendees
to share feedback specifically on the distributed PI Planning experience.
□ Get feedback from the attendees on the distributed PI planning experience.
SAFe Tip: Although allowing the individuals to anonymize their comments can be useful to get the
highest degrees of honesty when conducting a retrospective, consider asking them to add their
location as this can help the facilitators when reviewing the information to isolate comments that
may be due to the distributed nature of particular teams. This will also help identify appropriate
actions to rectify this for the next event.
□ Add the location of where the feedback came from as this can help to inform the necessary
corrective action.
Caution spending too long on the retrospective and certainly delay the analysis of the data to a
later date. It is likely late in the day for some of the time zones, and regardless people will be
getting tired. Don’t make them work more than is necessary.
© Scaled Agile, Inc.
26