PI planning definition: PI Planning stands for Program Increment Planning. Teams using the Scaled Agile Framework® (SAFe®) schedule these two-day events every eight to 12 weeks depending on the length of their increments. These planning sessions or ceremonies give big teams a chance to coordinate and integrate the actions of smaller team units.
Project managers figure out the planned features for the increment, development teams own user story planning, and UX designers and researchers validate the planning. The goal here is to align teams both to the mission of the organization and to each other.
Before the innovation of digital tools, like Mural, allowing remote teams to collaborate around the globe, PI planning was done with everyone attending in person. Obviously, getting teams from around the world together in the same physical location for two days cost companies a great deal. Now more than ever, SAFe teams are discovering the power of tools that make it easy to do PI planning remotely.
If you’re new to using the SAFe framework, you’ll want to begin with the PI planning ceremony.
So let’s dig a bit deeper into the “why.”
Why use PI planning?
PI planning is essential for large scale organizations using Agile. Imagine an organization with 20,000 developers. These developers might be broken down into 400–600 teams. Before PI planning, it was not uncommon for teams like this never to talk to each other (unless something went drastically wrong).
In the past, any alignment on vision would have happened only from the top down. Managers of teams might have gotten together to talk about the big picture — vision, mission, values. And of course, we’re talking about multiple levels of management playing telephone, passing the information down to their teams. But the teams themselves would never coordinate.
So, PI planning is the first opportunity many teams at large organizations get to talk to one another. It’s exciting because as the Agile Manifesto states, “the most efficient and effective method of conveying information to and within a development team is a face-to-face conversation."
The business benefits of PI planning include:
Establishing communication across all team members and stakeholders
Building a social network that makes the Agile Release Train (ART) really work
Aligning development to business goals
Identifying dependencies and cultivating cross-team and cross-ART collaboration
Syncing up demand and capacity
Eliminating excessive Work in Process (WIP)
What does PI planning have to do with Scaled Agile Framework® (SAFe®)?
If you are just getting started with the Scaled Agile Framework (SAFe), you may be wondering how PI planning fits into the picture.
Basically, SAFe is a set of guidelines and workflow patterns for implementing Agile at scale. And PI planning gives you a simple framework to bring your agile teams together. You can think of it as the framework within the framework.
PI planning is a vital part of SAFe. It’s a ceremony that brings together stakeholders from every team and gives them a plan for working together to decide on top features, identify dependencies, and make a plan for the next program increment. Ideally, PI planning allows for greater visibility across teams, smoother changes, and more coordination at every level of the organization.
PI planning templates
Historically, PI planning has been done in person with whiteboards and sticky notes. These PI planning templates enable teams to plan collaboratively in real time from anywhere.
Use the PI Planning Program template to create a visual summary of the features, goals, risks, dependencies, and timelines decided upon in the program increment plan.
Whether you’re a scrum leader, an Agile coach, or simply someone who wants their team to become more agile, a trip to Agile Space will provide practical solutions to help you on all your current and future missions.
Sample PI planning agenda
Every PI planning session follows the same general agenda, though it can be adapted depending on your teams' needs. For example, if you're doing PI planning digitally with a remote or hybrid team, you might consider spreading the event over five days instead of two to accommodate different timezones.
Here’s what a standard agenda might look like.
Business context (8–9 a.m.) A leader or executive describes the current state of the business, shares their vision, and presents a perspective on how effectively current solutions are meeting customer needs.
Product/solution vision (9–10:30 a.m.) The head of product presents the current vision (e.g., top 10 upcoming new features), highlights changes from the previous PI planning event, and introduces forthcoming milestones.
Architecture vision and development practices (10:30–11:30 a.m.) The System Architect or Engineer presents the architecture vision. A senior development manager may also introduce Agile-supportive changes to development practices being advanced in the upcoming PI.
Planning context and lunch (11:30–1 p.m.) The Release Train Engineer (RTE) presents the planning process and expected outcomes.
Team breakout sessions (1–4 p.m.) Individual teams meet to estimate their capacity for each iteration and identify the backlog items they’ll need to realize the features. Each team creates draft plans visible to all stakeholders.
Draft plan review (4–5 p.m.) Teams present key planning outputs, which include capacity, draft PI objectives, potential risks, and dependencies. Other teams and stakeholders review and provide input.
Management and problem solving (5–6 p.m.) Management may negotiate scope changes and resolve any challenges by agreeing to varying planning adjustments.
Planning adjustments (8–9 a.m.) Management begins day 2 by presenting any changes to scope, people, or resources.
Team breakouts (9–11 a.m.) Teams continue planning based on the previous day’s agenda and make appropriate adjustments. They finalize their objectives and managers sign off.
Final plan review and lunch (11–1 p.m.) Teams present their plans to the group. At the end of their time slot, teams state their risks and obstacles. The team then asks managers if it’s acceptable. If there are concerns, then teams have the opportunity to adjust the plan and present the revised plan.
Program risks (1–2 p.m.) The risks identified by each team are resolved in front of the whole train. One by one, the risks are discussed and categorized.
Confidence vote (2–2:15 p.m.) Once program risks have been identified and addressed, teams vote on their confidence in their ability to meet their team PI objectives. If the team is confident, then management should accept their commitment. Anyone who doesn't feel confident has the chance to voice their concerns.
Plan rework as needed (2:15–X:XX p.m.) If necessary, teams rework their plans until they reach a high level of confidence.
Planning retrospective and moving forward (when ready) Finally, the RTE leads a brief retrospective for the PI planning event to capture what went well and what can be done better next time.
Why is a confidence vote held at the end of PI planning?
Arguably the most important part of PI planning is the confidence vote. Here’s how it works: The RTE asks, “will we meet our objectives?” Then everyone in the room votes by raising a hand showing a number of fingers expressing their level of confidence (5 fingers = very confident, 1 finger = not confident). If the average is three fingers or higher, then the plan is good to go. If it’s less than three, the plan needs to be reworked. Anyone who votes with just one or two fingers, has the chance to voice their concerns.
No items found.
Who should be involved in PI planning?
There are five critical roles involved in PI planning:
Release train engineers (RTE)
Scrum leaders (aka scrum masters)
Let’s look at the responsibilities of each.
The release train engineer (RTE) is a leader and coach for the ART. Their role is about planning and facilitating the PI planning event.
Establishes and communicates the annual calendar
Gets everything ready, including for pre- and post-PI planning meetings
Manages risks and dependencies
Creates Program PI objectives from team PI objectives and shares them with all the stakeholders
Ensures strategic and execution alignment
Facilitates system demos
The RTE is also the facilitator of the two-day event. In this role, they present the planning process and expected outcomes. They also run the management and problem solving session, as well as the retrospective at the end.
The product manager presents the program vision and any upcoming milestones. They review the draft plan and explain any changes to the planning and scope based on the management and problem solving session. This allows the project manager to manage and prioritize the workflow. Once the PI planning event is over, managers use the program objectives to update the roadmap. Project managers are also involved in pre- and post-PI planning meetings.
The product owner is responsible for maintaining and prioritizing the team backlog as well as iteration planning. They also have content authority to make decisions at the user story level during PI planning team breakout sessions. Product owners help teams define stories, estimate and sequence workflows, as well as draft team PI objectives. Finally, they’re responsible for conveying the vision and goals from upper management to the team.
The scrum leader (aka scrum master)helps the product owner by managing and leading processes as well as being a liaison between the product owner and the development team. They facilitate preparation for events and help to prepare system demos. The scrum master also helps teams estimate their capacity and finalize their team PI objectives, as well as manage deadlines, dependencies, and ambiguities during team breakout sessions.
Developers research, design, implement, test, maintain, and manage software systems. During PI planning, they participate in breakout sessions to build and refine user stories and acceptance criteria. They also help with plan adjustments, identify risks and dependencies, and support the team in drafting team PI objectives.
Now that you understand all the pieces of the PI planning event and who’s involved, let’s see what you have to do to prepare your team before the event.
No items found.
What should we do to prepare for PI planning?
Every PI planning event requires strong preparation to make sure your teams get the most out of the event and meet their objectives afterwards. So what does preparation look like?
All stakeholders must prepare by assigning key roles, ensuring they as a team are aligned on strategy, and making sure everyone understands the planning process. Presenters will need to do the most to prepare getting their content ready for prime time.
In addition, you’ll likely have hundreds of participants, so you’ll need to ensure the proper event planning happens. If your teams are meeting in person, you’ll need to prepare the facility. If you’re doing PI planning virtually, you’ll need to treat this like the virtual event that it is. Focus on technology (including audio, video, and internet connectivity) to make sure all remote teams can participate.
Also, to make this work seamlessly for your organization, you may need to customize PI planning templates that support your needs. Consider the comfort needs of your teams too. The best planning happens when everyone is well fed and hydrated.
Having a clear picture of what needs to be done before and during this event, let’s turn to what happens afterward.
No items found.
What happens after PI planning is done?
Your PI retrospective will include discussing what went well and what could have gone better. Then there should be a discussion about next steps. Next steps will include plans for moving team plans and objectives forward, coordinating calendars, and setting daily standups and iteration meetings.
Also, there will be post-PI planning events, which bring together stakeholders across all Agile Release Trains within the solution train to ensure everything is synchronized. Post-PI planning happens after all teams have completed their planning for the next increment. Teams present plans, explain objectives, and share milestones and expected timelines.
Post-PI planning happens among teams and instead of looking at features, these ceremonies outline capabilities, dependencies, and milestones for each iteration and ART. Potential risks are identified, discussed, and owned, resolved, accepted, or mitigated. Similar to regular PI planning events, post- PI plans go through a vote of confidence.
No items found.
Digital PI planning for hybrid teams
As remote work becomes part of our everyday working lives, virtual events like SAFe PI planning will become the norm. Your organization needs to be ready for this shift with digital tools that support your vision and goals.