Easy Agile - The Ultimate Guide To PI Planning (2020 SAFe Edition)

2/25/2020 Easy Agile | The Ultimate Guide to PI Planning [2020 SAFe Edition]
The Ultimate Guide to PI Planning [2020

SAF Edition]
a
Published 12 Dec 2019

by Sean Blake, Head of Marketing
https://www.easyagile.com/blog/the-ultimate-guide-to-pi-planning-2020-safe-edition/ 1/30
When you’re getting started with scaling agile in your company, the thought of
bringing multiple agile teams together in the one room is enough to bring on cold
sweats. 😰💭
Or maybe you’ve been doing PI Planning for a while now, but it’s not running too
well and you’re thinking of throwing in the towel.
🦸 Never fear, Easy Agile is here!
We’ve put together this complete guide to PI Planning in 2020. We’ll help destroy
the myths and crack the code to running successful and effective SAFe PI
Planning sessions.
In this guide you’ll learn about what PI Planning is, why it’s so important for your
business, how to get started, and much more.
Plus, we answer a bunch of FAQs about PI Planning so you can feel confident
enough to be part of an event (and start using all the lingo).
This PI Planning Ultimate Guide ain’t short, so if you want to scroll ahead to a bit
that’s most interesting/useful to you, be our guest. We’ll cover:
What actually is PI Planning?

Why do PI Planning?
What is the goal of PI Planning?
What should be included in the PI Planning agenda?
What is accomplished in the first part of the PI Planning
meeting?
Why is a confidence vote held at the end of PI Planning?
When is PI Planning held?
What is a pre-PI Planning event and when is it needed?
What does SAFe have to do with PI Planning?
What is PI Planning in Scrum?
What is the difference between a PI Roadmap and a

Solution Roadmap?
What is a program?
What’s a program board?
Who should be involved in PI Planning?
What should we do to prepare for PI Planning?
What do you do after PI Planning?
What is post-PI Planning?
Tips for distributed teams and remote PI Planning
Common mistakes and challenges
Using Jira for PI Planning
Anything else you’d like to know about PI Planning?
Let’s start with the basics…
What actually is PI Planning?

PI Planning stands for Program Increment Planning.
PI Planning sessions are regularly scheduled events held throughout the year
where multiple teams within the same Agile Release Train (ART) meet to align to
a shared vision, discuss features, plan the roadmap, and identify cross-team
dependencies.
Here are the essential elements of PI Planning:
2 full day events run every 8-12 weeks (depending on the

length of your increments)
Product Managers work to prioritize the planned features for
the increment beforehand
Development teams own user story planning and estimation
Engineers and UX teams work to validate the planning
The goal is to align the teams to the mission and each other
Everyone attends in person (if possible)
Technology is used to allow distributed teams to participate
(if needed)
If you’re adopting SAFe for the first time, chances are, it’ll start with PI Planning.
That’s because it forms the foundation of the Scaled Agile Framework.
Quick definition: SAFe or the Scaled Agile Framework™ is a series of guidelines

and practices designed to help bring agility into larger organizations, across all
teams and levels of the business. The framework is geared at improving visibility,
alignment, and collaboration and should lead to greater productivity, better results,
and faster delivery.
Whether you’re adopting all 5 levels or just essential SAFe, the foundation of your
transformation and the driver for everything is the PI Planning ceremony.
No pressure! Though seriously, if your team gets PI Planning right, it makes

everything in the upcoming increment so much easier.
So let’s dig a little bit deeper into the why…
Why do PI Planning?
PI Planning is incredibly beneficial for large scale agile organizations.
To understand the impact, let’s look at some numbers. For example, some larger
organizations might have 200-300 teams and 10,000 developers. In the old way of
working, these teams would never have spoken to one another before. 😢 (until
there was a critical problem that forced them to talk)
Previously, alignment would have been at the leadership team level, and they’d
have multiple levels of managers in between who cascade information down, but
the people on the teams would never talk to one another. There would be a
constant battle for resources, budget, and opportunities to work on the sexiest
projects.
Speaking of projects, these had a habit of conflicting - one team would release
something and then it would break something in another team’s project.
PI Planning is the first time many of these really big companies get their teams
together in a room or on the same call and talking to each other. They get the
chance to nut out those important conversations about who’s working on what.
This is kind of a big deal because:
When you’re touching a system or a code repository, you

