problem solving meeting pi planning

Agile workflow

The Ultimate Guide to PI Planning

You may be just starting out, or you may have worked with agile methodologies for a while, but we’re sure you can agree that scaling agile in a large organization can be daunting. PI Planning is key to scaling agile, so we’ve developed this guide to help you run successful planning sessions, and build your confidence for your next scaled planning event. We'll cover:

What is PI Planning?

Why do pi planning, what is the goal of pi planning, what should be included in the pi planning agenda, what happens 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, pi planning in safe, pi planning in scrum, what is the difference between a pi roadmap and a solution roadmap, what is a program, what is a program board.

• Who should be involved in PI Planning?

How to prepare for PI Planning

What happens after pi planning, what is a post-pi planning event, remote or hybrid pi planning, common pi planning mistakes, using jira for pi planning.

Let’s start with the basics…

PI Planning stands for Program Increment Planning.

PI Planning sessions are regularly scheduled events where teams within the same Agile Release Train (ART) meet to align and agree on what comes next. Teams will aim to align on goals and priorities, discuss features, plan the roadmap, and identify cross-team dependencies.

The goal is to align the teams to the mission and each other. 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

PI Planning is incredibly beneficial for large-scale agile organizations. PI Planning enables:

• Communication
• Collaboration

To understand the impact, let’s look at an example of a large organization that hasn’t yet implemented PI Planning. This organization has 250 teams and 6,500 team members. These teams rarely speak to each other, outside of dealing with a critical issue that has forced them to collaborate.

Alignment across these teams happens at the leadership team level, and they have multiple levels of managers in between who cascade information down with varying success. There is a constant battle for resources, budget, and opportunities to work on the most exciting projects.

Their projects have 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 big companies get their teams together in a room or on the same call to talk to each other. This is a chance to have important conversations about who is working on what.

Why is this important?

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

With proper planning and collaboration, teams can get things done more effectively, release with more predictability, and stay on budget.

All very good reasons to do 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.

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 realizing there’s a dependency, which could hold up the release or require a significant rework of the code.

The goal of PI Planning is to have 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.

Here’s a standard PI Planning agenda template:

Source: scaledagileframework.com/pi-planning

This agenda might be perfect for you, or you might make changes based on the needs of your teams.

Distributed teams, very large ARTs, and other factors might require you to be creative with the schedule. Some sessions may need more time, while others can be shortened. If you have teams in multiple time zones, your PI Planning agenda may need to go over 3-4 days. If it’s your first PI Planning event, try the standard agenda, get feedback from your teams, and experiment with different formats next time.

The first part of the PI Planning meeting is designed to set the context for the planning that happen next.

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, the Product Management team will 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). They’ll describe what’s coming up, including milestones and the next 10 features that are planned. This session should take around 1.5 hours.

The confidence vote is a seemingly small but very important part of PI Planning towards the end of the event.

It is important the team is confident in committing to the objectives and work that is planned. The Release Train Engineer will ask teams to vote on this.

Everyone participating in planning needs to vote. This could be via a raise of hands (and fingers) or it could be via the tool you’re using. For example, the Team Planning board in Easy Agile Programs allows each team member to enter their confidence vote .

If the average vote across the room is at least three out of five, the plan is a go-ahead. If it’s less it’ll need reworking (until it reaches a high confidence level). If anyone votes just one or two, they’ll have the chance to share their reasoning.

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 possible within the given timeframe. Speaking of timing, let’s talk about how and where PI Planning actually fits into your company calendar.

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

However, the timing and frequency will depend on how long each program increment is scheduled to last and may need to accommodate holidays.

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.

This means that what happens in preparation for PI Planning can be just as important as the event itself.

A pre-planning event - separate to PI Planning - is to make sure that the ART is aligned within the broader Solution Train before they do PI Planning. It’s all about synchronizing with the other ARTs to ensure the solution and organization are heading in the right direction, together.

You’ll need to organize 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 so formally.

Here are a few of the roles that should be invited to the pre-planning event:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Product Management
• System Architects/Engineers

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:

• Solution backlogs
• Upcoming PI features from the Program Backlog

In the next section, we'll help to define a few key terms that have been touched on.

If you’re adopting SAFe for the first time, chances are it will start with PI Planning. That’s because it forms the foundation of the Scaled Agile Framework.

As Scaled Agile says, "if you are not doing it, you are not doing SAFe."

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.

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. SAFe helps to scale agility across teams; to have multiple teams come together to work on the same products, objectives, and outcomes. It goes beyond the team level to include every stakeholder, outlining what should happen at each level of the organization to ensure that scaled planning is successful.

The purpose of SAFe is to improve the visibility of work and alignment across teams, which will lead to more predictable business results.

This is increasingly important for organizations as they respond to changing circumstances and customer expectations. The traditional waterfall approaches fall short because they’re slow and inefficient.

Bigger 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, making it more complex to launch a new feature and deliver new value to customers.

These companies are looking for new ways to organize people into projects and introduce more effective ways of working that use resources more effectively and provide more predictable delivery. If they don’t, they may not survive.

SAFe is a way for these companies to start moving in a more agile direction.

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 are powerful enablers for organizational agility.

While SAFe is a framework designed for larger organizations, there isn't a reason stopping smaller companies from doing a version of PI Planning, too. All you need is more than one agile team to make it worthwhile.

You can also use PI Planning as part of a simple Scrum approach.

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.

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 and context.

There are different types of roadmaps in SAFe, so it’s important to understand the differences and what each roadmap is meant to do.

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

Quarterly PI Planning will outline around 9 months of work. The second and third increments 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.

Solution Roadmap

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.

A program is where agile teams are grouped together to form a larger group. This is often referred to as the “team-of-teams” level. In simple terms, a program is a group of agile teams.

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
• Oxygen team (Agile)
• Landing team

After a few months, NASA decides that the way the oxygen team is working is going well, so the remaining three teams similarly adopt more agile methodologies:

• Launch team (Agile)
• Food team (Agile)
• Landing team (Agile)

Each of these 4 teams are self-organizing, 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.

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

Program Boards are a key output of 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.

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.

Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.

Easy Agile Programs

Who is involved in PI Planning?

There are 5 key roles in a PI Planning event:

• Product Managers
• Product Owners
• Scrum Masters

Here are the responsibilities for each of these roles during PI Planning:

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.

Before PI Planning happens, Product Managers take part in the pre-PI Planning meeting, where they discuss and define inputs, objectives, and milestones for their next PI Planning events.

In PI Planning, the Product Managers present the Program vision and upcoming milestones. So that they can manage and prioritize the flow of work, they review the Draft plan and describe any changes to the planning and scope based on the Management Review & Problem Solving session. Once the PI Planning event is over, they use the Program Objectives from the Release Train Engineer to update the roadmap.

Following PI Planning, Product Managers play a critical role in communicating findings and creating Solution PI Objectives.

Product Owner

The Product Owners are responsible for maintaining and prioritizing 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, finalize 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.

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 to identify risks and dependencies and to support the team in drafting and finalizing Team PI Objectives, before participating in the Team Confidence Vote.

Do you have a key role in PI Planning? See how the right tool can help you manage your release train or program better.

If you want to succeed at PI Planning, you need to prepare.

Every PI Planning event relies on good preparation so that your organization and attendees get the most out of the event and achieve your planning objectives.

The first step is to ensure that everyone involved properly understands the planning process. All people participating in PI Planning (along with key stakeholders and Business Owners) must be clear on their role and aligned on strategy.

Any presenters will also need to get content ready for their presentations.

To ensure that the PI Planning event runs smoothly, make sure that the tools you need to facilitate planning are available and working properly. Be sure to test any tech that you are relying on ahead of time (including audio, video, internet connectivity, and access to PI Planning applications), to ensure that your distributed teams can participate in the PI Planning event. Don’t forget to plan for enough food for everyone, too (planning is hungry work).

After PI Planning, teams do a planning retrospective to discuss:

• What went well
• What went not-so-well
• What could be better for next time
• There will also be a discussion of what happens next, which can include things like:
• Transcribing the objectives, user stories, and program board into your work management tool (like Jira)
• Agreeing on 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.

These are similar to the pre-PI Planning events we looked at earlier. A post-PI Planning event brings together stakeholders from all ARTs within the Solution Train to ensure they’re synchronized and aligned.

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 confidence vote to ensure they meet the solution’s objectives, and are reworked until the attendees average a vote of 3 or more.

PI Planning in person was once standard, but with teams more likely to be distributed, gathering everyone at the office isn't always feasible. This doesn't have to be a barrier.

The most important principle is to ensure that the teams who are doing the work are able to be 'present' in the planning in real-time, if not in person.

This may require some adjustments to the agenda and timing of your planning, but with forethought and support from the right technology, your PI Planning will still be effective.

Tips for remote PI Planning

Remote PI Planning is ideal for organizations with distributed teams or flexible work arrangements. It’s also a lot cheaper and less disruptive than flying folks in to do PI Planning every few months. If you have the right tools and technology, you can run PI Planning and allow everyone to participate, whether they’re in the same room or on the other side of the world.

Here are a few tips for remote PI Planning:

Embrace the cloud

Use online shared planning tools to allow your team to access and interact with information as soon as possible - ideally in real-time. Ensuring that all participants have instant access to the information simplifies the process of identifying dependencies and maintaining a centralized point of reference for your planning. This helps prevent errors that arise from working with different versions and transferring data between sources.

Livestream the event

Live-streaming audio and video from the PI Planning event is a viable alternative to in-person planning. Actively encourage your remote team members to use their cameras and microphones during the event. While it may not fully replicate the experience of having them physically present, it does come remarkably close.

Record the PI Planning event

Ideally, everyone will participate in the PI Planning live. But if your teams are distributed across multiple time zones or some team members are ill, it’s a good idea to record the event. Having a recording to refer back to could also be useful for attendees who want a refresher on anything that has been discussed.

Be ready to adapt

Some teams will change the standard PI Planning agenda to fit multiple time zones, which could mean starting the event earlier or later for some, or even running it across 3 days instead of 2.

Set expectations

A common issue that can arise from having distributed teams tune in remotely 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 blog on how to prepare for distributed PI Planning .

Whether distributed or in person, if your team gets PI Planning right, it makes everything in the upcoming increment so much easier.

📣 Hear how PNI media have embraced virtual PI planning

PI Planning doesn’t always run smoothly, especially the first time. And the framework itself may present a challenge to some organizations. Here are some common mistakes and challenges to keep in mind (and avoid):

Long, boring sessions

Avoid starting your PI Planning event with long sessions filled with dense content. Think of creative ways to make these sessions more engaging, or break them into shorter sessions. Consider different formats that help to involve and engage participants. And be sure to make room for team planning and collaboration.

Tech issues

Any event is vulnerable to technical mishaps, but if you’re streaming audio and video to a distributed team, this can really impact the flow of the event. It’s a good idea to carefully test all the equipment and connections ahead of time to minimize potential problems.

Confidence vote

Some PI Planning participants struggle with the confidence vote concept. People may feel pressure from the room to vote for a plan to go ahead, rather than speaking up about their concerns. Failing to address issues early only increases the risk of something going wrong during the increment.

Time constraints

When you have a large ART of 10 or more teams, there are a lot of draft plans to present and review, so less time is allocated to each team. Chances are that the feedback will be of poorer quality than a smaller ART with 8 teams.

Not committing to the process

PI Planning isn’t perfect and neither is SAFe. However, the process has been proven to work for many organizations, when the organization is committed. Start with the full framework as recommended; you can adapt the framework and your PI Planning event to suit your organization, but be sure to commit to the process that follows. Anything that is half-done will not deliver full results.

Sticking with the same old tools

If something is 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 incorrect, or you have 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 .

Jira is the most popular project management tool for agile teams, so chances are you're already using it at the team level.

When you need to scale team agility as part of an ART, it can be difficult to properly visualize the work of multiple teams in Jira. The only way you can do that in the native app is by creating a multi-project board, which is rather clunky.

Traditional PI Planning on a physical board using sticky notes and string may achieve planning objectives for co-located teams, but what happens next? After the session is over, the notes and string need to be recreated in Jira for the whole team so that work can be tracked throughout the increment. This is a cumbersome and time-consuming process that is open to error as sticky notes are transcribed incorrectly, or go missing.

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, create milestones
• Identify scheduling conflicts to mitigate risks
• Get aligned on committed objectives for the Program Increment
• Visualize an Increment Feature Roadmap
• Conduct confidence voting
• Transform Jira from a team-level tool to something that’s useful for the whole ART

Join companies like Bell, Cisco, and Deutsche Bahn who use Jira to do PI Planning with Easy Agile Programs (from the Atlassian Marketplace).

We’ll continue to revisit this guide in the future. If you have any questions about PI Planning or you notice there’s an aspect we haven’t covered yet, send us an email 📫

A straightforward guide to building smart PI objectives

6 Tips for Setting Up Distributed PI Planning

Improving Remote PI Planning with Easy Agile Programs

Subscribe to our blog.

Keep up with the latest tips and updates.

The Complete PI Planning Guide for Remote Teams

Start collaborating with Mural today

What is pi planning.

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.

If you’re new to using the SAFe framework, you’ll want to begin with the PI Planning ceremony.

Why is PI planning important?

PI planning is essential for large scale organizations using Agile . Imagine an organization with a few thousand developers. These developers might be broken down into smaller 400 to 600-person teams. Before PI planning, it was not uncommon for teams like this never to talk to each other (unless something went drastically wrong), leading to severe organizational silos . 

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

Benefits of PI planning

• 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)
• Fast decision-making

PI Planning and the 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.

What stakeholders are involved in PI planning?

There are five critical roles involved in PI planning:

• Release train engineers (RTE)
• Product managers
• Product owners
• 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
• Tracks progress
• 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.

Before the planning session: how to prepare

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 look at an example agenda and then turn to what happens afterward.

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

After the PI planning session

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.

Is it better to do PI planning in-person, hybrid, or remote?

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.

Imagine a team of about 300 PI planners (engineers, scrum masters, release train engineers, Agile coaches, leadership, etc.) from a large Fortune 500 company team. Every quarter, hundreds of international colleagues are flown to one location in the United States and grouped into about 25 teams. Each team has a scrum master and their own PI planning board. The scrum master leads the team to discuss the priorities for the quarter (or given timeframe), the effort required to achieve objectives and any dependencies between working groups, using their planning board as a visual.

That’s quite a large investment in travel, plus a lot of pressure for scrum masters and their participating PI planners to make the most out of the few days they have together. Is this really the best way to maximize results?

The team in this story realized no, it wasn’t the best way. They sought out MURAL's digital workspace to help them create a digital source of truth for their PI planning boards, and then moved over to a fully remote PI Planning methodology.

They designed a pilot program and partnered with MURAL on custom PI Planning templates and facilitator training. The team then flew all colleagues to one location, one last time, for a stress test.

Scrum masters were asked to be each team's canvas scribe on a 55-inch monitor while the important session was underway, and the teams completed their PI planning directly in Mural while speaking face to face. MURAL experts were on-hand for product and technical coaching, but it wasn’t needed. The transition was seamless and the hybrid session was a success, leading this customer to complete every subsequent quarterly PI planning remotely in MURAL, saving them upwards of $60,000 per quarter.

There are many other teams like this one paving their way to 21st century Agile work using MURAL. Read on for more of our tips and learnings.👇

How to perform PI planning in Mural

Pi planning program board.

‍ Create a visual summary of the goals, features, risks, dependencies, and timelines defined in the program increment plan.

PI Planning Team Board

Estimate the capacity of each team to accomplish the tasks in each iteration. You'll need one per team who participate in the planning.

Paste from (and to) spreadsheets

Turn planning into trackable jira tickets, how to get jira content into mural.

Use the PI Planning Templates above for this exercise, or create your own. To get Jira content into MURAL, each cell from a Jira export can be copied to a canvas as an individual sticky.

Getting started

Copy all cells that include feature or story descriptions. Return to your MURAL canvas, and use Cmd (or Ctrl)+V to paste them. They will render as 3x3 stickies. Note that if you are pasting 150+ characters of text, cells will render as text boxes instead of stickies.

Matching legend formatting

Multi select all of these new stickies. Using the 'Switch Type' option in your formatting toolbar (second to last icon), convert the stickies to 3x5. From the formatting toolbar you may also change the sticky note color.

Adding feature #, story #, and size

Using the Alt key+clicking and dragging, duplicate the appropriate sticky note header from the Legend. (You may also use Cmd+D, or simple Copy/Paste.) Group the text box to the existing sticky note using Cmd (or Ctrl)+G, and include as much existing information as you can. Decrease the font size as needed to keep the header one line.

To get MURAL stickies into Jira, each sticky or text box from a Mural canvas can be copied to a spreadsheet as a cell.  Before you start, determine what upload spreadsheet format you will need to use with Jira.

Copying stickies

Multi-select a group of sticky notes. Right click on them, & select 'copy as text'.

Completing your final data sort

