Planning Interval (PI) planning is a fundamental practice that underpins the Scaled Agile Framework^® (SAFe^®), improving the alignment of stakeholders and teams (Agile Release Train) to a shared vision and mission. In this guide, Quinn Dodsworth, Agile Learning Consultant and Facilitator at PM-Partners, explains what PI planning entails and how it can benefit your agile practice as a whole.

According to the Scaled Agile Framework^® (SAFe^®) guide, Planning Interval (PI) planning is an essential event in the practice of SAFe: “If you are not doing it, you are not doing SAFe.” – Dean Leffingwell

But what does PI planning entail? This article will cover everything you need to know about PI planning and the important part it plays in the Scaled Agile Framework (SAFe). 

What is PI planning? 

PI planning is an activity for the Agile release train (ART) that seeks to align stakeholders – teams of agile teams and others alike – to a shared vision and mission through effective collaboration. A successful PI planning event should produce both committed and uncommitted PI objectives and an ART planning board that identifies features included, feature dependencies among teams, and possible delivery dates and milestones. 

The basics of PI planning

A typical PI planning event takes two full days and should be run during the ‘Innovation and Planning’ iteration of a PI. A Planning Interval usually runs for an interval of 8-12 weeks long (approximately 4-6 two-weekly iterations). Every team in the ART, including remote teams, should attend the PI planning event whether in-person or virtually. Organisations with established scaled agile practices tend to schedule these well in advance, for example every quarter, to allow for teams to travel or find suitable time zones to meet.

PI planning events are essential to SAFe as they gather team members, product owners and stakeholders to define objectives, prioritise features and identify dependencies across teams. Essentially, they provide the direction for the Agile Release Trains, on the value stream managed tracks, to deliver key products and services to the customer.

The SAFe authors recommend the agenda of the two days contain the following:

Day 1:

• Business context (60 minutes): The business owner gives an overview of the current state of the business and the portfolio vision, plus an evaluation on the efficacy of existing solutions in meeting current customer needs.
• Product/solution vision (90 minutes): The product management team recap the current vision, indicate any changes from the previous PI planning event, and share relevant milestones.
• Architecture vision and development practices (60 minutes): The system architect discloses the architecture vision. This is also a chance for senior development managers to suggest or introduce changes to development practices that improve Agile practices for the next PI.
• Planning context and lunch (90 minutes): The release train engineer outlines the planning process and expected outcomes. People re-energise and socialise at lunch.
• Team breakouts (180 minutes): Teams work out their capacity for each iteration and identify the backlog items they potentially need to realise the features. Each develop and share draft plans of each iteration.
• Draft plan review (60 minutes): Each team presents key planning outputs, initial risks and or missed opportunities; the other stakeholders review these and provide input.
• Management review and problem-solving (60 minutes): Management discusses and resolves problems by suggesting, negotiating or approving planning adjustments.

Day 2:

1. Adjustments (60 minutes): Management shares changes to the planning scope, people, and resources based on Day 1 presentations.
2. Team breakouts (120 minutes): Teams finalise their plans and objectives for the PI.
3. Final plan review and lunch (120 minutes): All teams share their plans to the group, including risks and impediments. Business owners decide if the plan is acceptable: if yes, the team submits its PI objective sheet; if no, the team can adjust the plan in response to any objections and share its revised plan.
4. ART PI Risks (60 minutes): The whole train collates the risks and impediments identified in the final plan review to address and classify them as resolved, owned, accepted or mitigated.
5. Confidence vote (15 minutes): The teams vote on their confidence in meeting their team PI objectives.
6. Plan rework: If required, teams may adjust their objectives to increase their confidence.
7. Planning retrospective: The release train engineer shares the key aspects of the PI planning event – what went well, what didn’t, and how to improve for next time.

PI planning versus project planning

PI planning is a comprehensive event that brings multiple teams together in a collaborative setting, focusing on both program value and team alignment. It serves as an opportunity for teams to meet, understand one another, and work collectively to solve problems and address challenges. The alignment between teams is as crucial as the PI objectives and the plans the event produces. A key difference in PI planning is its emphasis on continuous delivery of customer value. Teams collaborate to identify ways to deliver value to the customer sooner, ensuring that what is produced remains relevant and valuable over time. This approach aligns with SAFe’s focus on long-term value flow, where customer needs continually guide the work. 

In contrast, traditional project planning is typically handled by project leadership, and then communicated and delegated to various team members or teams that work under its direction. This top-down approach can lead to missed dependencies and risks, and there is often less opportunity for teams to build rapport with others. Project management focuses more on delivering value within a defined start and end date, with the product’s delivery often marking the first real opportunity to provide customer value. Any further opportunities identified typically require the initiation of a new project, reflecting a short-term, segmented approach to value delivery. 

When to use PI planning

PI planning is designed to take place prior to the start of the next interval (usually 8-12 weeks); it is not for the start of a sprint. It’s looking for a better agreement to the broader strategic objectives, whereas sprint planning breaks these down into smaller, more tactical, detailed goals.

Because of its breadth, PI planning is for organisations practising agile at scale using multiple teams and working on large-scale programs, whereas other types of agile planning are narrower in scope and meant for individual teams.

Use PI planning:

• Before the start of each interval
• When all teams are available to contribute
• For large-scale programs
• For strategic objectives
• To align multiple teams and stakeholders.

You can use the PI planning model for non-scaled-agile programs in smaller organisations and/or for those using Scrum, however. In this case, the modified version may be less formal and require less time but still adopt the collaborative multi-team approach that sets objectives, identifies dependencies, and secures commitment for the next increment.

The benefits of PI planning

The organisational benefits of PI planning are as much about who is collaborating and how they work together as it is about the act of planning and the outcomes of the event. Thus, it is important that team members and stakeholders communicate face-to-face (virtually if in-person is not feasible) and foster cross-team collaboration to develop the social network at the foundation of the ART.

For the program, the benefits range from clear alignment of goals with the business context and vision, as well as the team and Agile Release Train’s PI objectives, to identifying demand and capacity, assessing dependencies, and speeding up decision-making.

Each PI planning event also enables the organisation to check in and guide the teams on the architecture and lean user experience aspects of practising scaled agile.

PI planning in action

PI planning is ideal for programs where different teams play different roles but do better when they collaborate to produce aligned objectives.

For example, imagine you are building a fashion ecommerce website and you are adding three features: search by size/colour/brand, customer reviews, and website-generated recommendations. You might have a UX team that primarily designs and tests the search function, a buying team that manages stock and inventory, a marketing or customer service team that seeks reviews by prompting existing buyers to rate their purchases, and a programming team that analyses search and sales data and matches them with user profiles and customer reviews to create an algorithm for the recommendation function.

Each of these teams can function on its own and do its part, but collaboration allows them to create synergy, identify dependencies and see shared objectives to bring the teams into alignment and increase their collective chances of success.

Planning Interval planning is at the foundation of agile release trains, which is the building block for the Scaled Agile Framework. Done properly, PI planning brings together multiple teams to collaborate and align their objectives while fostering better interpersonal relationships between teams. It is this dual purpose that makes PI planning an extremely effective event for organisations practising scaled agile.

Need more guidance on planning interval (PI) planning? See our range of SAFe Agile courses and SAFe consultation services. Or to find out if scaled agile is right for you, contact us online, or call us on 1300 70 13 14 today.

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.

This article was last updated in October 2024.