5 Steps to Lay the Tracks for Your Agile Release Train

Scrum teams create release plans to support successful product releases. This helps them maintain their focus on the product vision and feature deliverables.

Here, we’ll explore the definition and purpose of agile release planning and its essential template elements.

Find out what goes into creating a planning meeting and how to set your Scrum team up for successful product releases.

What is agile release planning?

Because software projects are unpredictable, release planning helps team members prioritize their workflow. A release plan focuses on getting specific product features ready for the market. It should examine the product scope, the release date for feature completion, and the resources needed for each release.

The development team then looks at the feedback from earlier product iterations to guide their planning. Product owners and Scrum teams get together to discuss the agile release plan. That’s because team members need to understand what level of product functionality must go into their work. They also need to understand work effort to plan their deadlines for each product increment.

Instead of planning for a significant product release, team members divide the project scope into short sprints or iterations. Many Scrum teams use Jira software to help them plan their sprints, as it helps everyone see the project status at any time.

Creating a prioritization list ensures that team members focus on the most vital product versions the Scrum product owner prioritizes.

What is the purpose of the release plan?

Project release planning helps software development teams plan, direct, and release each project in increments to serve the customer experience. Teams often use this methodology for short sprints of product development.

Release planning provides agile and Scrum teams with a solid direction to complete their projects. Team members also use this opportunity to use sprint feedback to create increments that align with the next release’s project roadmap.

Getting the product plan together

Release planning seems complex, but with some foresight, it can be simple. Let’s review each part of the process.

1. Who leads the release plan?

Typically, the product development team takes its lead from the Scrum master or the product owner. During the meeting, this leader will raise questions about the product backlog to ensure that sprint discussions align with the final product.

All the product stakeholders should participate in the release plan to ensure their feedback is taken into consideration. Without input from everyone involved in the product development, the team risks missing out on vital information to keep the product roadmap on track.

2. Agile release plan aspects

While the release plan is meant to be agile, it also follows a strict process to ensure that teams keep the product roadmap in sight.

Agile teams take all the sprint planning discussions and evaluate these to detail new product deliverables. Although most organizations will use various approaches in their release planning process, each sprint review should include the following aspects:

• The agreed product development releases at each stage of the sprint
• A direction for each new product release
• Specific current and future iterations due in each upcoming release
• What features and functionality should accompany the iteration
• Specific task requirements for each feature delivery to meet the release goal

By going through an in-depth release planning process, software development teams harness the value of these sprint meetings. The ability to rapidly change direction as necessary ensures the team releases the best possible product.

This constant iteration in each sprint review is also valuable in the dynamic environment of product development.

This level of planning, combined with an iterative schedule to account for the dynamic nature of software, is what makes Agile product development so valuable.

3. Sprint meeting discussions

Sprint meeting discussions revolve around user stories, product backlog, and product backlog items. Scrum release planning also considers other issues such as dependencies and product functionality. Other aspects that the team speaks about involve the next release and the number of sprints they must complete and deliver.

Essentially, team members must keep the product vision in mind for effective release planning. This vision helps team members isolate minimum market sprint feature batches and their release dates.

Sprint meeting discussions should include:

• Release plan prioritization of impending new product features and functionality
• Evaluation and inclusion of stakeholder feedback for each sprint
• Detailed descriptions of sprint deliverables and whether these fall into the category of product short-term increments or major longer-term releases
• Which product version will be ready for release and the ideal sequence of product releases to achieve each release goal

Development teams build several product versions. After creating these versions, they prioritize them to release the most important ones to users.

Part of the purpose of release planning is to ensure that all stakeholders are on the same product development page. Another element of these sprint planning meetings is to drive ownership and acceptance of the product vision.

Development of the release plan

There are four steps that software development teams follow to create their product plan.

1. Creating the vision

First, you need to define the vision for the product. Creating a clear vision produces a roadmap for the team to follow in each consecutive sprint. This vision should align with market demand and the product owner’s goals.