Return to your spreadsheet. Use cmd (or ctrl) + V to paste your stickies. Click and drag each respective cell (description and it's header), dragging it to its appropriate position in the upload spreadsheet.

Separating feature #, story #, and size into separate cells

Select the column of data that includes sticky note header content (ex. "Feat. #34891 , Story #, Size 5"). Click your spreadsheet program's data menu. Select "Split Text to Columns", and use comma as the delimiter. This will result in 3 cells, "Feat. #34891" "Story #" "Size 5".

Related blog posts

Remote PI planning: set your team up for success — webinar recap

How to run efficient Agile meetings [+ templates]

6 tips to make daily stand-ups more effective

Related blog posts.

Visual collaboration: What it is & how to get started

What is the difference between traditional project management and Agile?

13 best online collaboration tools to try in 2024

The Ultimate Guide to PI Planning

#projectmanagement, table of content, what is pi planning, why do pi planning, what is the goal of pi planning, what to include in a pi planning agenda.

• When is PI Planning held?
• What are the inputs and outputs of PI planning?

Benefits of PI Planning

Example pi planning agenda.

Prioritizing and adhering to Agile principles while scaling is paramount for the success of any organization. The journey from a small entity to achieving scale often involves the collaboration of geographically and functionally dispersed teams whose work is intricately interdependent.

Recognizing and strategically planning for these interdependencies is crucial to ensure that each team’s efforts are harmoniously directed toward a singular, project-focused goal.

The implementation of Program Increment (PI) planning significantly facilitates the attainment of this goal. But what precisely is PI planning, and why does it hold such significance?

PI Planning, an abbreviation for Program Increment Planning, constitutes a vital practice within the Scaled Agile Framework® (SAFe®). These structured events occur every eight to 12 weeks, with the frequency dependent on the duration of the increments. During these planning sessions or ceremonies, large agile teams often seize the opportunity to coordinate and integrate the efforts of smaller team units.

The responsibilities within PI Planning are distributed across different teams agree various roles. Project managers strategize the planned features for the increment, while development teams take ownership of user story planning. Simultaneously, UX designers and researchers contribute to validating the planning. The overarching objective is to align teams not only with the organization’s mission but also with each other.

For those new to the SAFe framework, initiating the journey with the PI Planning ceremony is a foundational step. The framework is specifically designed to enhance visibility, alignment, and collaboration among teams, ultimately leading to heightened productivity, superior results, and accelerated delivery.

Whether an organization adopts all five levels of SAFe or focuses on essential aspects, the cornerstone of the transformation lies in the PI Planning ceremony. This ceremony serves as the linchpin, steering the entire process towards improved efficiency and successful implementation.

PI Planning holds paramount significance for large-scale organizations employing Agile methodologies. Imagine an organization with several thousand developers organized into more manageable units of 400 to 600 individuals per team.

Prior to the implementation of PI planning, it was not uncommon for these distributed teams to operate in relative isolation, seldom engaging in communication unless prompted by significant issues. This isolation often led to the formation of severe organizational silos.

Historically, the alignment of vision within remote teams of such organizations primarily occurred through a top-down approach. Managers of various teams would convene to discuss overarching concepts such as vision, mission, and values.

However, this process involved multiple levels of management, resembling a game of telephone, with information cascading down through hierarchical layers to reach individual teams. Consequently, direct coordination among all the teams themselves was a rarity.

PI Planning constitutes an indispensable component of the Scaled Agile Framework (SAFe), a framework meticulously crafted to introduce agile methodologies to large companies with multiple teams.

Within the SAFe context, PI Planning plays a pivotal role in facilitating synchronization, collaboration, and alignment among teams forming the Agile Release Train (ART). This alignment encompasses various aspects, including workflows, objectives, releases, and more.

Conversely, the absence of PI Planning leaves teams without a structured communication framework. This lack of coordination can lead to significant challenges, such as teams unknowingly working on disparate features, potentially resulting in dependencies that might impede the release or necessitate extensive code rework.

The overarching objective of PI Planning is to strategically align all teams and foster cross-team collaboration, thereby preempting potential issues. Having established the rationale behind PI Planning, let’s delve deeper into its operational aspects by examining a comprehensive sprint planning agenda.

Adhering to these three fundamental steps for effective program increment planning is crucial to harness the full potential of the Agile project methodology.

1. Organizational Readiness

• Ensure key stakeholders are available for the program increment planning session.
• Schedule timely PI planning meetings and send reminders to participating teams.
• Consider conducting the PI planning session before the quarter commences to allow teams to set up and prepare for upcoming activities.

2. Content Preparedness

• Clearly communicate the mission, vision, and purpose of the program.
• Emphasize the significance of each activity by articulating the “why” behind the scaled Agile program increment planning sessions.
• Ensure that the rationale for the sessions is well understood by all relevant team members.

3. Logistics Preparation and Accessibility

• Facilitate optimal engagement during PI planning sessions, whether conducted offline or virtually.
• Arrange for a spacious room or a virtual platform, such as a team Zoom call, to accommodate the required number of attendees.
• Utilize Zoom breakout rooms to foster collaboration among teams in smaller groups, addressing specific action items.

Understanding the Connection between SAFe and PI Planning Event

• Program Increment Planning, structured as either a face-to-face or virtual event, plays a pivotal role in aligning Agile Release Train (ART) teams toward shared goals.
• As a team expands, maintaining adherence to core Agile principles can pose challenges, making PI planning in ART crucial for Scaled Agile Framework (SAFe) implementation.
• SAFe, encompassing Agile methodologies, lean principles, and systems thinking, provides a foundational knowledge base. While not offering ready-made solutions for unique organizational challenges, SAFe equips teams with proven best practices to enhance project deliverable quality, increase team productivity, and foster employee engagement.

When is PI Planning Held?

– optimal duration.

Companies often find that a program increment lasting 8-12 weeks is effective. This duration corresponds to 4-6 iterations, each lasting 2 weeks.

– Variability in scheduling

The timing and frequency of PI Planning sessions vary among organizations based on their specific needs and project timelines.

– Quarterly Schedule Example

Some organizations adopt a quarterly schedule for regular PI Planning events to provide a structured framework.For instance, Q1 PI Planning might occur in December, followed by Q2 PI Planning in March, Q3 PI Planning in June, and Q4 PI Planning in September.

– Consideration for Holidays

When scheduling PI Planning sessions, it’s essential to consider holidays and potential disruptions. This ensures that teams can fully engage in the planning process without significant interruptions.

– Advantages of Regular Occurrence

Fixed and regular scheduling of PI Planning sessions offers several advantages. Teams and business owners can plan well in advance, allowing for better preparation and participation.

– Structured Approach to Planning Process

The regular occurrence of PI Planning enables a structured and well-coordinated approach to project planning and execution. Teams can align their efforts with organizational goals and synchronize their activities.

– Preparation Significance

The preparation leading up to previous PI Planning event is as crucial as the event itself. Proactive planning ensures organizational readiness and logistical readiness for the planning session.

– Proactive Approach

Organizations benefit from a proactive approach to PI Planning, addressing considerations well in advance. This approach contributes to the smooth execution of planning sessions and subsequent project activities.

– Stakeholder Involvement

Consistent scheduling ensures the active participation of the team presents all relevant stakeholders. Stakeholders, including team members and business owners, can allocate time and resources effectively.

– Alignment with Agile Principles

The regularity of PI Planning aligns with Agile principles, fostering collaboration, iterative development, and effective execution. It ensures that Agile teams stay true to the core principles even as the organizational scales.

By adhering to a well-defined schedule and prioritizing thorough preparation, organizations set the foundation for successful PI Planning sessions, promoting collaboration and adherence to Agile principles.

Seamlessly Manage Time Off in Lieu and Boost Productivity.

Get started

What are the Inputs and Outputs of PI planning?

Inputs for successful pi planning, – overall company vision and goals.

A foundation for PI planning success lies in a comprehensive understanding of the overall company vision and goals. A clear business context, defined mission, actionable roadmap, and prioritized backlogs contribute to effective PI planning.

– Mapping Goals to Business Needs

Goals become meaningful when aligned with tangible business needs and end-user requirements. Ensure a mapping of company goals to actual business needs, providing a roadmap for teams during PI planning.

Outputs of a Successful PI Planning Event

– committed pi objectives and tasks.

Each team, irrespective of its size, defines clear and well-defined objectives and associated tasks during PI planning. The commitment made by teams serves as a basis for a management review by business owners to identify risks and assign appropriate business value.

– Crystallized Features, Milestones, and Delivery Dates

Successful PI planning results in a crystallized set of features, milestones, and precisely defined delivery dates. Program boards are used to identify potential risks and interdependencies among teams, ensuring explicit timelines for feature delivery.

By establishing these inputs and outputs, organizations can streamline the PI planning process, fostering clarity, commitment, and effective collaboration among teams. This structured approach contributes to achieving organizational outcomes more efficiently.

Detailed Aspects for Successful PI Planning

• Establishing Communication Across All Team Members and Stakeholders

Facilitating open and transparent communication channels is crucial for effective PI planning. Ensuring that all team members and stakeholders have a platform to express ideas, concerns, and updates fosters a collaborative environment.

• Building a Social Network that Makes the Agile Release Train (ART) Really Work

Cultivating a social network within all the team members of Agile Release Train (ART) enhances team cohesion and cooperation. Encouraging social interactions and team-building activities contributes to a positive and productive ART environment.

• Aligning Development to Business Goals

The heart of PI planning lies in aligning the development team and efforts with overarching business goals. Teams need a clear understanding of how their work contributes to the broader business objectives, ensuring a unified direction.

• Identifying Dependencies and Cultivating Cross-Team and Cross-ART Collaboration

Recognizing dependencies between teams and ARTs is essential for streamlined planning. Cultivating collaboration across teams and ARTs promotes knowledge sharing, review and problem solving re-solving, and a collective commitment to success.

• Syncing Up Demand and Capacity

Balancing demand and capacity is a key element in PI planning. Ensuring that teams have a realistic assessment of their capacity and aligning it with the demand for work prevents overcommitment and fosters achievable goals.

• Eliminating Excessive Work in Process (WIP)

Striving for efficiency involves minimizing Work in Process (WIP) to maintain a steady workflow. Reducing WIP helps teams focus on high-priority tasks, leading to better productivity and successful PI outcomes.

• Fast Decision-Making in Agile Teams

PI planning requires swift decision-making to adapt to changing circumstances. Establishing mechanisms for quick decision-making ensures that the planning process remains agile and responsive to evolving needs.

Organizations can create a robust foundation for agile PI planning by addressing these detailed aspects, promoting collaboration, goal alignment, and streamlined workflows across Agile Release Trains and teams.

Every PI planning session adheres to a consistent agenda, allowing for adaptation based on team-specific requirements. The standard agenda itself can be modified, for instance, when conducting digital PI planning with remote teams or hybrid teams, necessitating potential adjustments in duration to accommodate diverse time zones.

Business Context (8–9 a.m.)

A leader or executive provides an overview of the current business state, articulates the business owner’ vision, and evaluates the efficacy of existing solutions in meeting customer needs.

Product/Solution Vision (9–10:30 a.m.)

The head of product presents the current vision, highlighting upcoming features, addressing changes from the previous PI planning, and introducing imminent milestones.

Architecture Vision and Development Practices (10:30–11:30 a.m.)

The System Architect or Engineer outlines the architecture vision, potentially introducing Agile-supportive changes to development practices in the upcoming PI.

Planning Context and Lunch (11:30–1 p.m.)

The Release Train Engineer (RTE) delineates the planning process and expected outcomes.

Team Breakout Sessions (1–4 p.m.)

Individual teams estimate their iteration capacity, identify backlog items for feature realization, and create draft plans visible to stakeholders.

Draft Plan Review (4–5 p.m.)

Teams present key planning outputs, including capacity, draft PI objectives, risks, and dependencies. Stakeholders review and provide input.

Management and Problem Solving (5–6 p.m.)

Negotiation, management review and problem of scope changes and resolution of challenges occur as management addresses planning adjustments.

Planning Adjustments (8–9 a.m.)

Management presents any changes to scope, people, or resources.

Team Breakouts (9–11 a.m.)

Teams refine planning, make necessary adjustments, and finalize objectives with managerial approval.

Final Plan Review and Lunch (11–1 p.m.)

Teams present plans to senior development manager, outlining risks and obstacles. Teams seek managerial approval, with opportunities for plan adjustments if concerns arise.

Program Risks (1–2 p.m.)

Teams collectively address identified risks, discussing and even program risks and categorizing them.

Confidence Vote (2–2:15 p.m.)

Teams and teams vote mostly on confidence in meeting their objectives. Concerns are addressed, and other teams also voice their confidence levels.

Plan Rework as Needed (2:15–X:XX p.m.)

Teams rework plans until achieving a high level of confidence.

Planning Retrospective and Moving Forward (When Ready)

The RTE leads a brief retrospective, capturing insights into what went well and areas for improvement in future PI planning events.

Bottom line

In conclusion, Time Off in Lieu (TOIL) is a valuable strategy that benefits employers and employees. TOIL balances addressing business needs and recognizing employees’ efforts by incentivizing additional work without incurring extra costs.

However, its successful implementation relies on a well-crafted policy that delineates responsibilities, ensures clarity in accrue toil and usage, and fosters equitable application. HR’s pivotal role in communicating, maintaining consistency, and nurturing understanding among employees is integral to the effectiveness of the TOIL policy.

Being a digital marketer, I have been working with different clients and following strict deadlines. For me, learning the skill of time management and tracking was crucial for juggling between tasks and completing them. So, writing about time management and monitoring helps me add my flavor to the knowledge pool. I also learned a few things, which I am excited to share with all of you.

Time Tracking

• Absence Management Software
• Clock In System
• Time Attendance System
• Auto Scheduling
• Duty Roster
• Shift Planning
• Appointment Planning
• Task Planning
• Integrations
• Info Center
• Timesheet Templates
• Download Apps
• Rota Templates
• Promotional Program
• Affiliate Program
• Success Stories

Ask a question

Start a discussion.

• Atlassian logo Jira Product Discovery
• Jira Service Desk Jira Service Management
• Confluence Confluence
• Trello Trello
• Atlassian logo Atlassian Guard

Community resources

• Announcements
• Documentation and support

Atlassian Community Events

• Atlassian University
• groups-icon Welcome Center
• groups-icon Featured Groups
• groups-icon Product Groups
• groups-icon Regional Groups
• groups-icon Industry Groups
• groups-icon Community Groups
• Learning Paths
• Certifications
• Courses by Product
• Live learning
• Local meet ups
• Community led conferences

Get product advice from experts

Join a community group

Advance your career with learning paths

Earn badges and rewards

Connect and share ideas at events

Tips for facilitating a virtual management review and problem solving meeting during pi planning.

Was this helpful?

Sam Tsubota

About this author

Senior Product Manager, Enterprise Strategy & Planning

Los Angeles, CA

30 accepted answers

144 total posts

• +24 more...
• best-practice
• pi-planning
• scaled-agile
• Community Guidelines
• Privacy policy
• Notice at Collection
• Terms of use
• © 2024 Atlassian

Table of Contents

What is PI planning?

Let's define pi planning.

Program increment (PI) planning is an event that creates a shared vision among Agile teams. Throughout the event, business stakeholders, project owners, and project teams review their program backlog. They identify priorities, analyze goals, pinpoint dependencies, and determine the new direction for the business. Organizations typically carry out these meetings every 8–12 weeks. They’re usually spread over 1–2 days (although virtual sessions tend to be shorter). This allows teams plenty of time to host breakout sessions, collaborate, and discuss the new plan of action. But where does Agile come into this, and what is a PI planning event in Agile ? In the Agile framework, PI planning allows teams to create an Agile Release Train (ART). An ART brings teams together to help them make informed decisions about the future of product development.

What is SAFe PI planning?

The Scaled Agile Framework (SAFe) is a structure for implementing Agile practices. It helps teams come together to review the same products, outcomes, and key objectives at an enterprise scale. The SAFe program board is an important part of Agile PI planning. In fact, it’s the key deliverable of a PI session (more on this later). A SAFe program board maps delivery dates, dependencies, milestones, and timelines.

What is the goal of a PI planning event?

There are many benefits to running a PI planning session with your team. The main goals of a PI planning event is to:

1. Align Agile teams

Cross-functional collaboration is tricky, especially for distributed and remote teams. Everyone is on the same page  with a PI planning event — no matter what department they’re from.

2. Set clear goals

PI planning outlines your company goals and objectives. Every participant knows what the end goal is, why it’s important, and how to achieve it.

3. Build trust

PI planning is a collaborative process. It’s a great way for Agile teams to build relationships and develop trust with other team members.

4. Offer a better customer experience

PI planning allows you to streamline your processes and ensure that your teams are aligned across the business. As a result, your customers get a smoother, more efficient, and an overall better experience.

5. Make quick decisions

Decision-making isn’t easy for large, cross-functional teams. Use a PI planning event to bring teams together to make fast and informed decisions.

6. Prioritize tasks

Use a PI planning session to pinpoint the most important areas of your work and focus on action items that will help you achieve your objectives.

Who should be involved in PI planning?

The following team members form a PI planning event:

Release train engineer

The release train engineer (RTE) is the leader and coach of the Agile Release Train (ART). They form the head of the PI planning board. Their role is to plan, manage, and facilitate the PI planning event.

Scrum master

The scrum master in PI planning manages and leads processes during the event and facilitates preparation with the RTE. They also review team capacity, making sure the team can complete the work required to meet the goals and objectives. The scrum master is responsible for the timebox, identifying dependencies, and addressing any ambiguities during the breakout sessions.

Product manager

The product manager is responsible for presenting the program vision and any upcoming milestones. They review the draft plan to ensure they can effectively manage the flow of work. Their perspective is also valuable to the PI planning process, mostly because they fully understand customer needs. Their input ensures that the goal and direction add value to the end user.

Developers research, design, test, and maintain software systems. During PI planning, they participate in breakout sessions to help refine user stories, identify risks, and help the product owner finalize the PI objectives.

Big room planning versus PI planning

Big room planning is another word for PI planning, but it indicates that the team meeting is in-person. Today, many teams opt for a hybrid format to host these meetings. This allows distributed teams to easily attend the sessions from wherever they are. And when the meetings are online, the teams can record the sessions and review them in the future.

But managing an online PI planning session doesn’t come without challenges. Hosting a virtual meeting can be hard for hosts, with more considerations to make than an in-person event. Technology, for example, is a big factor to think about. If the technology doesn’t work or isn’t efficient, the entire meeting could fall apart. Online meetings can also be tricky for attendees. Focusing on a screen for long periods can be challenging, leading to a lack of concentration. Fortunately, there are tools to help you overcome these issues. Take a look at Miro as an example. If you choose to host a virtual PI planning session, a tool like Miro can help you plan, manage, and execute your meeting — as well as keep your participants engaged. Using a customizable and intuitive visual workspace allows teams to collaborate online. Start by selecting the ready-made PI planning template and begin recording all the information on Miro's infinite canvas. To keep participants focused, use the timer to cap the time spent in each session. Allow for breaks, and consider using icebreaker games to keep things light and engaging.

What to include in a PI planning agenda?

A successful PI planning meeting agenda should include the following information:

Business context

The business owner starts by describing the current state of the business. They’ll share the company’s vision for the future and outline how existing business solutions address current customer needs.

Product/solution vision

Product management then presents the current vision. This is often represented as the next 10 product features or the most pressing items in the product backlog. The product manager then highlights any changes from the last PI planning session.

Planning context

The RTE presents the planning process and outlines the expected outcomes.

Team breakouts

Participants break away into their teams to estimate the capacity for each iteration. The teams then create a draft plan outlining each iteration. This session is timed (use Miro’s Timer to manage this).

Draft plan review

Teams present their key planning outputs, including their capacity, PI objectives, risks, and dependencies. Other teams review all the draft plans and provide feedback.

Management review and problem-solving

Draft plans often present challenges to overcome, such as limited scope, capacity, resources, and conflicting dependencies. Management spends some time figuring out how to address these challenges. The RTE keeps this meeting on track.

Program risks

Before launching any new iterations, it’s important to identify potential risks. Teams categorize these risks into one of five categories. The first category is Resolved , which means the entire team agrees that there’s no longer a risk. The second category is Owned , meaning someone takes ownership of managing an unresolved risk. The third category is Accepted , which includes risks that are unavoidable and simply need to be understood and accepted. The fourth category is Mitigated , where teams figure out how to reduce the impact of a risk. Finally, the fifth category is Confidence Vote . The confidence vote in PI planning allows teams to vote on how confident they are that the team will meet the objectives after addressing all the risks.

Rework plan

Teams then rework their plans and address potential risks to achieve as high a confidence level as possible.

Planning retrospective and moving forward

In the final stage of the meeting, the RTE leads a brief retrospective. They’ll cover what went well, what didn’t, and what can be improved for the next session. The amount of time you assign to each of these areas is up to you. There’s no right or wrong but bear in mind that it’s harder for team members to maintain focus if they’re attending the meeting virtually. Allow for enough breaks throughout the session to keep them motivated and engaged.

How to prepare for a PI planning session

Follow these three simple steps to prepare for your next PI planning session.

Perform pre-planning activities

Pre PI planning events help everything run smoothly on the day of the session. You’ll make sure that all teams are ready for the session, that the necessary people have been invited, and that the technology (or location, if the meeting is in person) is ready to go. Here are the three key areas of pre PI planning:

1. Organizational readiness

This involves preparing the planning scope to ensure everyone is prepared for the meeting. It also means aligning the business priorities ahead of the meeting to make them as streamlined as possible and ensuring all critical roles are assigned.

2. Content readiness

To ensure a clear vision for the meeting, teams need to have all the right content ahead of it. This includes the executive briefing to define the current state of the business, an up-to-date product backlog, and the architecture vision briefing.

3. Logistics readiness

Organizing logistics is a vital part of PI planning. It involves planning the location (at a facility or online), sourcing the right technology, and choosing the right communication channels.

Choose the right platform

Planning to run a virtual PI planning session ? You need software that works for you and your Agile team. If the platform isn’t right, it can be difficult to run a successful meeting. To find the right platform, think about the features you need to make your meeting run as smoothly and efficiently as possible. Here are some suggestions:

A collaborative workspace . A virtual, collaborative workspace allows teams to work together throughout the session. Using an online workspace, especially one with specific features to enable PI Planning can help boost productivity, camaraderie and innovation.

Top-quality video chat . If participants are dialing in virtually, you need a high-quality video call platform. That way, everyone can experience the meeting without experiencing any glitches.

A timer . Keep your meetings on track by using a timer. This helps teams be as concise and productive as possible during the session.

Voting . Ensure all opinions are taken into account by using a voting tool.

Templates . Speed up by leveraging tried and tested templates to take advantage of best practices.

Understand the inputs and outputs

The items you’ll need to prepare before the meeting are your inputs. They’re vital to the success of your PI planning session, so it’s important to know exactly what they are and how to prepare them. Here are some examples of PI planning inputs:

Executive briefings. Briefings must be prepared beforehand to align teams and provide context for your session.

Roadmap and vision. You need a clear definition of the business’s direction and management’s vision for the future.

Program backlog. Prepare your prioritized list of product features and functionalities before the meeting so that you can discuss which items to focus on in your upcoming iterations.

Now, let’s look at the outputs.

Outputs are any tangible outcomes from your planning session. Two outcomes of PI planning indicate that the session was a success:

Committed PI objectives. The team’s commitment during the PI planning will result in a set of SMART goals that outline what you intend to achieve in your upcoming iterations. Each team may have its own goal to focus on, depending on what you discussed during the session.

A program board. A program board outlines your delivery dates, dependencies among teams, milestones, and a timeline of the events.

These outputs mark the end of your PI planning session. They’ll guide your future iterations and help your teams achieve their goals before returning to the drawing board for a new PI planning meeting.

Use Miro to host your PI Planning event

Miro's integrated set of Agile tools helps teams of all sizes run PI Planning events efficiently. Streamline preparations, align on dependencies, and run sessions that are engaging and collaborative.

Discover more

The ultimate guide to facilitating hybrid pi planning, what is an agile workflow, how to hold sprint planning & review meetings, what is safe, get on board in seconds, plans and pricing.

• Announcements
• Brainstorming
• Development
• HR Planning
• Infographics
• IT & Operations
• Marketing & Sales
• Meeting & Visual Collaboration
• Product Management
• Production & Manufacturing
• Project Management
• Remote Working
• Research & Analysis
• Software Teams
• Strategy & Planning
• Template Roundup
• Uncategorized

Quick Guide to Easier Remote Program Increment (PI) Planning

Updated on: 25 November 2022

PI Planning is an essential part of the Scaled Agile Framework TM . It is a great way to get your teams aligned and focused on what’s important. However, it can be tough to know where to start. This guide will walk you through the basics of PI Planning and what you need to include in your agenda to achieve successful planning outcomes. 

What is PI planning?

Program Increment planning, or PI planning, is a cadence-based event that is essential to the successful execution of agile releases. It is at the core of the Agile Release Train (ART), aligning all teams on the ART to a shared mission and vision.

PI planning sessions are regularly scheduled events held throughout the year where multiple teams in the same Agile Release Train meet to discuss features, the way forward, the roadmap, and cross-team dependencies. 

The PI Planning event is usually organized by the Release Train Engineer (Scrum Master) and is held over a 2-day period that includes 8 to 12 weeks of program increments.

An organization can decide on when to have the PI sessions. For example, many companies schedule PI planning at the beginning of a program increment and after the inspect and adapt iteration, while some opt to have the sessions quarterly. These sessions happen regularly on a fixed schedule allowing project managers or relevant teams to plan ahead of time.

SAFe or Scaled Agile Framework TM is a set of guidelines and practices that support larger organizations to adopt agility. It consists of four steps; planning, execution, adaptation, and reflection. SAFe is accepted as a methodology that increases visibility, alignment, and collaboration among different teams and levels resulting in better productivity and delivery.

Remote PI Planning

PI Planning sessions are traditionally held in person. However, the pandemic changed the workplace irrevocably where locating different teams and team members in one place, in person, is not always possible. As such, the priority is to gather all relevant teams who are part of the work in real-time to be present in the planning. To facilitate and support these sessions remotely, a host of online tools and necessary technologies are used.

Why is PI Planning Important?

PI planning is essential for companies of all sizes but is especially valuable for large organizations that may have 100-200 teams and 1000s of developers. Previous to introducing PI planning, these teams did not have any communications with each other and therefore information would be cascaded down from the leadership and management level leading to conflicts in resources, budgets, and work.

With PI Planning in place, proper communication protocols enable teams to get together and discuss what they’re working on and ensure that dependencies are understood and managed effectively. For example, situations where two teams working on different features without realizing there’s a dependency that could hold up the release or require a significant rework of the code, could be avoided. 

During PI Planning sessions, teams and team members meet face-to-face (remotely or in person), paving the way for one-on-one interactions that would result in better cooperation in future work. At the end of a PI planning session, the teams are equipped with a plan that includes iterations, backlogs, objectives, and risks for the next program increment.

PI Planning in a nutshell enables, 

• structured communications and visibility 
• collaboration and better synchronization among different teams 
• effective work, alignment on tasks and objectives
• ability to release features in less time and to stay within a budget.

Planning the Event

There are three steps for successful PI Planning.

• Organizational readiness: Make sure that all stakeholders and leaders in the program are available to participate. It would be best if PI planning sessions are scheduled in advance and teams are sent reminders.
• Content readiness : The vision and purpose of the PI session and the program need to be well prepared and in hand in time for the session. This should be clearly communicated to all participants on the first day.
• Logistics preparation: Arrange a large room, if in person, a Microsoft Teams or team Zoom call that can accommodate all participants. In remote sessions, use breakout rooms to divide the teams into small groups so that they can engage with each other more.

Before a PI event, besides the above steps, ensure that the below-mentioned items are identified and established as well. 

• Project vision and goals
• Project scope, constraints, timeline, and milestones
• Resources required
• Roles and responsibilities

The agenda of the PI planning event plays a critical role. It is the framework that guides participants on what needs to be covered in order for all to understand their role in building and executing the agile release train. The agenda should always be kept simple and easy so that participants can focus on what matters the most: delivering value.

While PI planning or remote PI planning may be different for each organization, there are certain similarities. Below is the standard agenda for a two-day PI planning session that you could follow.

Business Context

An update about the current business status, portfolio vision, and how effective the current solutions are in addressing customer needs. This is usually presented by the business owner or a senior executive.

Product/Solution Vision

This entails the current vision, which includes the top 10 upcoming features, any changes from the prior PI planning event, and prospective milestones. The product/solution vision is typically presented by Product Management.

Architecture Vision & Development Practices

The architecture vision and agile-related changes for improvements to the infrastructure, development process, and communications in the upcoming PI. The Architect/Engineering department takes the lead in presenting the architecture vision and development practices.

Planning Background

An outline of how the planning process works and what is expected.

Breakout Sessions

Several breakout sessions, two at least, spread out during the two days. For the first session, teams will work to identify their capacities, backlogs, risks, and dependencies to come up with draft plans that include initial team PI objectives to be shared with others. These PI objectives consist of goals that are included in the plan but are not committed due to unknown factors or risks. 

In the second session, which typically takes place on the second day, teams will continue to work on the plans and make adjustments as necessary. The objectives for the PI are finalized by the teams before being handed over to the business owners or senior management to assign business values.

Draft Plan Review

Teams present draft plans for feedback. Here teams are encouraged to communicate and identify associated dependencies with other teams or agile release trains. The session is a tightly timeboxed sitting where teams present key planning outputs, draft PI objectives, potential risks, and dependencies. Business owners and other teams provide input after each team presents.

Management Review

Business owners, stakeholders, and management will meet to address challenges presented in the draft plan to propose solutions or changes. Special attention will be paid to challenges in scope, resource issues, and dependencies. During the management review and problem-solving meeting, the management will look into sorting scope changes, resolving various issues, and making adjustments.

Final Plan Review

Each team presents its plans to the group. After each presentation, each team highlights risks, dependencies, and barriers. The plan is presented to the business owner and management for approval. If the plan is approved, the PI objectives are put forth for everyone to see. If the management has certain concerns, the team is provided time to address the concerns and present the revised plan.

Program Risks

Teams will identify risks that impede achieving objectives during the planning session. The identified risks will be presented to the whole group and addressed with transparency. During this process, the risks will be categorized as below. 

• Resolved: the risk is no longer a concern and has been resolved
• Owned: a member of the group takes ownership of the risk, which cannot be resolved during the discussion
• Accepted: some risks are understood and accepted as potential issues or the reality of the situation 
• Mitigated: a plan is identified to reduce the impact of the risk

Retrospective

A brief retrospective is held to obtain feedback on the event and what needs to be improved for future events.

Inputs and Outputs of PI Planning (Useful Templates)

• Business context

• Roadmap and vision

• Top 10 features of the program backlog

• Committed PI objectives: this includes a set of SMART objectives created by the teams with the value of the business assigned by the owners of the business.

• Program board: include dates as to when the new features will be released, dependencies among teams, and milestones.

Tips for Successful Remote PI Planning

Remote PI planning events are ideal for distributed teams. It’s cost-effective and allows all teams to participate regardless of their location. Besides the three important steps mentioned in ‘Planning the Event’, it would be important to keep note of the following for a hiccup-free remote event.

Online tools are your go-to platform

Use online tools to confirm participation, share information, conduct meetings and interact in real-time. Also, have a dedicated team to facilitate the sessions and provide support. 

Create a schedule and sign up sheets well in advance

Create the PI planning event’s schedule and inform stakeholders well in advance. Ask participants to sign up to confirm their participation.

Select the right time

With distributed teams, chances are team members are scattered throughout the world in different time zones. When selecting the time for the event, be mindful of the time differences and ensure that the event does not go beyond 6-8 hours. 

Etiquettes to follow

To avoid miscommunications, and unnecessary interruptions, circulate a list of etiquettes to follow. For example, request all team members to have their cameras turned on and to actively participate. Also, make sure to let them know when it is acceptable to talk and when to keep their mics muted. 

Avoid monotony and build trust

Provide participants some respite by including several 5-minute breaks and also ice breaker sessions to keep things interesting and to build trust.

Record the session

Livestream and record the session. This is useful for team members who may miss the session due to unavoidable circumstances or if you need to refer back.

Avoid surprises 

Stick to the shared agenda and communicate with participants regarding their roles and expectations. 

PI planning sessions are an essential part of agile release management. Make sure to attend a few sessions each year to stay on track and ensure successful product delivery.

Use Creately for your Remote PI Planning

Creately has a host of tools to make your PI planning virtually seamless from the very start.

• Whiteboard and freehand drawing capabilities to brainstorm and collaborate on important ideas, risks, and dependencies.
• 1,000 plus templates and shapes to start preparing the agenda and other needed formats for the PI planning sessions ahead of time to share with the members of the agile train. 
• In-app audio and video conferencing to liaise with other team members to brainstorm and discuss the preparations.
• Share workspaces and folders with peers and colleagues. Multiple access and role levels to manage, share, edit and review along with multiplayer capabilities to collaborate in real-time.
• Integration with MS Teams to conduct your meeting and manage the project board all in one place

Initiate your next PI Planning or Remote PI Planning session with Creately to experience the best of visual project management!

Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.

More Related Articles

Leave a comment Cancel reply

Please enter an answer in digits: four × one =

Download our all-new eBook for tips on 50 powerful Business Diagrams for Strategic Planning.

PI Planning and Scaling Agile Tool For SAFe Organizations

OKRs, Strategic Themes, Portfolio, Roadmaps, Dependency Management, ROAM Risks

What is PI Planning?

• PI Planning: The need
• PI Planning: Goals and Outcomes
• PI Planning: Program Board
• PI Planning: Conductor
• PI Planning: Participants
• PI Planning: Frequency
• PI Planning: Agenda, Duration and Events

BONUS TIP I

• Remote PI Planning: The need
• Remote PI Planning: Focus Areas
• Remote PI Planning: Agenda, Duration and Events

BONUS TIP II

BONUS TIP III

BONUS TIP IV

• PI Planning with Jira users

Pre PI Planning

Pi planning day, post pi planning.

• PI Planning for Azure Devops

How to conduct PI Planning?

• What is a successful PI Planning session?
• How to run a great virtual/distributed/remote PI Planning?
• How to overcome PI Planning Challenges?
• What is a PI Planning Preparation Checklist?
• Can you provide a PI Planning Template?

In the end we share with you an editable and downloadable Step-by-step guide for your PI Planning.

PI Planning 101 What is a successful PI Planning session?

• synchronization,
• (cross-team and cross-ART) collaboration,
• alignment (on business context workflows, objectives, vision, and more),
• social network,
• system architecture evaluation,
• eliminating excess Work in Process (WIP),
• efficiency in decision making,
• transparency for predictability and agility.

A successful PI Planning event ticks all these boxes, on top of managing to show a ‘Working Software’ at the end of the iteration. Put simply, if your PI Planning has succeeded in providing these two outputs, your PI Planning event has met its goal:

• Committed PI Objectives
• Where the PI Objectives identify a set of SMART objectives created by each team making up the ART, with the business value assigned by the Business Owners. PI objectives commitment is the holy grail of your ART.
• Program Board
• A compilation of data presenting the most accurate picture of your ART situation, highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones. It is the crystal ball of your ART.
• Break User Stories into tasks during the Team breakouts;
• Create Iteration plans and Team PI Objectives;
• Identify/address risks;
• Give the Confidence Vote
• Presents the ART architecture vision;
• Helps establish inter-team dependencies and risks
• Assists the team in preparation for ART activities, System Demos, and the Inspect and Adapt;
• Guides the team in establishing normalized estimates;
• Helps the team understand how to estimate Features and Capabilities
• Provides backlog prioritization;
• Presents the vision, which highlights the proposed features of the solution;
• Shares any relevant upcoming Milestones;
• Breaks Features into User Stories
• Presents the planning process and the expected outcomes;
• Facilitates the Management Review, Problem Solving session and retrospective. Due to this, an RTE is responsible to conduct a PI Planning session
• Q1 PI Planning: December
• Q2 PI Planning: March
• Q3 PI Planning: June
• Q4 PI Planning: September

They are planned in advance following a regular and fixed schedule. Invitations are sent out before time as well so that all the preparations can be done timely.

In case of Distributed or Remote PI Planning, however, the agenda remains the same, however the schedule of events depends on numerous variables which are discussed in the section below.

Distributed PI Planning How to run a great distributed/remote PI Planning?

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Contrary to popular belief, the core strength of PI Planning is not rooted in the co-location of your teams. It is in structuring and empowering the driving mechanism to an extent that physical proximity, or lack thereof, is no longer a factor in carrying out a fluid, transparent communication.

• Maintaining logistics for a handful of multi-site, multi-cultural teams,
• Regional travel restrictions in lieu of the pandemic
• Providing an environment of psychological safety in an unfamiliar setting
• Finding a venue, big enough, right enough, for the event,
• And last, but certainly not the least, the financial and time costs of all this elaborate arrangement.

Conducting a virtual PI Planning session is not a piece of cake either, agreed. However, if sufficient thought is put into crafting an experience of a social construct where your Agile teams feel seen, in their work as well as their person, the ROI of your remote event can actually be better than that of the one in person. Just make sure that you take home all the experiential wisdom and practical knowledge offered in all the sections of this guide and the Bonus Tips.

• Planning Locations: Minimize the number of dispersed locations by determining the number of locations needed.
• PI Planning Agenda: Creating an inclusive PI planning agenda to accommodate multiple time zones for the participating teams.
• Facilities: Setting up the appropriate physical space to conduct the planning.
• Working Agreements: Meeting the needs of the event attendees to optimize the experience for each member of the ART.
• Tooling: Employing adequate technology to support the range of planning activities.
• Facilitation: Executing a successful distributed PI planning event.

A sample schedule for a remote PI planning event for two time zones and split across three half-days with frequent breaks.

PI Planning: Challenges How to overcome PI Planning Challenges?

• Transparency and alignment across the ART,
• Effective collaboration,
• Efficient and impactful decision making,
• Meaningful communication,
• Purposeful engagement.

In terms of execution, these challenges translate as:

• Poor data assimilation,
• Manual collection of information with time costs and error proneness,
• Losing track of business objectives,
• Ill-timed sessions,
• Long heavy session,
• Technical failures,
• Ill prepared session management.

For an RTE with Jira teams, the biggest challenge for conducting an in-person and/or remote PI Planning, is to ensure a smooth, hassle-free, real-time, bi-directional integration between their planning board and Jira. Some organizations employ a visualization tool for their planning board. At the onset, this may seem to be an easy way out for conducting PI Planning, but can result in serious implications during the PI Planning event and the post PI Planning scenario. The most common hiccups faced are:

When scaling agile, there are heavy price tags attached to these challenges. Time lost and financial cost are only the measurable ones among these. The disappointment/demotivation of the team members and the trust deficit among the ART teams is often an unrecognized and mostly an irrecoverable damage. Thankfully, with Kendis these challenges can be taken care of effortlessly.

PI Planning: Preparation Checklist What is a PI Planning Preparation Checklist?

• Organizational readiness: Strategic alignment and teams and trains setup
• Content readiness: Management and development preparedness
• Logistics readiness: Considerations for running a successful event

Based on these three themes, here is the list of considerations you should be particular about:

• Planning scope and context: Has the scope (product, system, technology domain) of the planning process been identified? Do we know which teams need to plan together?
• Business alignment: Has there been a common understanding of the priorities among the Business Owners?
• Agile teams: Do all our Agile teams have dedicated team members, and an identified Scrum Master and Product Owner for each team?
• Executive briefing: A briefing that establishes the current business context for all the participants
• Product vision briefing: Is the Product Management briefing about the top 10 features in the Program Backlog?
• Architecture vision briefing: Has the CTO/Enterprise Architect/System Architect briefed about the new Enablers, features, and Non-functional Requirements (NFRs)?
• Locations: How many planning location do we need to maintain?
• Technology and tooling: Coupled with our ALM tool, Kendis will take care of our real-time PI Program Board, PI Objectives, ROAMing Risks, Dependency Management and PI Planning ceremonies, including: Scrum of Scrums, Confidence Vote and Inspect and Adapt. What other tools do we need to support distributed planning or remote attendees? (Hint: The answer is none. You’re good to go!)
• Communication channels: Primary and secondary audio, video, and presentation and conversation channels for an effective personal experience.

You must have noticed that the checklist heavily relies on contributions from all participants of the ART, as reflected in the section above documenting the PI Planning Participants and their roles.

PI Planning: Step-by-Step Guide Can you provide a PI Planning template?

• 01 The RTEs set up the PI Board at Kendis, defining the PI dates and duration
• 02 Connect with your Jira boards
• 03 Create your color-coded Teams
• 04 Define the Sprints for the Program Increment
• 05 Get Features from Jira onto your Kendis Board, using Jira filters or JQL with no performance impact to Jira
• 06 Team Stories in Jira, that are already linked to the Features, are fetched automatically at your board
• 07 Map your teams in Kendis to Jira boards
• 08 Now, invite your teams to your Kendis Board
• 09 Start setting up the planning by defining the business context through Business Values and prioritizing the Features.
• 01 During the Team Breakouts, the Scrum Masters set the capacity of each team for every Sprint in their specific team areas at Kendis
• 02 Pull Features from the prioritized Program Backlog at your Jira board to the Sprints on your Kendis Board
• 03 Expand the Features Card and Create Stories, with a title and estimate of story points. These Stories instantly appear on your Jira as well, linked to the specific Feature and assigned to a Sprint
• 04 Visualize the color-coded Dependencies using drag and drop, labelling the status, link types and description. Track the resolution of your Dependencies as their visualization changes on the board
• 05 Use the Business Value of your Objectives, linking each to your Features
• 06 Measure the progress of each Objective in your PI
• 07 At the Plan Review stage, the Product Owners use the Kendis Board to communicate the state of dependencies, highlight the risks, explaining their plan
• 08 View the Feature completion dates for each team
• 09 Evaluate the Capacity-Load relationship of each team with their Sprints
• 10 ROAM your risks using the Risks Register at the Kendis Board
• 11 Employ the Confidence Vote facility on your Kendis Board, to cast vote for your PI, or Teams, or both
• 12 Conduct the Inspect and Adapt session using the Inspect & Adapt module at your Kendis Board. Measure the program performance, evaluate the program delivery, and
• 13 Once the planning part is done, change your Kendis Board state to Tracking
• 14 Export the Kendis Board data to shareable formats in excel, csv etc.
• 01 Using Kendis Board’s strong visual management capacity, track progress of your Dependencies and Objectives
• 02 Use Scope Change Tracker for automated tracking of your PI progress
• 03 Identify the Features added/edited, Stories that changed their Sprints, to predict Scope increases, understanding how and when any deviations occur in execution compared to the original PI Planning.
• 02 Connect with Azure DevOps or TFS by providing relevant URL and API token
• 05 Get Features from Jira onto your Kendis Board, using existing queries or type new Wiql
• 06 Determine how the Stories are related to the Features
• 07 All the child-item Stories of the Features you got through the queries, are automatically fetched at your Kendis Board
• 08 Map your teams in Kendis to Azure DevOps
• 09 Now, invite your teams to your Kendis Board
• 10 Start setting up the planning by defining the business context through Business Values and prioritizing the Features
• 02 Pull Features from the prioritized Program Backlog in your Azure Devops to the Sprints on your Kendis Board
• 03 Expand the Features Card and Create Stories, with a title and estimate of story points. These Stories instantly appear in your Azure Devops as well, linked to the specific Feature and assigned to a Sprint
• 14 Export the Kendis Board data to shareable formats in excel, csv etc
• 03 Identify the Features added/edited, Stories that changed their Sprints, to predict Scope increases, understanding how and when any deviations occur in execution compared to the original PI Planning

Have we been able to address your questions regarding PI Planning?

Explore articles about scaling agile.

• On September 4, 2024

Protected: Planning Program Risks in PI Planning

There is no excerpt because this is a protected post.

• On August 21, 2024

Testing and Release Strategies in PI Planning

Kendis suggests reserving time to discuss Testing and Release strategies during the PI Planning event. Testing is a foundational and crucial aspect of software development…

• On July 9, 2024

Planning Adjustments in PI Planning

Planning Adjustments take place after the Draft Plan or Management Review and are usually the first event of Day 2 if you are following the…

• On May 20, 2024

PI Planning is done….now what?

As the dust settles after the exhilarating event of PI (Program Increment) planning, teams brace themselves for the journey ahead. PI planning marks the beginning…

• On May 9, 2024

Management Review in PI Planning

The event that concludes the first day of the PI Planning Agenda is called the Management Review. Contents What is Management Review? How is the…

Are your Scrum Masters Coaches? Redefining Roles in Scaled Agile Framework with Kendis

In the ever-evolving landscape of Agile methodologies, the Scaled Agile Framework (SAFe) has recently made a significant terminology shift by rebranding Scrum Masters as “coaches.”…

• On May 2, 2024

Draft Plan Review in Pl Planning

The event that shows the results and summarizes the collective efforts of all the teams involved in the Team Break-Out sessions in the PI Planning…

• On March 28, 2024

Planning Context in PI Planning

As we approach halfway towards the first day of the PI Planning Agenda, after setting the Business Context,Product and Solution Vision, and Architectural Vision, the…

• On March 6, 2024

Architectural Vision in PI Planning for SAFe

After establishing solid ground for PI Planning in the Scaled Agile Framework in the PI Planning Agenda with the Business Context and the Product and…

• On February 19, 2024

Product and Solution Vision in PI Planning for SAFe

After the Business Context is presented and has provided the basis for PI Planning in the Scaled Agile Framework in the PI Planning Agenda, the…

Got Questions?

• Program reports and analytics
• Dependencies Management

Risk Register Tracking

Feature tracking.

• Scope Change Tracking

Kendis offers the complete solution for your scaling agile needs

• Risks Management
• PI Objectives

Ready to get started?

• Protected: Planning Program Risks in PI Planning Source: Planning Program Risks in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-09-04
• Testing and Release Strategies in PI Planning Source: Testing and Release Strategies in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-08-21
• Planning Adjustments in PI Planning Source: Planning Adjustments in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-07-09
• PI Planning is done….now what? Source: PI Planning is done….now what? - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-05-20
• Management Review in PI Planning Source: Management Review in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-05-09
• Are your Scrum Masters Coaches? Redefining Roles in Scaled Agile Framework with Kendis Source: Management Review in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-05-09
• Draft Plan Review in Pl Planning Source: Draft Plan Review in Pl Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-05-02
• Planning Context in PI Planning Source: Planning Context in PI Planning - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-03-28
• Architectural Vision in PI Planning for SAFe Source: Architectural Vision in PI Planning for SAFe - PI Planning and Scaling Agile Tool For SAFe Organizations Published on 2024-03-06
• Product and Solution Vision in PI Planning for SAFe Source: Product and Solution Vision in PI Planning for SAFe Published on 2024-02-19

Please enter your email address for Scrum Master Activities in Kendis Checklist

Please enter your email address to download the free checklist

Please enter your email address to get your free Feature Template.

Please enter your email address to get your free Value Stream Mapping Template.

Please enter your email address to get your free User Story Mapping Template.

Get a Detailed Insight into our Deployment Options

Introduction to SAFe PI planning

Lucid Content

Reading time: about 8 min

Companies are always looking for ways to streamline operations and improve time to market. As companies grow, it can be harder to coordinate work among many different teams. This is where Program Increment (PI) planning comes in.

Let’s discuss what PI planning is, how it unifies multiple teams to work toward the same goals, and how to prepare for and run your PI planning meetings.

What is PI planning? 

PI planning is integral to ensuring that large corporations can work within an Agile framework. Here are a few terms that are used throughout this article that can help you understand how PI planning fits into an Agile environment.

Scaled Agile Framework (SAFe): A set of procedures and practices designed to help large organizations with multiple teams to be more agile. Its aim is to unify multiple groups to collaborate, be more flexible, have greater transparency, and align project strategies and goals.

Agile Release Train (ART): A team that is made up of Agile teams. This cross-functional group of 50 to 125 people who work on the same project. The members of the ART are aligned to a shared business and technological mission. This team plans and commits to the work that will be completed in the PI.

PI planning: An activity with the intent of ensuring that the ART is on the same track moving in the same direction. PI planning events are face-to-face meetings held every eight to 12 weeks after the previous PI. Multiple teams come together to plan and define the work that needs to be done, review backlogs, discuss which features will add value, create or update the product roadmap, and identify risks and dependencies.  

What is the goal of the PI planning event?

Often in large companies, there is a tendency for different teams to work in silos with little or no communication unless a problem arises. Senior management and the executives may be in alignment and share a vision for the company, but that vision can get lost in translation as it is communicated down through the various levels of management.

PI planning opens the lines of communication among various teams and asks that all teams agree on the direction the business is taking.

In addition to opening lines of communication, the goal of a PI planning event is to: 

Create an Agile Release Train (ART). The ART aligns vision, planning, risks, and dependencies among the various teams to focus on fast, flexible development and release.

Plan and update the product roadmap.

Define Agile SMART goals or objectives. Following this acronym, these objectives should be specific, measurable, achievable, relevant, and timely.

Create a program board so all teams and stakeholders can have an easily accessible visual summary of the goals, features, risks, dependencies, and timelines defined in the program increment plan.

Benefits of PI planning

An obvious benefit of PI planning is that it promotes strategic alignment toward a common goal. In addition, PI planning helps companies:

• Establish open and face-to-face communication among all teams and stakeholders.
• Agree on common goals, vision, and objectives.
• Effectively plan each team’s work for the PI time period.
• Have a better understanding of their individual roles and how they align with the PI plan’s vision and business goals.
• Identify risks and dependencies and ensure that team members know who to contact when they need help.
• Collaborate among cross-functional teams.
• Increase business production.
• Keep focused and on track.

Steps of PI planning

PI planning sessions cannot be completed in one afternoon. These events are typically scheduled for two days and require a significant amount of preparation before the event and can benefit from post-event review to make improvements for the next PI.

Step 1: Pre-PI planning and preparation

Pre-PI planning events ensure that the teams for the train are set up, the necessary people have been invited, and the facilities and location are scheduled and ready to go.

You will need to prepare for the PI planning sessions in the following areas:

Organizational readiness: PI planning events need to be scheduled early enough to ensure that all team members, leaders, and stakeholders can make arrangements to attend. Your organization may consider making this a regular quarterly meeting so it’s already on the schedule. In addition, the organizers should prepare a common planning scope and context and assemble Agile teams.

Content readiness: Ensure that senior leadership has prepared a clear vision and context and is prepared to present this information.

Facility readiness: Find and schedule a large room that can accommodate all participants. The room needs to be big enough so that teams can move around and hold their breakout sessions. If team members cannot be physically in attendance, make sure that all connections are ready so people can participate and contribute remotely.

Step 2: Create a PI planning agenda

SAFe suggests the following standard agenda for your planning sessions.

8:00 a.m. to 9:00 a.m.

Business context Senior management lets the ART know how the business is doing in relation to market and consumer needs.

9:00 a.m. to 10:30 a.m.

Product/solution vision Product managers present the business vision for the upcoming PI.

10:30 a.m. to 11:30 a.m.

Architecture vision and development practices IT infrastructure improvements that will improve the time to market are outlined.

11:30 a.m. to 1:00 p.m.

Planning context and lunch The release train engineer (RTE) outlines the planning process and communicates the meeting outcome expectations.

1:00 p.m. to 4:00 p.m.

Team breakout sessions Teams look at the planning boards to estimate the capacity to accomplish the tasks in each iteration. Digital planning boards that can be accessed by remote team members are ideal to ensure that all team members can work on the same document at the same time.

4:00 p.m. to 5:00 p.m.

Draft plan review Teams create a draft of their plans for the PI and present to get feedback from business owners, product owners, stakeholders, and other teams.

5:00 p.m. to 6:00 p.m.

Management review and problem-solving The RTE and management teams address issues that are identified in the draft plans. This meeting should result in a new set of priorities and/or features that the teams can use on day two.

Planning adjustments Management communicates any changes in scope, people, and resources made in the problem-solving meeting. 

9:00 a.m. to 11:00 a.m.

Team breakout sessions The teams regroup around their planning boards and develop a new plan based on the adjustments made by management.

11:00 a.m. to 1:00 p.m.

Final plan review and lunch Each team presents its plans and identifies risks and dependencies.

1:00 p.m. to 2:00 p.m.

Program risks The teams address the risks that were identified in the final plan review meeting and determine how or if they can be overcome.

2:00 p.m. to 2:15 p.m.

Confidence vote All objectives are known and all risks have been identified. Teams vote on their confidence in accomplishing their PI objectives. Team members hold up one to five fingers to vote. One or two fingers indicates that the team needs to rework the plan and vote again.

2:15 p.m to finish

Plan rework (if needed) This time is used to rework the plan to address items that got less than a three-finger vote.

Planning retrospective and moving forward The RTE holds a small retrospective to determine what went well in the PI planning sessions and what could be improved for next time.

Step 3: Post-PI planning

Post-planning sessions are used to integrate the results from the PI planning meetings into the vision and roadmap. At the end of the PI, everybody involved should agree on objectives to be implemented and demonstrated at the next solution demo.

As companies grow and have a larger global footprint, teams are much more globally distributed. SAFe PI planning makes it easier for large organizations to work in an Agile environment by aligning multiple teams to work toward the same goals in a scheduled, timeboxed process. Digital planning tools help to bring global teams together in virtual meetings to participate in planning sessions that define work that needs to be accomplished in each PI. 

Learn more about how a SAFe program board works and how you can use one effectively.

About Lucidchart

Lucidchart, a cloud-based intelligent diagramming application, is a core component of Lucid Software's Visual Collaboration Suite. This intuitive, cloud-based solution empowers teams to collaborate in real-time to build flowcharts, mockups, UML diagrams, customer journey maps, and more. Lucidchart propels teams forward to build the future faster. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucidchart.com.

Bring your bright ideas to life.

or continue with

By registering, you agree to our Terms of Service and you acknowledge that you have read and understand our Privacy Policy .

All you need to know about Program Increment (PI) Planning

The same way tracks keep all train cars going in the same direction, PI Planning keeps your Agile Release Train running. Without PI Planning, there’s no proper SAFe®. But what is PI Planning and how do you do it? We’ve got you covered!

A word on Program Increment (vs Sprint)

Before we dive into PI Planning, let’s first explain what SAFe® PI is, and how it compares to a Sprint/iteration in Agile.

In many ways, PIs and Sprints are fairly similar. After all, SAFe® is one of many Scaled Agile frameworks meant for practicing Agile on a much larger scale. So like Sprints in Scrum , SAFe® Program Increment also delivers incremental value based on a  common goal after a fixed period of time. 

But instead of a single one- to four-week Sprints in Agile, SAFe Program Increments comprise several Sprints, lasting a total of 8-12 weeks . So how many Sprints are there in a single PI? It depends on the duration of your Sprints. If your Sprints are two weeks long, then one PI consists of four to six Sprints . In other words, Sprints are subsets of PIs.

The incremental value of a Program is the outcome of not one or two but several Agile/ Scrum teams . Those teams, in turn, are part of an ART (Agile Release Train) comprising 50 to 125 people. As a result, Program increments (PIs) take place among several Scrum teams , while Sprints occur within individual Scrum teams .

And the cadence in Scrum is higher because Sprints are much shorter. They “beat” more frequently. Program Increments, on the other hand, take longer and don’t happen as often. For that reason, the cadence of PIs is lower .

To summarize, Program Increments are like Sprints but at a higher level. They last longer and involve more people. And just as Sprint/iteration is to an Agile team , a Program Increment is to an Agile Release Train.

So what is PI planning?

PI Planning is a  regular face-to-face event based on the cadence of consequent Program Increments. Organizations carry out PI Planning sessions every 8-12 weeks (depending on the length of their Program Increments) typically after the Inspect and Adapt session . A standard planning session is 2 days long, but the ART can extend this timebox to accommodate planning across multiple time zones.

Who attends the PI Planning event?

PI Planning brings together everyone who has an interest or can contribute to the planning. So this event isn’t just for the teams on their respective ARTs, or the RTE (Release Train Engineer) facilitating the event. You’ll also see key stakeholders, Product Owners and Managers, Scrum Masters /Team Coaches, and maybe even someone from the lean portfolio management group.

What’s the ultimate goal of PI Planning?

The Agile Release Train (ART) is the key to all your Scrum teams working together toward a common goal. In large enterprises, there could be more than two Trains working. Making things even more complicated, members of the Scrum teams on those ARTs often work from different locations. So it stands to reason that teams need a chance to step back and make sure they’re still working toward the same business goals and overall vision. 

So in essence, the PI Planning helps ARTs create alignment and encourage collaboration . It also enables them to self-organize and eliminate waste. During the event, participants get to know one another face-to-face, which translates into stronger relationships and better cooperation.

In addition, because everyone is present in the same room (or sees each other remotely), participants can quickly resolve dependencies and talk with Managers and stakeholders. Thus, PI Planning also promotes faster decision-making for stakeholders and Agile teams.

Other goals of PI Planning

In to addition opening communication lines and encouraging cooperation, a PI planning event promotes other goals.

• Q1 PI Planning: December
• Q2 PI Planning: March
• Q3 PI Planning: June
• Q4 PI Planning: September

Preparing for Program Increment Planning

Having so many people at a single meeting is undoubtedly beneficial and fun. But it does have its downsides because PI Planning involves dozens of people. To make such a large event successful, you’ll need to devote a lot of attention to details in three major areas : organizational readiness, content readiness, and logistics readiness. Let’s take a look at them in more detail.

Organizational readiness

PI Planning is a massive event that involves many people from different organizational levels and departments. You need to make arrangements early enough (usually 4 weeks before) to enable participants to accommodate it in their schedules. Your organization could also consider making PI Planning a  regular quarterly meeting so it’s already on participants’ schedules.

Organizational readiness also involves the assignment of critical roles and assuring strategy alignment among participants, stakeholders, and Business Owners. At this stage, you identify members for your Agile teams. And also designate a Scrum Master/Team Coach and Product Owner for each team. In terms of business alignment, Organizational readiness means that Product Owners should’ve reached a reasonable agreement on priorities.

Content readiness

You’ll also need to ensure that senior leadership has prepared a  clear program vision and context they can communicate to the teams on day one. This step of PI Planning involves three types of briefings : Executive briefing (defines current business context); Product briefing (indicates top 10 features in the ART backlog); Architecture vision briefing (communicates new Enablers, features, and Non-Functional Requirements). 

Logistics readiness

The last step is securing and preparing the large space for people who’ll attend PI Planning in person. If you expect to have remote attendees or hold a fully distributed planning event, you’ll need to organize the necessary technical infrastructure .

Executing PI Planning with a standard two-day agenda

During PI Planning, Product Managers present the Vision Roadmap and the highest-priority features of the Program Backlog. Then Agile teams review what they can achieve on the basis of resource capacity , dependencies , and technical knowledge. (In PI Planning, Product Managers own feature priorities , while Agile teams own story planning and estimates .)

As teams create their plans and estimate capacity during breakouts, the Architects run the room to ensure teams plan their technical work properly. They also address any issues and concerns as they arise.

The entire 2-day event follows a  standard agenda. Below, you’ll find an outline of typical agenda items for each day, one by one.

PI Planning Agenda: Day 1

• 8:00 AM – 9:00 AM (Business Context): Business Owner (or senior executives) address how the organization is doing and how the solutions it produces meet customer needs.
• 9:00 AM – 10:30 AM (Product/Solution Vision): Product Managers present the Product Vision for the upcoming Program Increment (typically in the form of the top ~10 features).
• 10:30 AM – 11:30 AM (Architecture Vision and Development Practices) – the System Architect presents the architecture vision. Additionally, senior development managers go over Agile-supportive changes to development practices (e.g., test automation, DevOps, Continuous Integration, and Continuous Deployment) that Agile teams will adopt in the upcoming PI.
• 11:30 AM – 1 PM (Planning Context and Lunch): The Release Train Engineer outlines the planning process and the meeting outcome expectations. 
• 1 PM – 4 PM (Team Breakouts #1): With the help of the Agile planning boards, teams estimate their capacity and identify the backlog items they’ll need to complete to accomplish the tasks in each iteration.

• 4 PM – 5 PM (Draft Plan Review): Each team presents its key planning outputs and gets feedback from business owners, Product Owners, stakeholders, and other teams.
• 5 PM – 6 PM (Management Review and Problem-Solving): Facilitated by the RTE, the final hour on the agenda is dedicated to solving issues that have arisen due to architecture, dependencies, resources, and scope . The meeting is an opportunity to resolve those issues by negotiating the scope changes and other planning adjustments.

PI Planning Agenda: Day 2

• 8:00 AM – 9:00 AM (Planning Adjustments): The second day begins with management presenting any changes resulting from the Management Review and Problem-Solving meeting.
• 9:00 AM – 11:00 AM (Team Breakouts #2): Teams continue planning and make appropriate adjustments based on the changes communicated by management. They finalize objectives for the upcoming PI, while the Business Owners assign business values to those objectives and rank them accordingly.

• 11:00 AM – 1 PM (Final Plan Review and Lunch): This meeting is time-boxed. Every team presents its plans and identifies impediments and dependencies. Business Owners must approve all plans.
• Resolved (Teams agree the risk is no longer a concern).
• Owned   (One of the ART members becomes an owner of the risk and they’ll work on it later).
• Accepted (Some risks are simply facts that teams must understand and accept).
• Mitigated (Teams create a plan to reduce the impact of the risk).
• 2 PM – 2:15 PM (Confidence Vote): When teams finish discussing the PI risks, they vote on how confident they feel about meeting the PI objectives. On-site team members vote using their hands (a fist to five) while remote participants use a digital tool. If the objectives receive an average of less than three fingers , the team needs to rework their plan. Next, teams vote again, but this time for the entire ART with respect to the collective plan.

• 2:15 PM – until done (Plan Rework) – If the objectives received less than three fingers, team members have a chance to voice and address their concerns so teams can rework their plans.
• (Planning Retrospective and Moving Forward) – The RTE conducts a small retrospective to find out what went well in the PI planning sessions and what needs improvement.

PI Planning: next steps

When the PI Planning event is over, you still have a series of post-planning activities to complete. You’ll need to clean the meeting room (unless you had fully-remote planning). But there’s still some work left to do on the business side. 

First, the RTE and other ART stakeholders summarize individual team PI objectives into a collection of ART PI objectives. Then, the Product Managers use those objectives to refine their roadmaps and forecasts for the following two PIs. The teams now have a pre-populated backlog with their PI objectives, iteration plans, and risks: everything they need to kick off with the new PI. 

The inputs and outputs of PI Planning

PI Planning is an essential part of SAFe® because it enables organizations to produce outputs that are crucial for successful Program Increment execution. But before that happens, you need to clearly define a few inputs. Having a set of inputs ready before PI Planning takes place will help you get where you want to go faster.

The first PI Planning input is the business context . It comes in the form of briefings that are the result of the Content Readiness planning preparatory step. The second one is a  roadmap and vision . And third, a set of the highest-priority Features sitting in the ART backlogs.

There are two primary outputs: committed PI objectives and the ART planning board . The PI objectives, apart from being SMART, also come with business values assigned by Business Owners. The ART planning board, on the other hand, indicates new Feature delivery dates, Feature dependencies between the teams, and milestones . 

PI Planning vs. Sprint planning: the top 5 differences

How do PI Planning and Sprint planning compare, and what does it mean for you? If PI is a scaled Sprint, is PI Planning simply Agile planning on steroids? Here’s a breakdown.

The first major difference between planning Sprint and PI is the number of participants. The Sprint planning event is for one Agile team (5 to 10 people). One PI Planning, by contrast, is for the entire Agile Release Train (of 5 to 12 Agile teams, so 50 to 125 people).

#2. Time horizon

Sprint planning takes place every 1 to 4 weeks, depending on Sprint cadence. 

But in PI planning, we look at a much wider planning horizon that can be as short as 8 weeks or as long as 12 weeks . The default duration is 10 weeks, but organizations often go for the 12-week horizon to align with their financial quarter. For example:

•   Q1 PI Planning: December

Organizations that want to stay more Agile choose the 8-week interval.

Because Sprint planning focuses on frequent releases, the time horizon is much shorter, and the scope of planning is less far-reaching. Instead of high-level long-term planning, Sprint planning revolves around selecting and estimating small user stories , the value the individual team is expected to deliver (based on those stories), and deciding on the stories and tasks individual team members will work on.

PI Planning, on the other hand, is a bit like crafting a  high-level roadmap that tells you what goals your organization wants to achieve over the coming 8-12 weeks.

#4. Commitment

With a time horizon that can be as short as 1 week, you can expect a higher degree of focus and commitment. Because the distance between “now” and the goal the team is expected to meet feels closer.

In contrast, even an 8-week plan feels more distant and further “in the future.” And while teams can fully commit to the first Sprint, then the second, it’s challenging to maintain an equal level of commitment for 2 or 3 months.

#5. Event duration

The planning of one Sprint or iteration takes only a few hours (2-4 hours in the case of Sprints in Scrum). For PI Planning, the event takes 2 days (or more for distributed teams).

Does your organization want to implement SAFe? BigPicture can help!

BigPicture makes PI Planning and Execution quick and easy.

The Roadmap feature helps you define and present product plans for the upcoming Program Increment, setting clear targets for your ARTs. On the Roadmap, you can define both PI Objectives and visualize the Iteration Goals which your stakeholders can later view. Based on that, they’ll be able to monitor how teams are performing against objectives throughout the entire PI.

In addition, a Program Board will help you determine backlog items at the PI level. And if you dig into the Iteration level, you’ll be able to carry out more detailed planning.

PI Planning, as daunting as it looks, forms the foundation of SAFe®. If your company wants to make Agile convenient and measurable, PI Planning is the key. It’ll help you achieve your goals and help everyone involved understand company plans and leadership’s vision.

Related posts

The final showdown: iteration vs. increment.

Both iteration and increment are terms bound with the Agile approach. But, as usual, the devil is in the detail. …

5 Leading Scaled Agile frameworks: Comparison

As enterprise-level organizations are adopting Agile methodologies to depart from the traditional command-and-control style, it is important to understand how …

7 best SAFe® books for large-scale implementation

Before your organization starts applying the Scaled Agile Framework® in managing an entire portfolio of projects, there is plenty to …

SAFe® values explained

What values does the Scaled Agile Framework stand for? For those who are only beginning to scale up agilely, a&…

What kind of demo would you like to get?

Watch the demo.

" * " indicates required fields

Enterprise demo

Finding the right management system for a large-scale organization is quite a challenge.

We are here to help! As BigPicture is one of the most flexible PPM tools on the market, we would be thrilled to demo the system with your unique business case and requirements in mind. Let us better understand your needs by filling out the form:

Register for a live demo webinar

Congratulations, get started.

Enterprise Program & Portfolio Management right in monday.com

Try it out now

Request offer

Questionnaire, contact us, contact customer success, contact partner relations.

Sandeep Kashyap

A Step-By-Step Guide to PI Planning (2024)

If you are a business owner like me, I am sure there must have been times when you found that everybody has their own management rituals in the name of “Agile”.

It’s a wild world out there.

During my journey from a software developer to a CEO, I have witnessed Agile going through a significant evolution since its inception.

One such standout is the Scaled Agile Framework (SAFe), a comprehensive and structured methodology designed to tackle the complexities of modern software development head-on. Among SAFe’s key pillars lies the heartbeat of effective execution —PI planning.

Now, I understand that some people have their opinion on SAFe not being agile enough, but that’s a discussion for some other article.

In this article, however, we will decipher PI planning, a vital strategic event that perfectly aligns with the principles of the Agile manifesto .

Check out how these top five software can help you with project planning. 

What is PI Planning?

PI planning, short for Program Increment planning, is a vital planning process in Scale Agile Framework (SAFe) where agile teams conduct a face-to-face meeting event, either virtually or in person, to plan out what they are going to work on in the upcoming Program Increment. 

A Program Increment refers to a set period of time during which a group of agile teams, also known as Agile Release Train (ART),  work collaboratively on delivering the defined value proposition.

You can think of Program Increment as a long-term sprint, where it’s not just your team working on improving website navigation, but the whole ART is working collaboratively on project-level deliverables such as search functionality and overall design consistency, in addition to the improved navigation.

Program Increment planning is a repetitive process that occurs every 8-12 weeks, depending on the length of the PI. ART reviews the previous PI and, if required, adapts to the changes by addressing and re-establishing the dependencies.  

Now, PI planning might seem at odds with the Agile principle of valuing “ Responding to change over following a plan. ” Well, the key here is to strike a balance. While Agile promotes adaptive planning and short iterations, it also values the need for effective coordination and alignment in bigger projects. 

That’s why PI planning falls primarily under the Scaled Agile Framework (SAFe) of software development, where you scale the agile methodologies to incorporate the complexities associated with large-scale projects.

Let’s try to understand what value PI planning adds to SAFe.

Cut the fluff and get to the stuff. Streamline your planning process with these project planning tools in 2024. 

Why do you need PI planning?

Large-scale projects are inherently complex, demanding more than just weekly meetings and retrospectives for effective project management . Such projects require multiple agile teams working together on a common objective, thus necessitating a more comprehensive planning process. 

This is where PI planning comes in. A strategically designed event that ensures complete alignment among all teams within an Agile Release Train (ART) for the upcoming project phase, called program increment.

The essence of PI planning lies in aligning all the agile teams within your ART by setting cross-departmental tasks and team interdependencies. 

In contrast, a lack of well-executed PI planning may cause functional silos to creep in and create a major obstacle to effective execution.

For instance, your design team might work on the user interface independently, while the backend team focuses solely on data integration. As the project progresses, the user interface elements don’t fit well with the data flow, leading to glitches and user experience issues. 

Now, that’s just one situation PI planning helps the ART avoid. Following is the comprehensive list of benefits PI brings to Scaled Agile Framework (SAFe). 

Benefits of well-executed PI planning

• Value stream alignment: SAFe relies heavily on development and business stakeholders working together. PI planning provides a platform for business planners and development teams to find a middle ground for the most effective business growth. It helps to prioritize work, align scopes, and create the most effective product roadmap. 
• Risk mitigation: PI planning involves team members coming from diverse backgrounds, including business, technical, and operational. This mix of talent provides better insights, from both technical and overall business perspectives; subsequently, allowing for better contingency plans. 
• Enhanced visibility: With everyone in the ART having a clear understanding of what they need to do, and how their work may impact the overall progress of the project, ensures a streamlined execution of tasks and flexibility to adapt to dynamic changes. 
• Delivery predictability: As mentioned earlier, business teams rely heavily on development teams to formulate business plans and outcomes under SAFe. PI planning allows development teams and business teams to collaborate and define mutually agreeable and realistic PI objectives. A common method is to design the objectives under SMART criteria . This way, there is less confusion and a better predictability of delivery . 
• Improved collaboration: Collaboration is an essential part of any project’s success. This importance amplifies even more when you are working with diverse teams, not just individuals. PI planning plays an important role in bringing together cross-functional teams. Additionally, a coordinated effort of all stakeholders, including teams, product owners, managers, and other relevant parties, ensure better execution and fewer surprises. 

💡 Read More: How to effectively establish cross-functional collaboration among your teams.

Who should be involved in PI planning?

PI planning is a collaborative process and involves individuals from several departments in an organization. Nonetheless, they are primarily designated under the following roles:

• Release Train Engineer: The Release Train Engineer (RTE) oversees the overall PI planning event. The key responsibilities of the RTE are to guide the participants throughout the event, conduct pre- and post-event meetings, and ensure everything runs smoothly.
• Business owners: A business owner describes the business context to the rest of the participants. 
• Product Owner: Describes the overall product vision and development priorities.
• Product Managers: Describes the feature vision, and prioritizes backlog items. 
• Architects:  System architects and solution architects, offering architectural design insights. 
• Scrum Masters: Scrum masters operate at a team level to facilitate PI planning. They assist RTE and ensure everyone on their team is on the same page.
• Developers: Developers are responsible for estimating the work that needs to be done to deliver the features in the upcoming PI. 

💡 Read More: Project Manager roles and responsibilities .

PI Planning preparation checklist

Program Increment (PI) planning requires planning of its own.  Whether you are a seasoned agile practitioner or just starting out, here’s a handy checklist to guide you through the “planning” for a PI planning event.

1. Identify Participants

The first step is to assemble the right ART members depending on the scope of your project. This includes assigning roles to participants, such as the Release Train Engineer (RTE) to facilitate the event, business owners to guide business priorities, product managers to present feature vision, system architects to provide architectural insights, etc.

2. Organizational Readiness

Next, RTE needs to ensure that strategic alignment exists among participants and stakeholders. Confirm the scope, priorities, and roles, and validate that agile teams have designated members, Scrum Masters, and Product Owners.

3. Content Readiness

Prepare essential briefings, including an executive-level context briefing, product vision presentations, and architectural insights. These briefings provide a clear understanding of the current state, future goals, and technical direction.

4. Logistics Readiness

If the event is virtual, ensure the technical infrastructure is in place for remote participation. Set up communication tools , audio, video, and collaboration platforms for real-time feedback sharing.

Step-by-step PI planning agenda

PI planning events follow a standard agenda to ensure consistency, alignment, and effective communication among ARTs. Usually, the agenda is planned for two days, which can be tweaked to create a split agenda of 2.5 days to coincide with members located across different time zones.

Day 1: 

1. business context: .

Day 1 kicks off with senior executives and business owners setting up the business context, where they reflect on the current state of business and consumer take on the previous PI. 

2. Product/solution vision:

Product owners and managers present the vision for upcoming features and changes in the previous PI. 

3. Architecture vision and development practices:

System and solution architects discuss the architectural vision and changes teams will adopt in the upcoming PI.

4. Planning context: 

RTE sets the stage and explains the planning process and outcomes.

5. Team breakout #1:

The breakout session is for teams to decide on their capacity planning, identify backlogs, identify risks and dependencies, and prepare an initial PI objective.

Team members segregate these objectives into committed and uncommitted objectives based on the risk and uncertainty associated with each one. 

6. Draft Plan review:

During the draft plan review, business owners, stakeholders, and other management review the initial drafts that include the PI objective, capacity & load, risks, and dependencies. 

7. Management review and problem-solving:

The draft plan usually includes some challenges like resource constraints, scopes, and dependencies. Management and team members then negotiate to find a middle ground for aligning the scope with achievable objectives. 

Day 2: 

1. planning adjustments:.

Day 2 begins with management adjusting the planning scope, people, and resources. 

2. Team breakouts #2:

The team continues to plan and present business owners with adjusted PI objectives, to which business owners assign business values as prioritization scores. 

3. Final Plan and Review:

During this session, all teams present their final plan, with all the potential risks and impediments, to the group. If all the business owners agree to the final plan, the PI objectives are shared with everyone.  

4. ART PI risk evaluation:

All the identified risks and impediments in the previous session are evaluated by the ARTs under the ROAM framework .

• Resolved: Teams agree that risk is no longer a concern.
• Owned: The risk can’t be resolved during PI planning, so one of the team takes ownership to eliminate the risk later.
• Accepted: The risk must be accepted as it is since there is no workaround.
• Mitigated: Teams identify a workaround plan for risk.

5. Confidence vote

A confidence vote ceremony is conducted to make sure that attendees are in alignment with PI objectives and that they agree that the plan is achievable. Attendees cast votes with the show of fingers, or digital counters if the PI planning event is online. If the average count is above three, the plan is green-flagged for a go. If not, the plan is reworked. 

6. Plan rework

The plans with low confidence are reworked until agreed upon by everyone.

7. Planning retrospective and moving forward

Finally, the RTE runs a retrospective where they reflect on what went well during the PI planning event, what didn’t, and what could be done better. 

8. Post-PI planning events

After the planning event, RTE and other ART stakeholders write down and communicate the PI objectives with other team members in the ART. The product management breaks down and distributes the tasks among the team members and prepares a roadmap outline for individual teams. Additionally, teams also decide on the timeframe for Innovation and Planning (IP) iteration during the next PI. 

Navigating the PI Planning challenges: Common pitfalls

PI planning is an extensive event with a tightly packed schedule for many things to include. Surely, things are not going to go exactly as planned. Nonetheless, here are some pitfalls that are completely avoidable with a little effort. 

1. Lack of planning

PI planning requires planning. Though the event unfolds according to a standard agenda every time, neglecting to map out the event structure, and role allocation, and providing necessary briefings to the attendees can cause serious disarray and confusion during the event. 

2. Lack of prioritization in your agenda

Since all the individual events in your PI planning are time-boxed, it is important to prioritize the time allocation accordingly. For instance, allocating too much time for events that do not directly contribute to the PI objectives, risk identification, or plan refinement, may force you to make hasty decisions in the planning process. 

3. Running long-boring sessions

You don’t want a PI planning event to be a long presentation given by leaders, just to be preached by the teams. Given the time constraints, it is important for your agenda items to be short and straightforward, leaving more room for actual planning. Additionally, every session should be engaging to keep the participants invested and bring the best out of each other. 

4. Missing out on retrospective insights

Neglecting the insights from previous PI can lead to repeated mistakes and stagnation. Retrospectives are the goldmines for teams to make well-informed decisions. It becomes easier for teams to identify the areas where they are overcommitting or underperforming based on historical data. Encouraging team members to talk about what worked and what didn’t provides you with tested and proven information that you can integrate into your planning process for better results. 

5. Ignoring technical debt

Technical debt refers to the accumulated cost of undone development work, shortcuts, code patches, and other suboptimal coding practices that compromises the quality of your product. Failing to address these issues in the PI planning process can cost teams the flexibility to adapt to new changes quickly. By deliberately addressing these issues head-on in the PI planning process, teams can allocate time for cleanup and mitigation. 

💡Read More: 10 most common Project management challenges (and solutions)

PI Planning vs. Sprint Planning: What is the difference?

PI planning and sprint planning are both planning processes that agile teams rely on to get things done. Nonetheless, they are quite different in terms of scale and context. 

Sprint planning is done by development teams to map out the task they need to complete within the next sprint, a time-boxed period usually lasting 1-4 weeks. 

PI planning entails planning objectives, for the next program increment, a project phase that usually lasts 8-12 weeks. 

Sprint planning involves selecting an item from the product backlog, estimating the effort required, and creating a plan to deliver that item within a sprint.

PI planning has a more comprehensive scope than sprint planning. It includes defining objectives for the next program increment, evaluating the risks associated, and establishing cross-departmental dependencies for streamlining the progress. 

The primary objective of sprint planning is effective workload distribution and resource allocation for the on-time delivery of the user story. 

PI planning involves a more holistic approach to overall business growth. The primary objective of PI planning is to align the scope of all the teams in the ART with business objectives. This requires input from several participants, such as business owners, product owners, development teams, etc. 

Streamline PI planning process with ProofHub

A project management and team collaboration tool resides at the heart of a PI planning event. In today’s dynamic landscape of teams distributed around the globe, having a centralized platform that seamlessly brings everyone together is a must. 

This is where ProofHub comes in. With an array of diverse features , ProofHub is not just a project management and team collaboration tool for agile teams, but also a strategic asset for orchestrating effective planning events. 

1. Seamless collaboration

PI planning is all about effective communication and collaboration. Teams in the ART need to collaborate, share insights, align their goals, and plan objectives cohesively. With ProofHub , this key aspect is taken care of with an array of features that enable real-time discussions and document sharing, ensuring that every team member is on the same page.

From refining user stories to identifying dependencies, ProofHub’s collaboration capabilities facilitate the seamless flow of information, even when the team members are located miles apart.

2. Centralized planning and visibility

PI planning events are always short of time. Juggling spreadsheets, emails, and numerous tools is not the most effective way to manage your PI planning event. 

ProofHub provides everything you need under one roof. The centralized platform allows you to create and manage user stories, prioritize tasks , and assign responsibilities.

This level of consolidation not only saves time but also provides unparalleled visibility into the planning process. Stakeholders can quickly access timelines, progress charts, and updates, eliminating confusion and ensuring everyone remains aligned with the end business objectives.

3. Risk Mitigation

With ProofHub , you can monitor the progress of events, identify potential delays, and make necessary adjustments on the go. Moreover, ProofHub facilitates risk evaluation and contingency planning through its intuitive interface. You can assess potential bottlenecks with Gantt charts , evaluate risks associated with dependencies by highlighting the critical path, and devise contingency plans to mitigate potential disruptions. 

This comprehensive approach to risk management ensures that your PI planning remains flexible.

The best tool for everything from planning to delivery.

PI (Program Increment) planning is not just an event where business leaders gather to hash out a schedule for the upcoming development cycle. It’s a dynamic and strategic process that serves as the heartbeat of an Agile organization. 

This event manifests the essence of Agile principles, fostering an environment of open communication, transparency, and collective ownership. It’s a time to connect the dots between the overarching business goals and the tangible work that teams will undertake.

Unwind the full potential of your agile teams with the 20 best agile project management tools.  

FAQs about PI planning

Is pi planning a match for scrum.

PI planning involves teams coming from diverse departments, whereas scrum is a framework for software development under agile methodology. While technically you can have a two-day planning event for developing the next feature, it does not seem the most effective way to go about it. Sprint planning is beneficial when it comes to Scrum while PI planning is suitable for Scaled Agile Framework.

Who is responsible for PI planning?

Program Increment (PI) planning is a collaborative effort of agile teams to ensure the successful delivery of customer values in the next Program Increment. The key roles involved in PI planning include the Release Train Engineer (RTE), Product owners and managers, Scrum Master, System Architects, and other stakeholders.

How long is PI planning in Agile?

PI planning is usually a two-day-long planning event, which can be extended to incorporate the remote teams located in different time zones.

How do I prepare for PI planning?

The pre-planning phase of PI planning primarily includes four readiness aspects: identifying participants, organizational readiness, content readiness, and logistic readiness. First, identify the participants and assign the roles accordingly. 

Next, Product owners ensure that their team’s backlog is refined with well-defined user stories and acceptance criteria. Collaborate with Product Managers to clarify objectives and align priorities. Furthermore, if your organization is hosting an online PI planning event, make sure that teams are equipped with the necessary tools.

Who organizes PI planning?

PI planning is typically organized by the Release Train Engineer (RTE), who is responsible for coordinating and facilitating the PI planning event. They work closely with Product Management, Scrum Masters, Agile teams, and other stakeholders to ensure that the planning process is smooth, well-structured, and aligned with the organization’s goals. The RTE sets the agenda, schedules the event, and guides the participants through the various activities during the planning session.

What are the inputs and outputs of PI planning?

PI planning involves several inputs and outputs that contribute to the successful alignment of agile teams across the ART. 

• Business context
• Product and architecture vision
• Capacity and velocity
• Customer insights
• PI objectives
• Comprehensive risk evaluation
• Dependencies

What tool is used for PI planning?

Tools that are essential for PI planning are:

• A whiteboard tool, like Microsoft Whiteboard, for creating a collaborative program board. 
• A project management and team collaboration tool, like ProofHub, for documenting processes, file sharing, real-time communication, and contingency planning. 
• A video conferencing tool, like Zoom or Google Meet, for facilitating face-to-face communication.

What is the role of PI planning?

Program Increment planning plays an important role in the Scaled Agile Framework of software development. It provides a platform for the alignment of all the agile teams in the ART with overall business objectives. Additionally, it helps with mapping out and establishing dependencies for streamlined development in the next PI.

• Share on LinkedIn
• Email this Page
• Share on Facebook
• Share on WhatsApp

Try ProofHub, our powerful project management and team collaboration software, for free !

 No per user fee.    No credit card required.    Cancel anytime.

A Program Increment ( PI ) starts with a time-boxed PI Planning  event in which the Agile Release Train is responsible for planning & delivering incremental value in the form of working, tested software and systems. This is a two-day event where all stakeholders (including Agile/Scrum Teams) on the Agile Release Train (ART) participate in a collocated event. All teams have their own areas set up for their planning together with a Program Area with a Program Board to map Feature delivery and dependencies across teams. PI is usually 8 – 12 weeks long. A well-executed PI Planning session ensures alignment, transparency, and collaboration across teams, setting the stage for a successful Program Increment.

Purpose : The purpose of PI Planning is to create an emergent roadmap to deliver a prioritized and agreed set of outcomes as well as identify both known and potential impediments to progress. The goal is to align business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.

• Aligning Teams: Ensuring that all Agile Release Trains (ARTs) understand the priorities, objectives, and dependencies for the upcoming PI.
• Building Plans: Collaboratively creating plans for the PI, including defining objectives, estimating work, and identifying cross-team dependencies.
• Enhancing Collaboration: Fostering communication and collaboration among teams, stakeholders, and product owners to ensure a shared understanding of goals.

Goals: The primary purpose of release (PI) planning is to gain alignment between business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.

Features : Have clear, simple, well-written business-oriented and valuable features rather than Features describing a technical solution.

PI Planning Inputs (Pre-Work)

• Product backlog features are prioritized & ranked.
• Business review of each feature completed
• Technical analysis done, feasibility established, architecture and solution understood,  enabler  features identified.
• Features ranked (for example using WSJF ) – single common stack for the entire program
• Features sufficiently defined to support release planning and estimation.

PI Planning Process Steps

• Mapping: Features elaborated into user stories
• Sizing: Stories estimated (to +/- 20%) via bulk estimation
• Scheduling: Initial allocation of stories to sprints, taking into account team velocities and dependencies.
• Feature delivery dates determined (to nearest sprint)
• Release scope set based on velocity and target release date.
• Consolidated release plan showing feature completion dates.

PI Planning Outputs

• Release scope defined for next time-box
• The team better comprehends the objectives for the whole PI.
• A shared understanding of what it takes to release
• Program risks reviewed and actions identified to solidify the plan
• Release objectives reviewed and scored by business stakeholders
• Team and program confidence vote on the plan
• Collective ownership of the plan

Day 1: Creating Draft Plans

Business Context : This is an update given by upper management or a business on how the business is doing and how well they are keeping up with the market and consumer needs.

Vision : This is the overall business vision and objectives, but also the vision for the upcoming PI. At the beginning of PI Planning, the vision will be presented by Product Management or a senior business sponsor for the Agile Release Train.

Architectural Runway: Understanding the architectural implications of upcoming Features is important to ensure that the teams have an understanding of the underlying architectural approach and system constraints that they have to work within. Systems Architect or IT department will outline the systems and architecture vision for improvements to the infrastructure that will help to improve the time to market and may impact development during the coming PI.

Planning Context & Lunch : The Release Train Engineer (RTE) outlines how the PI planning process will work and what is expected from the teams and the overall meeting.

Team Breakouts : Teams will gather around the boards to estimate their velocity for each iteration and look over their backlogs and what will need to be brought forward to support the features outlined in the vision.

Draft Plan Review : This is a time-boxed meeting where the teams present their draft plans so that business owners, product owners, stakeholders, and other teams can give feedback.

Management Review and Problem-Solving: In most cases, the draft plans will bring up issues with architecture, scope, and people and resource constraints. These issues can sometimes only be solved by management renegotiating scope and possible features.

The program Backlog should be sufficiently refined to support story writing and sizing. Each team will first create draft plans & these plans include 3 basic things: a feature delivery timeline, a set of PI Objectives, and a risk assessment.

Create Stories from Features: Known as Story Mapping – taking a set of features and breaking each one down into small slices of functionality that can be delivered in a single iteration. At this stage, it is not necessary to refine the story to the extent that it will meet the definition of ready. This refinement can be done as part of the backlog refinement process.

• Capture the end-to-end user process flow.  Consider these as functional steps or ‘features’.
• Start defining potential actions the user will take to accomplish each function. These can be considered the ‘user stories’.
• Create the “ MVP ”.
• The classic INVEST (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable) , DEEP , and 3C’s (Card, Conversation, and Confirmation) techniques apply as much, if not more, to Features than they do to User Stories.

Story Size Estimates: estimation by linear affinity. This method is good for generating initial estimates for large Product Backlogs, e.g. for PI Planning. Stories not necessarily fully defined ( Ready ). Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended)

• Planning Poker – Agile Estimation Method
• Bucket System – Agile Estimation Method
• Affinity Estimation – Agile Estimation Method
• Dot Voting – Agile Estimation Method
• White Elephant Sizing – Agile Estimation Method

Story & Feature Scheduling : In this step allocate stories to sprints by taking into account story size (in points) and team velocity (points per iteration).

Identify Risks and Dependencies: Dependencies constitute a risk in that they represent items the team has no direct control.

Align Team Deliverables with Program Objectives : It gives teams the opportunity to validate with stakeholders that they have clearly understood the intent and priorities defined for the PI in terms of business value.

• This step is about assigning overall business value to the PI.
• The intent of this exercise is to summarize the PI in terms of meaningful business objectives and to confirm alignment between teams and stakeholders. Features deliver benefits that are aligned with business goals.
• PI objectives should be SMART : Specific, Measurable, Achievable, Realistic, and Time-Bound.
• Business stakeholders circulate and score the team’s objectives, assigning a ‘business value’ between 0-10, where 10 represents the highest business value. Each team starts with their most valuable PI Objective as a ’10’, then all remaining PI Objectives are scored relative to that first 10. BV can be scored as relative within the team, or relative to the overall train.
• At the next PI planning event, following the PI demos, business stakeholders will rate objectives based on what was actually achieved – this data is the basis of the Program Predictability Metric. (Pass out a printed list of PI objectives with original rankings to the stakeholders with an additional column for actuals).

Leadership review & problem-solving: The leadership team will work on the following questions:

• What have we learned so far?
• Where do we need to adjust: Vision, Scope, People?
• Where are the bottlenecks?
• What features must be de-scoped, or deferred?
• Are decisions needed before tomorrow?

Day 2: Make Adjustments and Finalize Plans

The leadership team will announce any required changes to feature priorities and team changes.

The overall agenda for the day will look like this:

• Program adjustments from leadership review – priorities, scope changes, people movements.
• Teams adjust & finalize plans
• Stretch objectives setting
• Teams identify remaining issues needing help from an outside team
• Business stakeholders circulate to review plans and score PI Objectives
• Team-level confidence votes.
• Program wall-board: Feature delivery timelines by the team.
• The team plans collected to the front of the room, risks ROAM’ed , program confidence vote.
• Event retrospective.

Program Adjustments – The day begins with any adjustments or decisions made by management and stakeholders in the problem-solving meeting.

Team Breakouts 2 – Plan Adjustments to incorporate changes in priorities, scope, and people moves into their plans. This will include any scope changes and feature delivery timelines, updating the team’s list of risks, and potentially revising the team’s list of program objectives. Identify any ‘stretch objectives’ and add them to their list of program objectives.

Scoring PI Objectives – Business value is assigned to each objective (scored 1-10). Formulate objectives by thinking about the problems being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic ‘value statement’ and from there back to at least one of the strategic themes identified for the business .

ROAM’ing exercise on their list of risks

• R: Resolved . The team has resolved (or knows how to resolve) the risk.
• O: Owned . The teams decide to ‘own’ the risk, that is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.
• A: Accepted : The team accepts the risk as something that is ‘part of life’, or part of the cost of doing business.
• M: Mitigated : The team believes they can take specific actions to reduce the impact of the risk.

Program Wall Board Update

The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of feature completion dates, enabler items, dependencies, and major program milestones.

Program Confidence Vote

It is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially reworked until all team members vote at least a 3.

PI Planning Event Retrospective

It can be as simple as a 2-column table drawn on a whiteboard or flip-chart with a column for ‘what went well’ and another for ‘needs improving’. A Dot Voting exercise can be done to identify the issues most important to the gathered teams.

Benefits of PI Planning

• Establishing face-to-face communication among all team members and stakeholders
• Building the social network the ART depends upon
• Aligning development to business goals with the business context, Vision, and  Team and Program PI objectives
• Identifying dependencies and fostering cross-team and cross-ART collaboration
• Providing the opportunity for “just the right amount” of architecture and  Lean User Experience (UX) guidance
• Matching demand to capacity, eliminating excess Work in Process (WIP)
• Fast decision making

Best Practices for PI Planning

Here are some best practices for PI planning:

• Involve the entire team: PI planning should involve the entire agile team, including product owners, scrum masters, developers, testers, and any other stakeholders involved in the development process. This helps to ensure that everyone is on the same page and that all perspectives are taken into account.
• Set clear goals and priorities: It is important to set clear goals and priorities for the upcoming program increment. This helps to ensure that everyone is working towards the same objectives and that the most important work is prioritized.
• Use a visual planning tool: Using a visual planning tool, such as a Kanban board or Gantt chart, can help to make the planning process more efficient and effective. It provides a clear picture of the work to be done and helps to identify dependencies and potential issues.
• Break down work into small, manageable pieces: Breaking down the work into small, manageable pieces, such as user stories, helps to make it more manageable and easier to estimate. It also allows for more frequent feedback and course corrections.
• Estimate effort and capacity realistically: It is important to estimate the effort required to complete each item realistically and to take into account the team’s capacity to complete the work within the timeframe of the program increment.
• Plan for contingencies: It is important to plan for contingencies, such as unforeseen issues or delays, to ensure that the team is able to stay on track and meet its goals.
• Establish clear communication channels: Clear communication channels should be established to keep everyone informed throughout the increment. This includes regular check-ins, progress reports, and open communication channels for addressing issues or concerns.
• Keep the planning session focused: PI planning can be a long process, so it is important to keep the team focused and avoid distractions. This can be achieved by setting clear objectives, managing the agenda, and encouraging active participation from all team members.
• Align with the organization’s strategy: The goals and priorities set during PI planning should align with the organization’s overall strategy and objectives. This helps to ensure that the work being done is driving the organization toward its larger goals.
• Plan for learning and improvement: PI planning should include a focus on learning and improvement. This can be achieved by setting goals for experimentation, incorporating feedback from customers or users, and regularly reflecting on the team’s performance and processes.
• Involve stakeholders: PI planning should involve key stakeholders, such as customers or users, to ensure that their needs are taken into account during the planning process. This can help to improve the quality of the work being done and increase stakeholder satisfaction.
• Continuously refine the plan: The plan created during PI planning should not be set in stone. It should be continuously refined and adjusted based on new information or feedback from the team or stakeholders. This helps to ensure that the team is always working towards the most important objectives and that they are able to adapt to changing circumstances.

Frequently Asked Questions

Who are the participants of pi planning.

All the teams of the Agile Release Train, Scrum Masters, Product Owners, Developers, Stakeholders, Business owners, Suppliers, Users, & Customers.

Who conducts the PI Planning session?

The Release Train Engineer (RTE) is at the front of facilitating the PI Planning session and ensures that a seamless and smooth PI session is done.

What are the Challenges of PI Planning?

PI Planning does have its huge benefits but at the same time, it can have some challenges. Some of them are listed below:

• Complexity: PI Planning involves coordinating multiple teams within an ART, each with its own objectives, dependencies, and priorities. This complexity can make it challenging to develop a cohesive plan that meets everyone’s needs.
• Time Constraints: PI Planning is a time-boxed event, typically lasting two days. This compressed timeframe can make it difficult to discuss and plan for all the work that needs to be done.
• Communication: Effective communication is essential during PI Planning, but it can be challenging to ensure that everyone is on the same page, especially when dealing with a large number of people and complex dependencies.
• Resistance to Change: Some team members may be resistant to change, which can create friction during the planning process and impede progress.
• Lack of Prioritization: Without clear prioritization, teams may struggle to focus on the most critical work during PI Planning, leading to inefficiencies and delays.
• Dependencies: Identifying and managing dependencies between different teams and features can be challenging and time-consuming, especially when there are many interdependencies to consider.

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

A PI Roadmap provides an overview of the Program Increment, which typically lasts for ten weeks. It outlines the objectives, milestones, and deliverables for each team within the ART (Agile Release Train) for the upcoming PI. The PI Roadmap is developed during PI Planning and provides a high-level view of the work that will be completed during the PI.

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)

On the other hand, a Solution Roadmap provides a long-term view of the solution, typically covering 12-24 months or more. It outlines the overarching goals and objectives for the solution, including the features, enablers, and capabilities that will be delivered over time. The Solution Roadmap is developed during the Solution Management process, which is responsible for defining and managing the solution vision, roadmap, and backlog.

In summary, a PI Roadmap focuses on the upcoming PI and provides a detailed plan for the next 10 weeks, while a Solution Roadmap focuses on the long-term vision of the solution and outlines the features and capabilities that will be delivered over a more extended period.

What is Post PI Planning?

Post-PI Planning takes place subsequent to the completion of PI Planning by all the ARTs for the following increment. During this stage, the teams present their plans, clarify their aims, and communicate important milestones and anticipated schedules. Post-PI Planning session ensures that you have a finalized set of PI Objectives that have to be implemented, and all the expected dates and milestones for delivering the final increment. These are mapped onto a physical or a Digital Solution Board.

The Release Train Engineer explains and discusses the objectives, dependencies, impediments, and risks of the PI. Risks are identified and mitigated, using the ROAM technique. If there are any aspects of the planning session that are left or not clearly understood, then a Rework Session is held to review the plan with the Agile Release Train.

Similar to PI Planning events, Post-PI Planning employs a planning board. However, instead of features, it lists capabilities, dependencies, and milestones for each iteration and ART. Any possible issues and risks are recognized, deliberated, and addressed by either taking ownership, resolving them, accepting them, or minimizing their impact. Plans undergo a first-of-five vote of confidence to ensure they align with the solution’s objectives, much like regular PI Planning events. The plans are reworked until the attendees’ average confidence level is three fingers or more.

Benefits of Post-PI Planning

• Aligns the Team: Post-PI Planning is an opportunity for the entire team to come together and review the progress made in the previous Program Increment, discuss any challenges faced, and align themselves with the upcoming goals and objectives. It ensures that everyone is on the same page and working towards the same goal.
• Identifies Dependencies: During Post PI Planning, teams identify dependencies between different features, systems, and teams. This helps them to coordinate their efforts better and ensures that all the necessary components are developed in time for integration.
• Promotes Transparency : Post-PI Planning promotes transparency and accountability within the team. It encourages open communication and helps to identify any issues or concerns early on, which can then be addressed promptly.
• Enhances Predictability : Post-PI Planning helps to enhance predictability in the project by providing a clear plan of action for the upcoming Program Increment. This allows the team to prioritize their work and focus on delivering the most critical features first.
• Facilitates Continuous Improvement: Post-PI Planning is an opportunity for the team to reflect on the previous Program Increment and identify areas for improvement. This helps them to continuously improve their processes, tools, and techniques and ensures that they are delivering value to the customer.

Executing a successful PI Planning event is pivotal for organizations following the SAFe framework. By following these steps and incorporating the provided tips and tricks, teams can navigate the complexities of PI Planning with confidence. This comprehensive guide aims to equip Agile Release Trains and teams with the knowledge needed to achieve alignment, collaboration, and success in their Program Increments.

Trending Now

• Corporate Training

During the PI Planning event, when are planning adjustments agreed upon?

• June 26, 2020

Mangesh Shahi

Table of Contents

A. During the draft plan review

B. During Scrum of scrums

C. During the management review and problem-solving

D. During breakout sessions

The Correct Answer is

Explanation.

During the PI (Program Increment) Planning event in the Scaled Agile Framework (SAFe), planning adjustments are typically agreed upon during the management review and problem-solving session. This part of the PI Planning process is crucial for finalizing plans that will guide the work of Agile Release Trains (ARTs) over the next Program Increment.

How It Works

• Draft Plan Review : Initially, teams present their draft plans, including objectives and potential risks. This phase is more about sharing initial thoughts and receiving feedback from other teams and stakeholders.
• Breakout Sessions : Teams work in breakout sessions to refine their plans based on the feedback received during the draft plan review. These sessions are iterative, allowing teams to adjust their strategies, dependencies, and objectives in smaller groups.
• Management Review and Problem-Solving : After teams have refined their plans during breakout sessions, there is a management review. During this stage, key stakeholders, including product management, system architects, and Agile Release Train Engineers (RTEs), review the plans. This is a critical phase where impediments and risks are discussed, and adjustments to the plans are made to resolve issues. The goal is to ensure that the plans are realistic, achievable, and aligned with the broader organizational goals.
• Scrum of Scrums : While Scrum of Scrums is a part of the coordination process in SAFe, especially useful for addressing and resolving dependencies and impediments across teams, it is not the primary session for agreeing on planning adjustments. It’s more about coordination and problem-solving among teams.

The management review and problem-solving stage is designed to finalize the plans by making necessary adjustments that consider the input from various stakeholders and the realities of the organization’s capabilities and constraints. This ensures that all teams aligned with the ART are ready to commit to their objectives for the upcoming Program Increment, with a clear understanding of how to address any identified issues or risks.

The Management Review and Problem-Solving session during the Program Increment (PI) Planning event in the Scaled Agile Framework (SAFe) is a pivotal point where significant adjustments are made to the plans before final commitment. This session is designed to ensure that the Agile Release Train (ART) is set on a path toward achieving its objectives efficiently and effectively. Let’s delve into the deep details of this session, its objectives, participants, and the process.

Objectives of the Management Review and Problem-Solving Session

• Resolve Impediments : Identify and propose solutions for any impediments that could hinder the teams’ ability to meet their PI objectives.
• Adjust Plans : Make necessary adjustments to the draft plans based on feedback, insights, and the resolution of identified impediments.
• Resource Allocation : Ensure that resources are adequately allocated to address the priorities and risks identified during the planning process.
• Risk Mitigation : Discuss and strategize on mitigating identified risks, ensuring that plans are resilient and flexible.
• Alignment : Confirm that all teams’ plans are aligned with the ART’s overall objectives and the organization’s strategic goals.

Participants

The session involves key stakeholders from various levels of the organization:

• Business Owners and Executives : Provide insight into business priorities and strategic alignment.
• Product Management : Ensures that the plans align with customer needs and product strategy.
• System and Solution Architects/Engineering : Offer technical guidance to ensure that the plans are technically feasible and aligned with the system’s architectural vision.
• Agile Release Train Engineer (RTE) : Facilitates the session, ensuring that discussions are productive and focused on solving problems.
• Team Representatives : Present the teams’ perspectives, challenges, and needs, ensuring that the solutions are workable at the team level.
• Review : The session begins with a review of the draft plans created by the teams during the breakout sessions. This includes going over the objectives, dependencies, and identified risks.
• Identification of Issues : The group identifies any critical impediments, risks, or issues not yet resolved that could impact the ART’s ability to meet its PI objectives.
• Problem-Solving : Through collaborative discussion, the group works on problem-solving, proposing solutions, and making decisions on how to address the identified issues. This may involve reallocating resources, adjusting scope, or developing mitigation strategies for risks.
• Adjustments : Plans are adjusted based on the solutions and decisions made during the problem-solving discussions. This might mean redefining some of the team’s objectives or changing the approach to handling certain features or capabilities.
• Finalization : Once adjustments are made, and solutions are agreed upon, the plans are finalized. This sets the stage for the teams to commit to their PI objectives with a clearer understanding of the path forward and the support mechanisms in place.
• Communication : The outcomes of the session, including any significant plan adjustments and the strategies for addressing key issues, are communicated back to the entire ART. This ensures transparency and alignment as the ART moves into the commitment phase of the PI Planning.

The Management Review and Problem-Solving session is critical not just for the practical aspects of planning and risk management but also for fostering a culture of collaboration, transparency, and shared commitment to success across the ART. It embodies the Lean-Agile principles of decentralized decision-making and cross-functional collaboration, ensuring that the plans are robust, achievable, and aligned with the strategic goals of the organization.

Other Leading SAFe 6.0 Question – At the end of PI Planning, after dependencies are resolved and risks are addressed, a confidence vote is taken. What is the default method used to vote?

Popular Courses

Agile and scrum courses, project management courses, devops courses, it service management (itsm), quality management courses, subscribe us.

• Accreditations

Terms & Policies Conditions

• Terms & Condition
• Privacy Policy
• Refund Policy
• Rescheduling Policy
• Become An Instructor

3500 South DuPont Highway Suite DK 101, Dover, DE 19901, United States

• USA : +1 (832) 924 0564
• INDIA : +91 83417-05065
• UK : +44 807 164 0572
• PMI®, PMP®, PMBOK®, and the PMI Registered Education Provider logo are registered marks of the Project Management Institute. Inc.
• ITIL® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited
• PRINCE2® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited
• The Swirl logoTM is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved
• CSM, A-CSM, CSPO, A-CSPO, and CAL are registered trademarks of Scrum Alliance
• PSM, PSPO, and PAL are registered trademarks of Scrum.org
• Spoclearn is an Accredited Training Provider of EXIN for all their certification courses and exams

© 2022 spoclearn.com

• Agile & Scrum
• Project Management
• Quality Management
• Microsoft Courses
• Data and Analytics
• Development & Testing
• Digital Marketing

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

Distributed PI Planning with SAFe

Bringing everyone on an Agile Release Train (ART) together for PI Planning is a significant effort. While both the Agile manifesto and SAFe highlight the benefits of face-to-face planning, often organizations will 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 such as those being experienced currently with the spread of the Coronavirus. Regardless of the reasons, every organization adopting SAFe will benefit from having a plan in place for effectively conducting PI planning with geographically distributed participants.

This advanced topic article brings together guidance from our own experiences and those of our customers, partners and the SPCT community on how to successfully manage a distributed PI planning. It focuses on the following 6 areas and shares tips within each one:

• Planning Locations: Determining the number of different locations needed.
• PI Planning Agenda: Creating a PI planning agenda to accommodate multiple time zones.
• Facilities: Ensuring the appropriate physical space to conduct the planning.
• Working Agreements: Meeting the needs of the event attendees.
• Tooling: Employing technology to support the different planning activities.
• Facilitation: Executing a successful distributed PI planning event.

Planning Locations

Determining the number of planning locations is an important first step. Two scenarios are possible. Either the individual teams themselves are collocated but distributed from other teams, or individuals on the teams find themselves dispersed across different locations or even working from home. The latter scenario adds another level of coordination and complexity. Organizations should seek to avoid this pattern and bring members of each team to a single location wherever possible.

In the first scenario, where each team is together but distributed from the other teams, efforts should still be made to consolidate the locations. Even something as simple as moving from two offices in two cities to one office in each city can create material benefits without incurring significant travel costs.The focus should be on bringing the teams that will have strong dependencies with one another together at a common location. However, even bringing together multiple teams who may not have much overlapping work, reduces the number of planning locations, lessens the feeling of isolation, and creates the feeling of shared experience for those taking part.

Some organizations with distributed teams have key roles such as Business Owners, Product Management and System Architecture/Engineering in the ‘home’ location with the teams working remotely. Something that we have seen work well is to reverse the direction of travel and send these individuals to the remote locations so they can be with the teams in person. Of course, the locations they attend can, and should be rotated so that each team feels the benefits of having these stakeholders on hand for immediate resolution of questions.

SAFe Tip: The PI planning toolkit, available from the Scaled Agile community site, includes a team roster. Use this to record the locations of the individuals on all the teams and include this in the handouts on day 1 of PI planning. Additionally, include details of the time differences across each location. This will be a critical reference when planning the technical and logistical support needed for the PI planning event.

PI Planning Agenda

Once the locations to be used for PI planning have been determined, the planning agenda can be created. ‘Respect for People and Culture’, one of the pillars of the SAFe House of Lean, reminds us that we should avoid asking the teams to work late into the night. Regardless of whether they are happy to do this, the quality of the plans will suffer if teams become sleep-deprived!!

Instead, we recommend creating a 2.5-day split agenda (further extended to 3 or more days as required) that accommodates a wide span of participating time zones. An extreme example of such an agenda across two locations, Delhi and Los Angeles, with a 12-hour time difference is shown in Figure 1 below. (The PI planning toolkit contains an editable version of this agenda.)

PI Planning Day 1

As can be seen from the example above, the overlaps between time zones are carefully selected to facilitate live interaction at critical points in the agenda. Starting on the morning of day 1, the briefings should be attended remotely by everyone on the ART. Alignment is the goal of PI planning and if the teams are to work independently for a portion of the event this alignment, and the questions that are raised and answered during the briefings to confirm understanding, are critical.

SAFe Tip: If it is not possible to have all the teams attend the briefings at the same time, an alternative is to record and distribute the briefings ahead of time and then use a smaller portion of overlapping time for questions.

The planning process briefing from the RTE is also important in this situation as they will run through the working agreements and agreed upon methods of communication and collaboration (more on this later).

PI Planning Day 2

Important additions to the regular PI planning agenda are the team synchronization points. These are the overlapping times where the teams can work with key stakeholders and collaborate with the other teams who are on different time zones. The duration of these synchronization points should be made as long as possible given the time zone restrictions.

SAFe Tip: Ahead of these synchronization points the teams should consider who they need to work with. They can use an online ‘booking sheet’ document or a calendar to block out time with the individuals and teams that they need to work with.

The draft plan review should also make use of the available overlapping time. This allows adherence to the presentation structure of ‘PI Objectives, capacity and load, and risks’ and ensures the time box is maintained. The management review and problem-solving meeting may also involve individuals from different locations. With a distributed PI Planning event it can be useful to extend the invitations to this meeting to include at least one person who has been working onsite with each team. This could be the Product Owner or Scrum Master if they are in the same location as the team but could also be another team member. This approach makes sure that no information ‘is lost’ due to the distributed nature of the planning.

PI Planning Day 3

The second team synchronization point includes the Business Owners assigning business value to the PI objectives. Again, the use of an online document with pre-determined time slots, around 10 mins each, for the teams to highlight when they want the Business Owners to contact them works well here.

The conclusion of planning, which includes the presentation of the final plans, confidence vote and the risk ROAMing should be done with all the teams present. Often the confidence vote for each team is taken ahead of time and the results communicated by the Scrum Master for that team to reduce the complexity of gathering this information in real-time. The combined ART confidence vote however must be done together once all plans have been shared, with everyone visibly providing a ‘fist of five’ in front of their respective webcams. Of course, at the end of day 2, if the planning is running ahead of schedule, the RTE can adjust the agenda to allow the teams to finish earlier than planned. Commonly the PI planning retrospective is managed as an online activity in the days following the event, so the attendees aren’t kept any later than is necessary.

SAFe Tip: Whatever agenda you arrive at, one thing that must be done is circulate it well in advance of the event. Not only do people need to clear their calendars they will also need to make the necessary arrangements outside of work such as childcare and transportation.

The first consideration here are the breakout rooms. With collocated PI planning the emphasis is on having everyone in the same room. This is usually not feasible when phone or video conferencing conversations need to take place, as the background noise can prevent clear communication between teams. Every location will need several breakout rooms setup and ready to go. A good starting point for the number of rooms required is one breakout room per team plus one or two additional rooms for key stakeholders to utilize and a room for the scrum of scrums. All regular meetings should be cleared from these rooms for the duration of the PI Planning event.

SAFe Tip: Each breakout room should have a pre-prepared ‘contact list’ with the details of the other breakout rooms and who they are for. A set of video conferencing links within an online document makes this process even smoother. Consider also having a permanent computer set up in each room. This reduces the potential problems as people connect and disconnect different laptops during the day.

For those locations that are working late into the night, make sure that the appropriate arrangements have been made so that the lights, air conditioning, power and other facilities will remain on after normal working hours. [Ed. You’d be surprised how often this is not the case!!] Similarly, for those starting earlier in the morning, ensure they can access the offices before a normal working day would have started.

Since many of the team members will be working late into the evening, consider organizing transportation to get them home after the event if the public transport they would normally take is not available or if safety could be a concern. During the event itself make sure that food is provided, particularly for the teams working well into the evenings when other options may be limited.

Facilities and tech support are critical during all PI planning events but even more so when the event is relying so heavily on remote communication channels. Ensure the individuals with these skills are dedicated to the event, with no other commitments during the 2.5 days, and that there is no time when they are not reachable. This may require a group of individuals working in shifts. Have an open messaging channel to these individuals so teams can raise any issues and agree upon a process for escalation if there is a serious blocking issue.

Although tooling will be covered later, it is important to emphasize the need to test the chosen technology ahead of the event. Critically, this test must be done with a representative ‘load’ on the system. A successful test of two people using a system is not reflective of what happens when 100+ people are using it concurrently during PI planning. Instead, run the tests in the previous weeks and enlist the help of employees across the organization to create a suitable load. Backup systems should also be available. Every tool that is used has the chance of failing just at the wrong moment – more often than not when the Business Owners are presenting the business context!!

SAFe Tip: For every tool that is being used, there should be an answer to the question, ‘what is the backup if it fails?’ As an example, if our ALM tool goes down we can use the spreadsheet where we exported the previous day’s data. This is especially critical for systems supporting connectivity between locations.

Working Agreements

Working agreements serve several purposes. They create a set of norms that determine how the teams want to work together to be most productive. They also allow the facilitators to hold attendees to these pre-agreed guidelines, and the teams to hold themselves and each other accountable. And of course, they are refined iteratively – the feedback from a previous event feeds into an improved set of working agreements for the next event.

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. Often events begin with reserved time to formulate these working agreements, but given the scale of this event it is recommended to start with a seeded list (some of the working agreements may require preparation), perhaps then allowing some time for additional items to be added. Figure 2 shows some example working agreements:

The first working agreement in this example is the most critical and often the hardest habit to form. Remember as soon as anyone talks without a microphone, all other participants in other locations will be cut off from the conversation. Other working agreements might include the facilitator repeating each question to ensure the remote sites heard it clearly. Pausing for questions after each presentation and proactively asking the different sites if they have anything they would like to add is highly recommended. Have webcams always turned on so people can see as well as hear each other. And of course, respect the time boxes – given the concessions being made to extend the working day, teams need to have appropriate breaks and start and end at the agreed upon times.

SAFe Tip: Evolve the working agreements iteratively not only from event to event but also within the PI Planning itself. If something is not working or a team requests a new working agreement, add it and communicate it.

Tooling is the cornerstone of distributed PI planning and several different types of tools are required in combination to support the activities that take place. Although the specific choice of tools will vary widely from organization to organization, the different tooling categories are explored below.

1.      Information Storage and Distribution

Throughout the course of the event there will be information that the teams need to access. This could range from the briefing slides from the morning of day 1, to photographs of the program board, to the scrum of scrums information radiator. Agree ahead of time where this information will be stored online and include sub-folders for each team as well as a general all hands folder. This will also support teams sharing information with one another. Make sure everyone in the event has the appropriate permissions to read and write to the agreed locations. Consider an internal intranet or portal site with all of the appropriate links teams will need throughout the event for easy access.

2.      Instant Messaging and Group Chat

Although face-to-face communication via webcams is good for longer conversations, more regular snippets of information need to be continuously passed between teams and individuals to resolve questions quickly as they arise. An instant messaging tool should be employed and preferably one with a group chat functionality. Ahead of the event, groups for each of the teams should be created within the messaging tool along with some additional groups such as a Scrum Masters group, a Product Owners group, a Facilitators group and others. Being able to drop a question into one of these groups increases the likelihood of a swift response.

SAFe Tip: A good addition to the working agreements is that someone in each of these chat groups takes turns continuously monitoring these information channels.

3.      Video Conferencing

Video conferencing will be heavily used during the event. Choose a tool that will meet your requirements for the expected number of concurrent users. As mentioned previously, have a document that everyone can access with pre-prepared links for connecting to the video conference channel for specific breakout rooms. Although normally an electronics-by-exception event, every attendee in the distributed PI planning should have their laptop available if not always on. That way if they receive a notification for a breakout conversation with someone from another team, there is little preparation required.

One additional way of employing video conferencing that we have come across is to ‘point’ the webcam at a source of information, such as a program board, white board, or projection screen. Our experience is that the fidelity of the image is insufficient for this use case. The collaboration tools described below are often better suited in this instance.

Extensively test the video and audio technology in a dress rehearsal with all remote locations well before the event. While individual components may be technically working, other environmental factors may result in a poor participant experience. There is no substitute for real people experiencing the visual, auditory, and ease of use of the total experience to ensure that the technology will support and not detract from the effectiveness of PI Planning. For example, low cost webcams and microphones are often inadequate to create the intended interactive experience.

SAFe Tip: If possible, have two video conference connections setup from the main planning room. One to show the person currently speaking and another showing the event attendees. This ensures that all the teams can see each other.

4.      Collaboration Tools

A set of tools have emerged that support cross team collaboration, many from companies who are Scaled Agile Platform partners. These tools often mimic online whiteboards where the user has complete freedom to create their own templates and design a shared collaborative space. We have observed teams and ARTs using these tools to create team planning boards, capturing PI objectives, ROAMing risks, and documenting the outputs from the scrum of scrums. No team collaboration space should be locked, so other teams can ‘drop in’ in the same way that they would walk past another team’s boards during a co-located event.

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 (more on that shortly). However, we are often seeing collaboration tools also being used 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. Keep in mind that the same rules apply – a conversation is needed before putting something in another team’s swimlane on the program board.

SAFe Tip: Although not as sophisticated, there is still much to be said for simple online documents. At Scaled Agile we have used an online spreadsheet as a way for teams to present their draft and final plans. We found this improved the visibility for remote employees in preference to squinting at flipcharts over a webcam.

5.      Agile Lifecycle Management (ALM) Tools

Regardless of whether the organization is doing distributed PI planning, many employ ALM tools to manage the complexity and scale of their development processes. In addition, these tools are an integral part of their Continuous Delivery Pipeline and connect with other tools in an automated fashion, also providing the required level of traceability.

Many of these tools include some of the collaboration capabilities mentioned previously and are therefore a great addition to a distributed PI planning event. One word of caution: PI planning is focused on developing a high-level plan. When entering data directly into an ALM be mindful of the mandatory fields that you may be required to complete or the different steps to go through in order model different planning scenarios. This additional data entry overhead may distract from the larger intent of the PI planning event. If at all possible, these details should be completed after PI Planning. Finding the right balance is important.

SAFe Tip: While technology brings many benefits, it also adds additional challenges. With everyone face down in their laptops, collaboration can be compromised. Whenever possible have the teams project the information onto a shared screen in their team breakout rooms and take turns to ‘drive’. This simple technique helps to maintain the collaborative nature of planning.

Facilitating the Event

Successful facilitation of a distributed PI planning event takes practice and each event is an opportunity to learn and improve for the next one. However, some common guidelines have emerged that act as a good starting point.

Facilitators at Each Location

The first is to have a named facilitator at each location. In some circumstances each facilitator will be managing large groups of people with multiple presentations taking place from each site. In other situations, it may just be a Scrum Master sitting with the remote team. It could also be a team member if the Scrum Master themselves are remote. The sentiment is clear – the facilitator needs to share the team experience and feel their challenges when an audio line is bad or multiple conversations are making it difficult to understand, for example. When this happens, they can take the appropriate actions to get it resolved.

SAFe Tip: Have a group chat open for the ‘named facilitators’ to quickly escalate the challenges they have identified, or the team have raised with them. This group should be constantly monitoring and communicating with each other.

It is often the case that a ‘home’ location has most of the attendees with a smaller number distributed. If this is the case, 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 main location. While the RTE is supporting the local execution of the event, the others are constantly monitoring the interactions of the remote teams and identifying where they can provide help.

SAFe Tip: One organization we have observed doing distributed PI Planning staffed a support desk at each location. The people at this desk were not part of the ART and so were 100% focused on supporting the teams. Each desk had their own backchannel to their counterparts at each location. When a team at one location for example had difficulty reaching someone at another location, the support team could take that task and work with their counterparts to chase down the right people with the communication request, so the teams could stay as focused as possible on planning the work.

Event Preparation

With the additional complexity that a distributed PI planning brings, some prior alignment around these processes pays off. The RTE should work with the Scrum Masters in the lead up to the event to clarify all the aforementioned activities and do a dry-run of the event, considering some of the different scenarios that might arise and the steps that should be taken to resolve them. The Scrum Masters play a critical role during these distributed PI planning events and need to be completely clear on the process, know how to use the tools effectively and have a good understanding of the locations of every team.

SAFe Tip: Scrum Masters should do their best to stay abreast of the different locations of the teams both at the beginning of planning but also as the teams disperse into their breakout rooms. Tracking down the right people at the right time is one of the biggest challenges with this type of distributed planning. Consider including phone numbers and email addresses in the ART and team rosters when possible to help alleviate this difficulty.

Although bringing everyone together delivers great benefits, not only just in terms of the plans that are created, but also in creating and deepening relationships, the reality today is that many organizations have ARTs that include teams distributed around the globe. Many organizations have demonstrated that these same benefits can be achieved with some prior preparation and additional considerations. Indeed, continually adapting and improving our systems of work is an ongoing endeavor that we are all committed to. This article has summarized some of these success patterns that have employed to great effect.

We would like to thank our customers, partners and SPCT community for continuing to share their ideas and experiences on distributed PI planning. As new patterns and recommendations emerge, we will continue to add them to this article. In the meantime, you can continue the discussion on distributed PI planning in the online SAFe community forums. 

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.