need to know how it’s going to impact another team
You might need to do some work to enable another team to
work on their feature first (and vice versa)
PI Planning enables:
🗨 Communication
👀 Visibility
🙌 Collaboration
As a result, teams can get things done more effectively, release more features in
less time, and stay on budget.
All very good reasons to do PI Planning. But let’s also look at the big picture…
What is the goal of PI Planning?
PI Planning is an essential part of the Scaled Agile Framework, a framework that’s

designed to bring agile to large companies with multiple teams. 🏢
SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize,
collaborate, and align on workflows, objectives, releases, and more.
On the flip side… without PI Planning, teams don’t have structured

communication. They may not know what the other teams are working on, which
can cause a lot of problems. For example, two teams might be working on
different features without realising there’s a dependency which could hold up the
release or require a significant rework of the code. ❌🤦
So, the goal of PI Planning is to get all your teams aligned strategically and enable
cross-team collaboration to avoid these potential problems.
Now that we’ve covered off the “why”, let’s dig a bit deeper into the “what”. The
best way to get a picture of what happens during PI Planning is to take a look at
an agenda.
What should be included in the PI Planning agenda?
Here’s a standard PI Planning agenda template suggested by the SAFe website:
Day 1
8:00am-9:00am
Business context
9:00am-10:30am
Product/solution vision
10:30am-11:30am
Architecture vision & development practices
11:30am-1:00pm
Planning context & lunch
1:00pm-4:00pm
Team breakouts
4:00pm-5:00pm
Draft plan review
5:00pm-6:00pm
Management review & problem solving

Day 2
8:00am-9:00am
Planning adjustments
9:00am-11:00am
Team breakouts
11:00am-1:00pm
Final plan review & lunch
1:00pm-2:00pm
Program risks
2:00pm-2:15pm
Confidence vote
2:15pm-X:XXpm
Plan rework (if needed)
When ready
Planning retrospective & moving forward
Source: scaledagileframework.com/pi-planning
This agenda might be perfect for you, or you might tweak it based on your team’s
needs. Distributed teams, very large ARTs, and other factors might require you to
get creative with the schedule. You might find that some sessions need more time,
while others can be shortened. If it’s your first PI Planning event, try the standard
agenda, get feedback from your teams, and experiment with different formats next
time. 🥼🧪💥
Now, let’s get a little more specific about the agenda items - in particular, what
happens during those first few hours of a PI Planning session on day 1.
What is accomplished in the first part of the PI Planning meeting?

The first thing you’ll do is gather around in a circle with the rest of your Agile
Release Train and chant mantras, like:
🧘 Think positive thoughts
😊 I am smart, I am kind, I am important
💡 I love lamp
Nah, just kidding. What’ll actually go down is much less exciting (but necessary).
Although it could be exciting if business discussions are your thing. 🤷🤓
Day 1 usually kicks off with a presentation from a Senior Executive or Business
Owner. The agenda allows an hour to talk about the current state of the business.
They highlight specific customer needs, how the current products address these
needs, and potential gaps.
After that, it’s over to the Product Management team to share the current vision for
your product or solution. They’ll talk about any changes that have occurred since
the last PI Planning session (usually around 3 months prior). And they’ll cover off
what’s coming up, including milestones and the next 10 features that are coming
up. This session should take around 1.5 hours.
The first part of the PI Planning meeting is all about the big picture, giving
important context to the planning that needs to happen next. Now let’s skip ahead
and talk about something really important that happens at the end of the meeting.
Why is a confidence vote held at the end of PI Planning?
The confidence vote is a seemingly small but very important part of PI Planning.
Here’s how it works…
It happens almost at the end of your PI Planning event. The Release Train
Engineer asks “Will we meet the objectives?”
Everyone in the room needs to vote by raising a hand (and fingers). 🤚
If the average vote across the room is at least 3 fingers, the plan is a go-ahead. If
it’s less ✌ it’ll need reworking (until it reaches a high confidence level). Plus, if
anyone votes using just one or two fingers, they’ll have the chance to share the
reasoning.
(If anyone gets creative and does the Napoleon Dynamite thing, the room gets
thrown into chaos. Try it!)
The confidence vote is all about making sure that the attendees are in alignment
and that they agree that the plan in its current form is do-able within the given
timeframe. Speaking of timing, let’s talk about how and where PI Planning actually
fits into your company calendar.
When is PI Planning held?
Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations)
is the right amount of time for an increment.
Some companies hold quarterly PI Planning, for example:
Q1 PI Planning: December
Q2 PI Planning: March
Q3 PI Planning: June
Q4 PI Planning: September
But the timing and frequency will depend on how long each program increment is
scheduled to last.
📅 The good thing about PI Planning events is that they happen regularly on a
fixed schedule, which means you can plan for them well ahead of time. That
means teams and Business Owners have plenty of notice to ensure they can
show up for the event.
Before we go any further, let’s backtrack a little. Because depending on how you
do agile, there’s actually something that needs to happen before you can run PI
Planning. Yep, we’re talking about pre-PI Planning (what SAFe lack in creative
names, they make up for in good systems and processes 😉).
What is a pre-PI Planning event and when is it needed?