It also encourages team members to sift through which features they should prioritize. Similarly, the product roadmap helps teams evaluate the resources they need during the sprint review. Product planning also enables teams to be flexible. Planning reviews ensure direction changes to accommodate ongoing increments to achieve overall release goals.

2. Prioritization of the product backlog

After defining the vision, team members focus on prioritizing features in the product backlog. Here, stakeholder inputs must align with the vision to successfully implement user stories. User stories are vital to the process as they provide the background for detailing product features or functionality.

The product manager provides the team with direction at this stage to outline a viable release plan. This release plan must include the product release goals, release dates, and prioritization of user stories.

3. Set the Scrum planning meeting

The next step in the planning meeting is for the stakeholders to review the plan. Team members now have the chance to adjust deliverables in line with the vision.

Everyone must agree to the release plan at this stage before they can move forward to the next release.

Meeting agenda

Setting up a meeting agenda helps manage the release plan. The essential elements of the agenda for the Scrum framework include:

1. Product plan assessment

The Scrum team reviews the product roadmap to ensure that everyone accepts the product vision and goals.

2. Architecture evaluation

With each release, the Scrum team and product owner evaluate the previous sprint’s architecture. They examine the technical details of the product development and discuss any potential problems that can impact the product release.

Scrum teams go over the scope and estimates of their release plan. Team members determine whether their planning includes the risk of technical debt and if they can complete certain task aspects, such as documenting their work to meet deadlines. Stakeholders also review dependencies that can influence the product versions’ functionality.

3. Velocity and iteration assessment

Scrum teams go over previous iterations to review their velocity estimates. They align their estimates with the suggested iteration schedule to ensure they cover all vital elements.

The product manager controls this assessment to ensure points are assigned to user stories. Assessing user stories and assigning points demonstrate the level of effort the team must invest in each iteration. The total number of story points then represents the estimation of release dates for each sprint release.

An iteration schedule is built by the agile team to determine their velocity for the current and subsequent sprints during this assessment.

The team creates the release scope, which includes all the necessary releases. The Scrum master assigns work to each team member, and all the stakeholders agree to the plan before moving to the next step.

4. Agreement on the definition of done

The team members must now discuss what will qualify as the definition of done for each feature release. Team members must consider whether their evaluation of user stories meets all the product owner's acceptance criteria for release. Once they can prove the acceptance criteria are met in their assessment, they will know that a release completion is valid.

The definition of done must confirm that team members have completed all their assigned tasks for the user story. Team members must also record each task so that the product owner can assess their work.

5. Populate the product release schedule

The project manager can now populate and complete the release plan schedule. All stakeholders should be able to access the calendar to track progress. This release plan schedule helps everyone stay focused on product deliverables and release dates.

Get help with your release planning

Agile release planning is a vital part of the software development team’s success. Create a comprehensive agile release plan for minor or major releases, and you make your life simpler for an upcoming release.

Focus on the release plan calendar helps keep product owners and team members aware of the overall product vision.

Most Scrum teams can use a little help in creating their release plans. At Easy Agile, we offer Jira software that helps Scrum teams execute their release plans to perfection.

Easy Agile TeamRhythm supports collaborative release planning in Jira. The highly-visual story map format transforms the flat Jira backlog into a meaningful picture of work, making it easier to manage your backlog and plan your release.

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…

What is PI Planning?

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

Why do PI Planning?

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

• Communication
• Visibility
• 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?

1. When you’re touching a system or a code repository, you need to know how it’s going to impact another team
2. 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.

What is the goal of PI Planning?

PI Planning is an essential part of the Scaled Agile Framework, a framework that’s designed to bring agile to large companies with multiple teams.

SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize, collaborate, and align on workflows, objectives, releases, and more.

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.

What should be included in the PI Planning agenda?

Here’s a standard PI Planning agenda template:

