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.
- 1 PM – 2 PM (ART Risks): In the previous meeting, teams presented their plans and identified risks. Now, they attempt to resolve them in a broader business context in front of the entire ART. Teams discuss each risk with honesty and group them into one of the four categories:
- 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.
Inputs
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.
Outputs
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.
#1. Teams
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
- Q2 PI Planning: March
- Q3 PI Planning: June
- Q4 PI Planning: September
Organizations that want to stay more Agile choose the 8-week interval.
#3. Scope
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.