Yep, this is a thing. Because apparently the two-day PI Planning event just isn’t
enough.
But they exist for a very good reason - to make sure that the ART is aligned within
the broader Solution Train before they do PI Planning. It’s all about synchronising
with the other ARTs to ensure the solution and organization are heading in the
right direction, together.
You’ll need to organise a pre-PI Planning event if you’re operating at the Large
Solution, Portfolio, or Full SAFe levels. Essential SAFe is more basic and does not
have a Solution Train, so if you’re operating at this level, you won’t need pre-PI
Planning.
If this was Thomas the Tank Engine, we’d think of this a little bit like Thomas,
Percy, and James as separate ARTs all teaming up to be Very Useful Engines and
haul separate loads for the same overall purpose.
🚂 Thomas would carry the passengers
🚂 Percy would pick up the fireworks
🚂 James would bring the picnic food
…and everybody would have a very nice time.
(We’ve deliberately left Gordon out… he’s not a team player.)
But back to pre-PI Planning events. What usually happens is that key people get
together from the Solution Train, along with representatives from the ARTs and
relevant suppliers. Here are a few of the folks you’ll find at the planning event:
Solution Train Engineer

Solution Management
Solution Architect/Engineering
Solution System Team
Release Train Engineers
Product Management
System Architects/Engineers
Customers
They’ll look at the top capabilities from the Solution Backlog, Solution Intent,
Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher
level, across the overall solution and not just the individual ART.
The event starts with each ART summing up their previous program increment
and accomplishments to set the context. Next, a senior executive will brief the
attendees on the current situation before Solution Management discusses the
current solution vision and any changes from what was shared previously. Other
things that are often discussed or finalized include:
Roadmaps
Milestones
Solution backlogs
Upcoming PI features from the Program Backlog
Okay, so back to talking about regular PI Planning. It’s time to properly define a
few of these terms we’ve been touching on, like SAFe, Scrum, Roadmaps, and
Programs. Hopefully, if it hasn’t already, the lightbulb will start to come on for you
in 3, 2, 1… 💡
What does SAFe have to do with PI Planning?

We’re not a huge fan of complicated acronyms (maybe we’re in the wrong industry
😂). But SAFe is one worth knowing. It stands for Scaled Agile Framework.
SAFe is the world’s leading framework for scaling agile across the enterprise.
(State of Agile Report)
For a bit of perspective - Scrum and Kanban are also agile frameworks (that you
may be more familiar with), and these have historically been very effective at the
individual team level. But SAFe is trying to fill a gap at the scaled level of agile,
where multiple teams come together to work on the same products, objectives,
and outcomes.
Hang on… what does this have to do with PI Planning?
SAFe outlines what should happen at each level of the organization to make sure
that scaled agile is successful. It goes way beyond the team level to include every
stakeholder.
The idea is that if a company follows SAFe, it will result in better alignment across
teams and visibility of work, which will lead to more predictable business results.
✔📈
This is increasingly important as the environment for organisations continues to