Day 1 AgendaDay 2 Agenda8:00 - 9:00 | Business Context8:00 - 9:00 | Planning Adjustments9:00 - 10:30 | Product/Solution Vision9:00 - 11:00 | Team Breakouts10:30 - 11:30 | Architecture Vision and Development Practices11:00 - 13:00 | Final Plan Review and Lunch11:30 - 13:00 | Planning Context and Lunch13:00 - 14:00 | ART Risks13:00 - 16:00 | Team Breakouts14:00 - 14:15 | Confidence Vote16:00 - 17:00 | Draft Plan Review14:15 - ??  |Plan Rework?17:00 - 18:00 | Management Review and Problem Solving?? | Planning Retrospective and Moving Forward

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.

What happens in the first part of the PI Planning meeting?

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.

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

The confidence vote is a seemingly small but very important part of PI Planning 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.

When is PI Planning held?

Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations) is the right amount of time for an increment.

Some companies hold quarterly PI Planning, for example:

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

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.

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

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

They’ll look at the top capabilities from the Solution Backlog, Solution Intent, Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher level, across the overall solution and not just the individual ART.

The event starts with each ART summing up their previous program increment and accomplishments to set the context. Next, a senior executive will brief the attendees on the current situation before Solution Management discusses the current solution vision and any changes from what was shared previously. Other things that are often discussed or finalized include:

• Roadmaps
• Milestones
• Solution backlogs
• Upcoming PI features from the Program Backlog

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

PI Planning in SAFe

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.

PI Planning in Scrum

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.

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

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

PI Roadmap

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:

1. The current increment (work that’s committed)
2. The next forecasted increment (planned work based on forecasted objectives)
3. 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.

What is a program?

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.

1. Launch team
2. Food team
3. Oxygen team (Agile)
4. 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:

1. Launch team (Agile)
2. Food team (Agile)
3. Oxygen team (Agile)
4. 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).

What is a program board?

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.

• Feature 1
• Feature 2
• Feature 3

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

Free Trial

Who is involved in PI Planning?

There are 5 key roles in a PI Planning event:

1. Release Train Engineers
2. Product Managers
3. Product Owners
4. Scrum Masters
5. Developers

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.

Developer

Developers are responsible for researching, designing, implementing, testing, maintaining, and managing software systems.

During PI Planning, they participate in Breakout sessions to create and refine user stories and acceptance criteria (alongside their Product Owner) and adjust the working plan. Developers help 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.

Watch an Easy Agile Programs product demo

How to prepare for PI Planning

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

What happens after PI Planning?

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.

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

Remote or hybrid PI Planning

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

Common PI Planning mistakes

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.

Using Jira for PI Planning

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

Looking for a PI Planning tool for Jira?

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 📫

Is agile now distributed?

It’s no secret that our work has completely changed in the last two years. Today’s work environment has seen companies embracing a hybrid or fully remote business model, with studies showing that only 4% of workplaces are going back into the office full-time.

In the Agile Manifesto, one of the original principles states, “individuals and interactions over processes and tools.” While this may still ring true, we know now more than ever that our tools empower our interactions and facilitate our processes.

Multiple industries that have adopted the agile framework have shown an increase in distributed agile teams. In fact, according to the 15th State of Agile Report, 89% of agile teams are distributed. Only 3% of these teams will return to the office full-time post-Covid. This is because remote workers have better focus and productivity, are less likely to leave their job, and cost the business less.

Distributed agile is no longer a new concept but our lived reality.

How do we prepare for agile ceremonies such as PI Planning, initially designed to happen face-to-face? How do we retain the most valuable element of face-to-face communication without collocating?

The challenges of PI Planning with a distributed team

Traditionally, activities like PI Planning in agile are designed for team members in the same room to interact in person.

PI Planning is a 2-day event that brings all members of an Agile Release Train (ART) together to plan their next Program Increment (PI).

As the 15th State of Agile Report showed, 89% of agile teams are now distributed. For a distributed team, your options are to fly in employees for each PI Planning session or to support a distributed PI Planning session.

While this is nice, it can be a pricey (and disruptive) exercise for any organization, especially if you need to do it 4 or 5 times a year.

Performing distributed PI Planning also brings up a challenge with using a physical program board. Those at home cannot access or contribute to the physical PI Planning board in the same way as their collocated colleagues. As a result, their ideas can go unheard, and their ability to contribute to the program board is limited.

Distributed PI Planning - Best Practice

Instead of flying your remote team to a central location to run PI Planning in person, distributed PI Planning involves using cloud-based tools to plan and run your next Program Increment virtually.

Even if the methods are a little different from distributed PI Planning, the process and desired outcomes are the same:

• A senior representative discusses the current state of the business
• Product Management presents the current program vision
• Product Owners and teams breakout separately to discuss how they’ll achieve desired outcomes
• Teams identify and visualize cross-team dependencies and work to remove blockers
• Everyone comes together to agree on a committed plan via your Program Board

6 tips for setting up distributed PI Planning

Distributed PI Planning is no longer a temporary exception. Whether PI Planning is distributed or not, we need to ensure we maintain the same quality and outcomes that PI Planning aims to achieve - to align all teams within the Agile Release Train.

To help you through this, we’ve prepared the following 6 tips to help you prepare for distributed PI Planning.

These tips aren’t things that we’ve just brainstormed. We’ve learned these things from speaking to our customers by trawling the forums and talking to experts in the field.

1. Get the basics right

The three basics are communication, preparation, and execution.

Let’s start by talking about communication and preparation. It is essential to provide appropriate tools for online interactions for each stage of the PI Planning process: for product managers to collaborate and facilitators to manage the process-both leading up to and during the event. We also need to ensure team members can access all relevant current information, collaborate effortlessly, and access support.

Scaled Agile recommends having pre-PI Planning meetings scheduled anywhere from 2-6 weeks in advance, depending on the complexity of your solution train.

Lastly, let’s talk about execution. The execution should flow if we are communicating well and are prepared. But we need to be prepared that some things can still go wrong. Technology will fail us. People can still have problems accessing the tools we’ve set up. Execution won’t always be seamless, but iteration is a principle of agile.

2. Set the agenda early, as early as possible

Why is that? Well, think about your employees working from home. They’re working with their pets or family around, and if they know that they have PI Planning, they need to know what is expected of them.

This allows time for employees to inform their families of their commitments for that day, set up a space with no distractions, and be mentally prepared for a few days of planning.

Also, let’s not cram the agenda full of all the events we need to hold. Let’s make sure we have enough time to schedule multiple breaks throughout the day, as studies show that humans are more likely to experience mental exhaustion after a day of video conferencing.

While it’s essential to use the tech, it can get a little bit much. Set up rules about who can talk and when to use the mute button. This will avoid interference and background noise disrupting your team’s focus.

3. Choose your tools wisely

Distributed agile teams can simulate the best of the in-person experience by selecting tools built for distributed and hybrid teams: video conferencing platforms, team chat, virtual program boards, and interactive collaboration spaces.

Whatever tools you choose, the key is finding solutions for colleagues to connect in real-time, whether in the same room or on the other side of the world.

Set up the tools, test them, and introduce them to all participants before the PI Planning session. To avoid overload and confusion, select tools that work together seamlessly.

4. Practice

We’re not going to get this right the first time. We’re going to have to rehearse. We’ll have to work out how we do things like confidence votes. Will we use the poll function on Zoom, or will we use Slack?

Everyone prefers to finish early rather than run out of time. Let’s build some slack into the agenda.

Acknowledge that there’s always room for improvement and build that into our planning. Let’s give our people a chance to communicate back to us, whether by a retrospective or by opening up a channel for feedback. We’re not just getting feedback on how the last planning session went but also on how we are finding working together more generally.

5. Make it accessible

When dealing with different time zones, you should extend the PI Planning agenda from 2 days to 3-4 days to ensure all critical parts of the PI Planning session are placed at a reasonable time for all time zones.

Set up each meeting via Google Calendar or any calendar device your team may already be using. Ensure each meeting is named, followed by a description, so attendees know what to prepare and which tools are relevant for this meeting. Make sure the correct attendees have all been sent invitations to the forum before the event.

We’ll have trouble setting up people on new tools and getting them access to their needed resources. It will be great if tech support is available throughout PI Planning. That will be easier for some people than it is for others. But it’s crucial if things go wrong.