change and customers expect more features to be delivered more quickly. The
traditional waterfall approaches fall short because they’re slow and inefficient.
Big, older companies (often with thousands of developers) can’t keep up with the
innovation of smaller, more nimble startups. Along with bigger teams, larger
organizations often have stricter requirements around governance and
compliance, which can make it harder to move quickly.
It can take 3-4 years for these bigger, more complex companies to launch a new
feature, which won’t fly with customers these days. Plus, they often struggle to
manage and organize their (many!) teams of developers, which also stops them
from launching projects on time.
They need to make a change to speed things up, make the most of their
resources, and minimize budget blowouts. These companies are looking for new
ways to organize people into projects and introduce more effective ways of
working. If they don’t, they face extinction. 🦕☠
SAFe is a way for these companies (that otherwise would stay stuck in their old
ways) to start moving in a more agile direction.
Which is where PI Planning comes in…
PI Planning is a vital element of SAFe. It’s a ceremony that brings together

representatives from every team to help them work together, decide on top
features to work on next, identify dependencies, and make a plan for the next
Program Increment. As a result, there’s greater visibility across all the teams,
changes are made more frequently, and teams work with each other - not against
each other. From there, these massive companies can speed up their processes,
work more efficiently, compete with newer and more nimble companies, and stay
viable.
SAFe and PI Planning to the rescue! 🦸🏆
Side note: while SAFe is a framework for larger organizations, there’s also no
reason why smaller companies can’t do a version of PI Planning, too. All you need
is more than one agile team to make it worthwhile.
Now for another definition…
What is PI Planning in Scrum?

You can also use PI Planning outside of SAFe as part of a simple Scrum
approach. 🤯
Alt text: Scrum Framework diagram shows when and how scrum teams can
implement PI Planning
Source: Scrum.org
Scrum is an agile framework that helps teams get things done. It’s a way for
teams to plan and organize their own work and tackle user stories and tasks in
smaller time boxes. This is often referred to as a sprint.
(Not that kind of sprint 🏃 - we’re talking about the standard 2-week iteration for
work and releases, of course.)
If multiple scrum teams want to work better together (but aren’t necessarily
operating within SAFe), they could adopt a version of PI Planning.
For example, these scrum teams could:
Meet every 10 weeks and discuss the features they are

planning to work on
Get product managers to combine backlogs and prioritize
together
Share resources across the teams, as needed
Map dependencies and coordinate joint releases
The good news here is that there’s no “one size fits all” approach to PI Planning,
so think about how you could adopt the ideas and principles and make it work for
your organization. 🤔
Speaking of PI Planning ideas… one of the most useful parts of PI Planning is the
roadmap (although we may be somewhat biased since we created Easy Agile
Roadmaps 😛). Here’s one question that we’ve seen come up a few times:
What is the difference between a PI Roadmap and a Solution Roadmap?

There are a few different types of roadmaps in SAFe, so it’s important to
understand the differences and what each roadmap is meant to do.
Your PI Roadmap is created before your PI Planning event, and also reviewed
and updated by Product Management after the event is finished. It will usually
cover three Program Increments:
The current increment (work that’s committed)

The next forecasted increment (planned work based on
forecasted objectives)
The increment after that (further planned work based on
forecasted objectives)
If you do quarterly PI Planning, it’ll outline around 9 months of work. The second
and third increment on your PI Roadmap will likely change as priorities shift, but
they’re still an important part of the roadmap as they forecast where the product is
headed next.
So, what’s the Solution Roadmap all about?
The Solution Roadmap is a longer term forecasting and planning tool for a specific
product or service. 🔭🗺
It will usually cover a few years at a time, with more specific details available for
year one (like quarterly features and capabilities), and more general information
(like objectives) for year two and beyond.
Now that we’ve cleared up roadmaps, scrum, and SAFe, it’s time for another
definition to help you understand the context of how PI Planning fits into the bigger
picture of agile and SAFe…
What is a program?
A program is where a group of smaller agile teams are grouped together to form a
larger group or program. This is often referred to as the “team-of-teams” level.
When you hear people talking about team of teams or scaled agile, they mean
taking agile beyond a single team, and asking more teams to join in.
For example, there might be 4 teams working on a NASA spaceship mission to