We’re going to need a backup in place. Your tools will need to be reliable, and you will need tech support to help fix them quickly.

We will need more facilitators than we usually do to be able to answer all of these questions throughout the week.

Some people may not be used to using the tools that we’re suggesting that they use. So is there training available to help them get up to speed?

6. Level up the human experience

Seize opportunities to ensure agile teams feel as if they are working together when they are actually apart so that members see themselves as part of a community with:

• Shared understanding – Clarity of vision, mission, purpose, and visibility into what team members are doing, facilitating learning loops among colleagues.
• Shared empathy – Forging human connections with our tribe creates the psychological safety to learn, grow and iterate.
• Shared experience – Creating a sense of team place, identity, and building together.

How to excel at distributed PI Planning with Easy Agile Programs and Welo

The most challenging part of distributed PI Planning is providing the positive aspects of the in-person experience to a distributed team: fluid movement around and between rooms to collaborate, easy ways to contribute to brainstorming sessions and keep whiteboards up to date and accessible, and natural social interactions that build trust and camaraderie.

Easy Agile Programs offers a complete PI Planning solution that makes scaled cross-team planning and execution easy. With a seamless Jira integration, it’s a powerful yet simple-to-use tool to scale planning and maintain alignment across distributed, hybrid, or remote teams during planning and throughout execution.

Welo offers interactive collaboration spaces that amp up the human experience for distributed and hybrid teams. It replicates the in-person experience of fluid interactions, effortless collaboration, and human connections among colleagues–beyond the isolated video. Welo’s visual orientation enables each person to be present in the context of space and to navigate to be with people and groups as they choose.

With these two tools, you can set your Agile Release Train up for success for PI Planning. Here’s how:

Select professionally-designed virtual spaces

Bring online the best of the brick-and-mortar spaces you used for in-person PI Planning–from plenary to break-out rooms to spots for casual socializing.

Rather than feel confined to a static rectangle, people see themselves and others in context, move themselves in and between spaces to connect with colleagues before, during, and after PI Planning events.

Welo spaces also provide PI participants ready access to up-to-date, relevant resources, such as Jira and Easy Agile apps used across all events.

Establish the Business Context

All Agile Release Train members can access information about the program in Easy Agile Programs. For example, in the objectives section below, you could link to a pre-recorded video of the business owner addressing the company-level objectives. Hence, teams know that their team-level objectives must ladder to this. This ensures that all members of the Agile Release Train see your business owner face to face in that distributed way and that they always have access to this video throughout PI Planning.

After viewing the information about the program, the Product Manager can create features in Jira ahead of the PI Planning event to be discussed and broken down in planning. Easy Agile Programs seamlessly integrates with Jira, so there's no need to double-handle the work. They are ready to schedule onto a visual timeline for everyone to see what the team has committed to during PI Planning.

Set up your SAFe Program Board

The SAFe Program Board is a critical tool and output of PI Planning; It is a visual summary of features or goals, cross-team dependencies, and other factors that impact their delivery. Not only does this help with transparency, but it also increases flexibility, which helps minimize delays and unhealthy dependencies.

Ensure you have a digitized SAFe Program Board set up before the PI Planning session. Easy Agile Programs replicates the physical program board. A board that everyone has the same view of and can access. Learn how to set up a SAFe Program Board with Easy Agile Programs here.

Prepare your Team Planning Board

The Team Planning Board represents a scrum or kanban board which is included in the Program. This is where the teams will plan their work in the team breakout sessions during PI Planning.

If you have set up your Program Board with Easy Agile Programs, prepare the team Planning Boards by adding each team to the Program ahead of PI Planning. Once teams are added, Planning Boards are automatically created and ready for team breakout sessions. Teams can create team-level PI objectives, break down features into user stories, estimate issues to understand capacity, and create dependencies with other teams.

Moving forward

With distributed PI Planning a reality for nearly 90% of agile teams, the good news is that new solutions are being developed to work with your current tools–powering employee engagement, fluid collaboration, and efficient processes critical to successful outcomes and career satisfaction.

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

Easy Agile Programs

Join a demo