Mars. 🚀
NASA decides they want to see if agile can help these teams do better work. So,
to start with, the Oxygen team switches from working with traditional Waterfall
project management methods to embracing agile principles.
Launch team
Food team
Oxygen team - Agile!
Landing team
After a few months, NASA decides that this agile thing is really working well. So
they get 3 more teams to move over to agile methodology.
Launch team - Agile!

Food team - Agile!
Oxygen team - Agile!
Landing team - Agile!
Each of these 4 teams are self-organising, meaning they’re responsible for their
own work.
However, now that these teams are all working in the same way, they can be
grouped together as a program.
So in simple terms, a program is a group of agile teams. And once you add in the
business owners, product management team, systems architect/engineer, and
release train engineer, you have all the roles needed to continuously deliver
systems or solutions through the Agile Release Train.
Now for one more definition…
What’s a program board?

Program Boards are an important part of SAFe and PI Planning.
Traditionally, they’re a physical board that’s mounted on the wall, with columns
drawn up to mark the iterations for the increment, and a row for each team. Teams
add sticky notes that describe features they’ll be working on.
🏷 Feature 1
🏷 Feature 2…
Once all the features are added, they work to identify dependencies (features
that’ll affect other features) and mark this up by connecting them with red string.
SAFe program boards don’t have to be physical, though. There are a lot of
advantages to using a digital program board like Easy Agile Programs, which
integrates directly with Jira. We’ll talk more about how you can use Jira for PI
Planning towards the end of this guide. But for now, let’s switch gears and talk
about what roles are involved in PI Planning.
Who should be involved in PI Planning?

There are 5 key roles in a PI Planning event:
🚂 Release Train Engineers
💼 Product Managers
Product Owners
🕵 Scrum Masters
Developers
Let’s take a closer look at what each of these roles is responsible for during the
event.
Release Train Engineer
The Release Train Engineer is a servant leader and coach for the ART. Their role
focuses mainly on planning and facilitating the PI Planning event. This means they
help:
Establish and communicate the annual calendars

Get everything ready (including pre and post PI Planning
meetings)
Manage risks and dependencies
Create Program PI Objectives from Team PI Objectives and
publish them
Track progress towards expected goals
Ensure strategy and execution alignment
Facilitate System Demos
As the facilitator for the 2-day event, the Release Train Engineer presents the
planning process and expected outcomes for the event, plus facilitates the
Management Review and Problem Solving session and retrospective.
Product Manager
A Product Manager’s job is to understand the customers’ needs and validate

solutions, while understanding and supporting portfolio work.
So, what is the product manager’s role in PI Planning?
They present the Program vision (aka top 10 Features that are coming up) plus
any upcoming Milestones. They review the Draft plan and describe any changes
to the planning and scope based on the Management Review & Problem Solving
session. That way, they can manage and prioritize the flow of work. Once the PI
Planning event is over, they use the Program Objectives from the Release Train
Engineer to update the roadmap.
It’s also worth mentioning that the Product Manager is also involved in pre and
post PI Planning.
Before PI Planning happens, a pre-PI Planning meeting is held, where Product

Managers and other ART representatives who make up part of the same Solution
Train discuss and define inputs, objectives, and milestones for their next PI
Planning events.
Post-PI Planning involves gathering ART representatives together again to

discuss how their PI Planning events went and summarizing any findings into
Solution PI Objectives. Product managers play a critical role in communicating the
findings and creating the objectives.
Product Owner
The Product Owners are responsible for maintaining and prioritising the Team
Backlog, as well as Iteration Planning. They have content authority to make
decisions at the User Story level during PI Planning Team Breakout sessions.
Product Owners help the Team with defining stories, estimating, and sequencing,
as well as drafting the Team’s PI Objectives and participating in the Team
Confidence Vote. They’re also responsible for conveying visions and goals from
upper management to the team, as well as:
📝 Reporting on key performance metrics
🤔 Evaluating progress, and
🗨 Communicating the status to stakeholders
Scrum Master
The Scrum Master is a servant leader to the Product Owner and Development
team, which means they manage and lead processes, while helping the team in
practical ways to get things done.
They facilitate preparation for events (including PI Planning) and prepare System
Demos. They help the team estimate their capacity for Iterations, finalise Team PI
Objectives, and manage the timebox, dependencies, and ambiguities during Team
Breakout sessions. The Scrum Master also participates in the Confidence Vote to
help the team reach a consensus.
Developer
Developers are responsible for researching, designing, implementing, testing,

maintaining, and managing software systems.
During PI Planning, they participate in Breakout sessions to create and refine user
stories and acceptance criteria (alongside their Product Owner) and adjust the
working plan. Developers help with identifying risks and dependencies, and
support the team in drafting and finalizing Team PI Objectives, before participating
in the Team Confidence Vote.
At this point, you’ve got all the key definitions, you know what needs to happen
during a PI Planning event and who needs to show up.
But how do you actually prepare your teams and space before you get started?
What should we do to prepare for PI Planning?

“By failing to prepare, you are preparing to fail.” - Benjamin Franklin
If you want to succeed at PI Planning, make sure you don’t skip over the
prepwork!
Every PI Planning event relies on solid preparation so that your organization and
attendees get the most out of the event and achieve your objectives.
So, what’s planning actually look like?
The participants themselves (plus key stakeholders and Business Owners) must
get ready by assigning any key roles, ensuring there’s alignment on the strategy,
and ensuring the planning process is properly understood by everyone.
Any presenters will also need to get content ready for their presentations.
Plus, you’ll need to ensure the facility is ready - especially since you may have
hundreds of participants attending. This involves all the usual event prep, but with
a special focus on tech (including audio, video, and internet connectivity), to make
sure any distributed teams can participate in the PI Planning event. Don’t forget to
plan for enough food for everyone, too (planning is hungry work).
So, at this point, we have a clear picture of what happens during and before a PI
Planning event, but what about afterwards?
What do you do after PI Planning?

After PI Planning, teams do a planning retrospective and list out:
😋 What went well (good snacks)
🙁 What went not-so-well (not enough snacks)
🎂 What could be better for next time (erm, Lenny, please don’t eat all the
brownies, in future)
And then there’ll be a chat about the next steps. These steps can include things
like:
Getting copies of the objectives, user stories, and program

board into your project management tool (like Jira)
Taking a look at calendars
Chatting about meeting times and locations for daily stand-
ups and iteration planning
Making sure that everyone has their belongings and leaves
the event rooms clean when they go
The other thing that usually happens after PI Planning events is a post-PI
Planning event.
What is post-PI Planning?

These are similar to the pre-PI Planning events we already talked about. They
involve getting together ART stakeholders across all the Agile Release Trains
within the solution train to ensure they’re synchronised.
Post-PI Planning happens after all the ARTs have completed their PI Planning for
the next increment. They present the plans, explain their objectives, and share
milestones and expected timelines.
Like PI Planning events, post-PI Planning involves using a planning board, but
rather than features, it outlines capabilities, dependencies, and milestones for
each iteration and ART. Potential issues and risks are identified, discussed, and
either owned, resolved, accepted, or mitigated. And similar to regular PI Planning
events, plans go through a first-of-five vote of confidence to ensure they meet the
solution’s objectives, and are reworked until the attendees average 3 fingers so
more.
But what about PI Planning events for distributed teams and remote team
members? How do they collaborate via planning boards, do votes of confidence,
and things like that? Running a successful PI Planning event with people both in
and out of the room can come with some extra challenges…
Tips for distributed teams and remote PI Planning

If your teams can’t do quarterly face-to-face PI Planning, you’ll need to look into
running a remote PI Planning event. Don’t worry - it’s very do-able and ideal for
organizations with distributed teams or flexible work arrangements. Plus, it’s a lot
cheaper than flying folks in to do PI Planning every few months. 🙌
If you’ve got the right tools and technology, you can run PI Planning and allow
anyone to participate, whether they’re in the same room or on the other side of the
world 🌏.
Here are a few tips to help you make it work:
Co-locate
Rather than having everyone tune in from their separate remote locations, co-
locate teams as much as possible. You might set up a main headquarters for
hosting the leadership group and nearby teams, and then fly distributed workers
into their nearest remote location. ✈ That way, everyone still gets an element of
face-to-face collaboration.
Embrace the cloud
☁ Use online shared planning tools to allow your team to access and interact
with information as soon as possible - perhaps even in real time. Making sure
every participant has immediate visibility on the information makes it easier to
map cross dependencies and avoids storing the info in 10+ different places.
Livestream the event
Face-to-face is ideal, but when that’s not possible, the next best thing is to
livestream audio and video from the event and from participants. 📶 That means
you’ll need to encourage any remote or distributed teams to use their cameras
and microphones during the event. It’s not quite the same as having them in the
room with you, but it’s pretty close.
Record it
Ideally, everyone will participate in the PI Planning live. But whether your team is
distributed across multiple timezones or a couple of team members can’t make it
on the day due to sickness or something else, it’s a good idea to record the event,
too. 📹🎤 Plus, having a recording to refer back to could be useful for attendees
who want a refresher on anything that’s been discussed.
Adapt
Some teams will change the standard PI Planning agenda to fit multiple
timezones, which could mean starting the event earlier or later for some, or even
running it across 3 days instead of 2.
Lay down the law
One common issue that can arise from having distributed teams tune in remotely
via video and audio is too much noise and interference. Before your first session
kicks off, communicate about when it’s acceptable to talk and when teams need to
use the mute button. 🔉 🔇 That way, your teams will avoid getting distracted,
while still ensuring everyone can participate.
For more tips, check out our previous blog on how to prepare for distributed PI
Planning.
Common mistakes and challenges

PI Planning doesn’t always go… well, to plan. And the framework itself may
present a challenge to some organizations. Here are some common mistakes and
challenges to keep in mind (and avoid, if possible):
Long, boring sessions
One of the major downsides of PI Planning is the suggested agenda includes

some long, heavy sessions, right from the start. 😴 It might be worth looking at
creative ways to make these sessions more engaging, delivering the business
context information in a different format, or adapting the timeline so they’re
shorter. That way, there’s more time for team planning and collaboration.
Tech issues
Any event is vulnerable to tech mishaps, but if you’re streaming audio and video
to a distributed team, this can really impact on the flow of the event. It’s a good
idea to carefully test all the equipment and connections ahead of time to minimise
potential problems. 🖥🔌
Confidence vote
Some PI Planning participants have struggled with the confidence vote concept in
the past. People may feel pressure from the room to vote for a plan to go ahead,
rather than speaking up about their concerns. 👎👍
Time constraints
⌛ When you have a large ART of, say, 12 teams, that’s a lot of draft plans to
present and review. Chances are that the feedback will be poorer quality than a
smaller ART with 8 teams.
Not committing to the process
SAFe isn’t perfect and neither is PI Planning. But the process has been proven to
work for many organizations. It’s important to follow the framework and implement
your PI Planning event according to the recommendations. Then commit to the
process that follows.
Sticking with the same old tools
If something’s not working, fix it. For example, too many teams stick with
traditional SAFe Program Boards even though they’re not always practical. 🏷🏷
If the post-it notes keep escaping, the data entered into Jira seems a bit off, or
you’ve got a distributed team who want a digital way to be part of your PI Planning
event… it’s time to upgrade to a digital program board like Easy Agile Programs.
Speaking of software, it’s (finally) time to talk about Jira!
Using Jira for PI Planning
Jira is the most popular project management tool for agile teams, so if you’re
agile, chances are you’re already using it at the team level.
Jira is great for single teams. It has ALL the bells and whistles. 🔔✨
But when you need to implement agile at the scaled level as part of an ART, it can
be tricky to properly visualize work that’s happening across multiple teams. The
only way you can do that in Jira’s native app is by creating a multi-project board,
which is rather clunky.
So, how does Jira fit into SAFe and PI Planning?

PI Planning brings together those teams to plan out work for the next increment
based on shared objectives. During PI Planning, teams use a Program Board to
plan out their work and map dependencies. Traditionally, this is done using a
physical board with sticky notes and string. After the session is over, the notes
and string are recreated in Jira for the whole team. But again, this is clunky and
means missing a lot of context, particularly around dependencies.
The best way to use Jira for PI Planning is to use an app like Easy Agile Programs
to help you run your PI Planning sessions. The integrated features mean you can:
Set up a digital Program Board (no more string and sticky

notes!)
Do cross-team planning
Visualize and manage cross-team dependencies
Get aligned on committed objectives for the Program
Increment
Visualize an Increment Feature Roadmap
Transform Jira from a team-level tool to something that’s
useful for the whole ART
Join companies like Boeing, Vodafone, and Prudential Insurance who use Jira to
do PI Planning with Easy Agile Programs (which is available from the Atlassian
Marketplace).
Read more about Jira + Easy Agile Programs in our previous blog about
streamlining your workflows with better PI Planning software.
Anything else you’d like to know about PI Planning?
That’s it! You made it! You’ve crossed the finish line! Seriously, there should be
some kind of award for people like you who actually get to the bottom of an
ultimate guide, let alone one about PI Planning 😉
We’ll come back to this guide and make it even more epic in the future. So if you
have any questions about PI Planning or you notice there’s an aspect we haven’t
covered yet, let us know over on Twitter!

Easy Agile - The Ultimate Guide To PI Planning (2020 SAFe Edition)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Easy Agile - The Ultimate Guide To PI Planning (2020 SAFe Edition)

Uploaded by

Copyright:

Available Formats

2/25/2020 Easy Agile | The Ultimate Guide to PI Planning [2020 SAFe Edition]

The Ultimate Guide to PI Planning [2020

Published 12 Dec 2019

🦸 Never fear, Easy Agile is here!

What actually is PI Planning?

What is the difference between a PI Roadmap and a

Let’s start with the basics…

What actually is PI Planning?

Here are the essential elements of PI Planning:

2 full day events run every 8-12 weeks (depending on the

Quick definition: SAFe or the Scaled Agile Framework™ is a series of guidelines

No pressure! Though seriously, if your team gets PI Planning right, it makes

So let’s dig a little bit deeper into the why…

PI Planning is incredibly beneficial for large scale agile organizations.

This is kind of a big deal because:

When you’re touching a system or a code repository, you

What is the goal of PI Planning?

PI Planning is an essential part of the Scaled Agile Framework, a framework that’s

On the flip side… without PI Planning, teams don’t have structured

What should be included in the PI Planning agenda?

Here’s a standard PI Planning agenda template suggested by the SAFe website:

Architecture vision & development practices

Planning context & lunch

Draft plan review

Management review & problem solving

Final plan review & lunch

Plan rework (if needed)

Planning retrospective & moving forward

What is accomplished in the first part of the PI Planning meeting?

🧘 Think positive thoughts

😊 I am smart, I am kind, I am important

Although it could be exciting if business discussions are your thing. 🤷🤓

Why is a confidence vote held at the end of PI Planning?

Here’s how it works…

Everyone in the room needs to vote by raising a hand (and fingers). 🤚

When is PI Planning held?

Some companies hold quarterly PI Planning, for example:

What is a pre-PI Planning event and when is it needed?

🚂 Thomas would carry the passengers

🚂 Percy would pick up the fireworks

🚂 James would bring the picnic food

…and everybody would have a very nice time.

(We’ve deliberately left Gordon out… he’s not a team player.)

Solution Train Engineer

What does SAFe have to do with PI Planning?

Hang on… what does this have to do with PI Planning?

This is increasingly important as the environment for organisations continues to

Which is where PI Planning comes in…

PI Planning is a vital element of SAFe. It’s a ceremony that brings together

SAFe and PI Planning to the rescue! 🦸🏆

Now for another definition…

What is PI Planning in Scrum?

For example, these scrum teams could:

Meet every 10 weeks and discuss the features they are

What is the difference between a PI Roadmap and a Solution Roadmap?

The current increment (work that’s committed)

So, what’s the Solution Roadmap all about?

For example, there might be 4 teams working on a NASA spaceship mission to

Launch team - Agile!

Now for one more definition…

What’s a program board?

Who should be involved in PI Planning?

🚂 Release Train Engineers