The Definitive Guide To PI Planning. Tips & Guidance

What is the Scaled Agile Framework (SAFe)?

The Scaled Agile Framework (referred to as SAFe), is a system for scaling Agile principles and practices throughout an organization. It is primarily used by companies focused on building software—and most commonly is used almost exclusively by the technology organization itself.

SAFe was created by Dean Leffingwell, a devout Lean-Agile practitioner and author. It debuted in 2011 with version 1.0 and has evolved over the years as Dean, along with his team of SAFe contributors have learned, experimented, and found new ways to apply the principles more efficiently and to a broader audience.

SAFe Configurations

There are multiple “configurations” in SAFe. They are, from simplest to most complex:

• Essential SAFe
• Large Solution SAFe
• Portfolio SAFe
• Full SAFe

The use of a specific configuration will be determined by a number of factors including business size, number of products/solutions offered, product maturity, team maturity, and many more. Each configuration adds additional components and concepts.

For the purposes of this article, we’ll consider Essential SAFe as our context, as it’s the easiest to understand and is at the core of the other configurations.

That said, the basics of PI Planning don’t change much between configurations so don’t worry too much about the details.

SAFe Basics

SAFe is a method of scaling Agile development practices throughout an organization in order to synchronize planning and ensure everyone is working toward the most important objectives at the same time.

Layers of Essential SAFe

Essential SAFe has two levels or layers:

1. The Program level–consists of product managers, system architects & engineers, and the Release Train Engineer (RTE).
2. The team level–consists of all the individuals product teams (e.g. engineers + QA + Product Owner)

Each level has its own distinct and some overlapping roles & responsibilities. For the core work of PI Planning, just remember that the Program level is where features are created and the team level is where user stories are created. User stories roll up into features.

The SAFe Lifecycle

1. Plan the work for the next quarter (PI Planning)
   1. Decide on the top 2-3 initiatives
   2. Write and refine features that contribute to the initiatives
   3. Break down the features into user stories that the teams will work on
2. Do the work throughout the quarter
   1. Work
   2. Measure
   3. React
3. Start planning for the next quarter
   1. Mainly PMs and business owners
   2. Measure and evaluate delivered work
   3. Start identifying candidate initiatives
   4. Pre-plan some features
4. Repeat steps 1-3

PI Planning Overview

There are numerous ceremonies (aka meetings) in SAFe. These ceremonies, as with traditional Scrum ceremonies, help organizations plan and prioritize consistently and effectively. The Program Increment (PI) Planning event is the grand ceremony of SAFe. Without it, there is no SAFe. That warrants added emphasis: You’re not practicing SAFe and will almost certainly fail in your attempt without proper PI Planning. PI Planning is where the rubber meets the road.

You’re not practicing SAFe and will almost certainly fail in your attempt without proper PI Planning.

During the event the Agile Release Train (ART), together with all key stakeholders, meets face-to-face to figure out how you are going to accomplish the top two to three initiatives for the next PI. The event is held at the start of every PI, usually once per quarter, as a general rule.

The venue for the event can be anywhere, but face-to-face communication in a co-located space is preferred. Virtual PI events can work, but will always suffer in efficiency compared to a co-located event. Ideally, the venue will be large enough to accommodate all teams and stakeholders in a single room with enough space for each team to have their own working area. Plan on two full days for the event.

What are the inputs to PI Planning?

Many things go into PI Planning, but the major inputs are the:

• Business context
• Product roadmap and vision
• Top features of the program backlog

SAFe recommends limiting this to the top 10 features, but your ART size, velocity, and capabilities may mean you need to reduce this to even fewer. Many SAFe consultants recommend an organization focus on their top two to three initiatives per quarter.

What are the outputs of PI Planning?

The high level outputs are the Program Board and committed PI objectives. More specifically, the goal of the event is for each team on the ART to create their team-level PI plan, sprint-by-sprint, along with their committed (and stretch) objectives, delivery dates, milestones and clearly-identified dependencies on other teams. These team-level plans put together form the Program Board that everyone on the ART and all relevant stakeholders can view.

We’ll dive into the details of PI Planning in the following sections. These sections are divided into convenient groups for easy reference:

• Getting Ready & Pre-PI Planning
• Logistics
• The PI Planning Event

How to Prepare for the PI Planning Event

In Essential SAFe, the human resources are categorized into two main groups:

• Team level – those who are engaged in daily front-line production activities (i.e. engineers, QA, Scrum Masters, and Product Owners)
• Program level – those who operate a level up from the team (i.e. product managers, release train engineers [RTEs], system architects, and business owners).

This latter group spends much of the PI, particularly the latter half, getting ready for and planning out the next Program Increment. We’ll focus on two topics here:

• Pre-Planning Activities
• Logistics

Who Facilitates PI Planning?

The work of PI Planning is done by everyone, but is primarily facilitated by the RTE with backing from the Business Owner(s), system architects, and product managers. As you’ll see, there is a lot that goes into a PI Planning and everyone has to do their part.

When is Pre-PI Planning Needed?

“By failing to prepare, you are preparing to fail.” –Benjamin Franklin

Essential SAFe consists of a single ART, and doesn’t require the official Pre- and Post-PI planning meetings indicated for Large Solution and more advanced SAFe configurations. Our focus here is on general pre-PI planning activities that will help ensure a more successful PI Planning Event.

Pre-PI activities include the necessary strategy, research, product planning, and similar activities that produce the key inputs for the PI Planning Event (noted above). These activities involve business owners, product managers, system architects, and RTEs.

Business owners will establish the business context–the “state of the business” that includes general business progress, competition, regulatory landscape, market conditions, and so forth. This information is key to helping everyone on the ART have a broader sense of what they are trying to accomplish and the environment in which they are trying to accomplish it. They will also establish and agree on the priorities for the next PI.

Product managers generally create and refine the roadmap based on business objectives and priorities. They spend much of the current PI building the backlog by creating and refining the features that will be the focus of the next PI-Planning Event. They also work with the system architects to convey scope and understand the constraints of the system.

System architects work with the product managers to communicate constraints, as stated above, but also work to lay down the architectural runway necessary to accomplish the work of the next PI. Therefore, it is essential that business owners, product managers, and system architects stay in sync to ensure the correct runway is laid down or well underway before the next PI starts.

Release Train Engineers (RTEs) spend much of their time tying things together, ensuring everyone is working together, but also planning out logistics and schedules for the next PI-Planning Event.

The deliverables from all of this pre-planning work include business context, the product roadmap/vision, and the top features that will be considered for the next PI.

Logistics

“The line between disorder and order lies in logistics.” –Sun Tzu

The logistics of the PI Planning Event are equally as important as the content of the event itself. Without proper logistical preparation, even the best content in the world can’t make the event succeed. There are several key factors in the logistics of the meeting and these need to be planned and communicated broadly well in advance of the event. It’s probably easiest to think of the logistical needs in terms of who, what, when, where, and why.

Who Should Attend PI Planning?

You will need to consider which teams, individuals, and leaders will attend the event. Additionally, if this is your first PI Planning event, having a consultant to help monitor and facilitate can be incredibly helpful. This doesn’t need to be a 3rd party consultant, either. This can be an individual from another business unit who’s been practicing SAFe, or even someone within the company who is SAFe certified or has previously participated in PI Planning Events.

Generally speaking, everyone on the Agile Release Train should attend:

• Every team (engineers, QA, Scrum Masters, Product Owners)
• Product managers
• Release Train Engineer
• System architects/engineers
• Business owners
• Optional key stakeholders, such as other executives.

What Supplies and Tools are Needed?

The what of the logistical puzzle involves many components. This includes basic office supplies, technology and communications tools, and food and beverages.

Office Supplies

• A few sticky notes pads in four different colors (generally blue, yellow, orange, and white). These will be used to populate the team boards as well as to identify dependencies on other teams on the program board. Assign the colors a specific meaning and be consistent. For example, use blue for features, white for user stories, yellow for milestones, and red or orange for dependencies.
• Poster-sized sticky notes or poster boards for the team iteration boards (one for each two-week sprint/iteration in the PI).
• A half a dozen markers and pens
• A large whiteboard or a blank banner that can be rolled up and transported outside of the venue. This will be used for the program board.
• Red string or yarn to visually link dependencies on the program board.

Technology and Communications:

• Projectors/screens or large TVs that everyone can see and adequate audio (especially critical for large ARTs and venues). The projectors will be used to present the business context, product roadmap/vision, and architecture roadmap. These will also be used for plan reviews.
• Computers and internet (for select individuals).
• Additional technology and communication considerations will need to be made for remote attendees (e.g. Zoom, Slack, etc.).

Food and Beverage

Perhaps the most important item (at least in terms of keeping people happy) is the food and beverage service.

• Provide at least lunch (and maybe breakfast) on site to keep the break concise and productive.
• In addition to lunch, it is helpful to provide snacks and beverages (in addition to water) to keep everyone motivated.

When and How Often is PI Planning?

PI Planning is most commonly done once per quarter. The date of your PI Planning event should coincide with the end of the last iteration (sprint) of the current PI. Thursday and Friday are good days and give everyone a break over the weekend before coming back and officially kicking off the first iteration.

The specific agenda for each day will be discussed below, but in general, plan to start at 8am the first day and end at 6pm. The second day will start at 8am as well but may end at 3 or 4pm or earlier, depending on how much rework is needed.

Where is PI Planning Held?

The best choice is to meet at an offsite venue large enough to accommodate all teams. Co-location is important because there’s no substitute for face-to-face, in-person communication. Offsite (away from the office) is ideal because it reduces the distractions of being in the office and gives people a change of scenery.

For offsite venues you’ll need to consider: Providing lunch, snacks, and beverages; coordination of travel to/from the venue; and transportation of technology components, the program board, office supplies, etc.

Strategies for Effective Distributed PI Planning Events

In some cases, a co-located event isn’t possible. Some organizations have multiple office locations or are 100% remote and can’t feasibly bring everyone together. Some strategies to make this setup effective are:

• Robust video conferencing with team breakout capabilities. Everyone needs to communicate in real-time, both as an ART and as individual teams.
• Slack or other instant messaging tool. You’ll need to collaborate with other teams without interrupting their meetings so Slack becomes helpful for less urgent communication.
• Digital whiteboards (e.g. Miro) and/or other collaboration tools like Google docs. You’ll need shared tools for building the team iterations as well as the Program Board.

The PI Planning Event – How to Conduct PI Planning

“Nothing good ever comes out of hurry and frustration, only misery.” –Auliq Ice

The PI Event should be planned for two full days. Additionally, some key stakeholders may meet for another partial day after the main event concludes. Rushing or consolidating the event into a single day is not recommended.

What follows is the suggested schedule of events, as recommended by Scaled Agile, Inc. This is what is taught in the official certification courses and generally what most companies follow. Try not to deviate from the suggested schedule, in terms of content and order, but the time allocated to each item can be somewhat fluid.

Below the schedule we’ll take a look at what is involved with each agenda item.

Day 1

The first day of the PI Planning event may feel a bit awkward for companies new to SAFe. Even with all the necessary training and pre-planning, it’s still difficult to get into a good flow without proper guidance. It’s highly recommended, where possible, to have one or more guides–someone internal or external to the company or ART who has previous experience with SAFe and can help facilitate the event.

Now let’s dive into the agenda one piece at a time.

Business Context

The business context is presented by a senior leader or executive, usually designated as a Business Owner. This segment starts with a state of the business, after which the vision is laid out and contrasted to existing market solutions that don’t meet customer needs.

Product/Solution Vision

The product or solution vision is presented by the product org–usually a senior product leader. They will typically present the next set of features that aim to fulfill the vision in practical terms. They may also discuss any major changes in strategy from the previous program increment.

Architecture Vision & Development Practices

The architecture vision is presented by an individual designated as a System Architect or Engineer. This time may also be used to present upcoming changes to a company’s internal agile development processes.

Planning Context & Lunch

For Planning Context, the Release Train Engineer (RTE) reviews the PI planning process, the expected outcomes and artifacts, and may elicit and answer questions from the group.

A quick note about the day one morning activities: Oftentimes, the first four agenda items of the day take less than an hour and a half total. There’s no need to artificially stretch these portions out. They’ll likely be longer in your first PI since everyone will be new to the process. Don’t be afraid to wrap up the “business” items before lunch.

Team Breakouts

This is the central and single most important event of PI Planning. If the first four meetings of the day conclude rather quickly, you’ll want to move into Team Breakouts right away.

Key activities during team breakouts:

• Estimate team velocity (capacity) for each of the 6 sprints or iterations of the PI (assuming a 12-week PI). Teams need to take into account holidays and planned PTO, but may also want to consider a buffer for unexpected interruptions like sick days and sideways work.
• Create the stories needed to accomplish the features in the program backlog. It’s often helpful to think of Program features as epics and plan stories accordingly. Stick to the sticky note color scheme you agree on (e.g. blue for features, white for stories, yellow for milestones, red/orange for dependencies).
• Create draft plans on the giant stickies or posters on the wall for other teams to see. This involves laying out the stories when and where needed to accommodate blockers and dependent team schedules.
• Create draft objectives for the PI to accompany the draft plan. Objectives should be SMART–specific, measurable, actionable (or attainable), realistic, and timebound.
• Scrum masters attend an hourly scrum of scrums to get insight into other team’s planning, dependencies, and potential blockers. Note: This is not on the official SAFe agenda but is highly recommended.
• Teams identify which features are planned for which iteration on the program board (usually placed at the front of the room for everyone to access). Ensure dependencies are noted on this board with colored string or yarn.
• Teams report dependencies to other teams and put them on the program board.
• Teams report risks on the program board.

Draft Plan Review

Each team presents their proposed plan for the PI, including estimated capacity and load (i.e. story points) for each iteration, draft objectives, and risks and dependencies (often these are related, but not always).

The pace of this review is fairly quick and each team needs to be timeboxed to keep on schedule.

Confidence Vote

A day one confidence vote isn’t officially part of the SAFe PI Planning agenda, but it is helpful to gauge group sentiment on day one, seeking feedback from those with low confidence and comparing confidence from day one to day two.

How does the Confidence Vote Work?

The confidence vote format is best accomplished by assigning the numbers 1 to 5 to five different areas of the room. Call the vote and tell people to move to their confidence number, with 5 being total confidence that the objectives will be met. Once everyone has voted, it is helpful to elicit input and feedback from those with lower confidence, if they wish to share.

If there isn’t sufficient room for location-based voting, a fist to five method works where people show their votes with their fingers. Similarly, in a distributed or remote PI Planning, a simple vote can be taken using any number of online polling systems.

Management Review and Problem Solving

The day one planning activities and especially the draft plan review and confidence vote, will always surface important issues regarding risks, dependencies, resources, and scope.

• Attendees should be business owners, RTE, system architects/engineers, Scrum Masters, team leads/dev managers, product managers, and Product Owners.
• The group reviews risks together and ROAMs each of them. In a ROAM exercise, each risk is Resolved, Owned, Accepted, or Mitigated (see Program Risks below). With very large ARTs, it may be helpful to do this with the smaller leadership group so the risks can be briefly reviewed with the ART on day 2.
• Dependencies are discussed and stakeholders are made aware. Ideally, no new dependencies will be discovered at this stage, but team breakouts can be a bit chaotic so some teams may not be aware of all dependencies on them. Now is the time to ensure everyone is in the loop so any re-work can happen on day two.
• Issues of scope and resources usually boil down to teams taking on too much load to accomplish the selected features from the Program backlog. For this reason, it is vitally important that the business owners have clear priorities, because you will almost always have to cut scope during PI Planning.

Day 2

Planning Adjustments

To start day two, leadership will review any changes in priority and scope that were made at the end of day one. These may affect one or more teams but should be communicated to everyone.

Team Breakouts

Once the priority and scope changes have been reviewed, the teams will break out once again. Virtually every team will have to make some changes. The same key activities as day one are carried out, with teams ensuring they wrap up planning with all relevant dependencies considered.

Final Plan Review & Lunch

Each team presents their proposed plan for the PI as they did on day one. This time, the plans are considered final, with few exceptions (see Plan Rework below).

Program Risks

If risks were ROAMed the previous day, they should still be reviewed with the larger group, in case anyone has unresolved concerns. If not, you’ll need to ROAM the risks now.

• Resolved–the risk is resolved with no further action needed.
• Owned–the risk is assigned to an owner to resolve or mitigate outside of the meeting.
• Accepted–the risk is accepted because it can’t be resolved or mitigated.
• Mitigated–a plan is put in place to eliminate or reduce the impact of the risk.

Confidence Vote

Another confidence vote is taken, following the same format as the draft vote from the day before. If risks have been ROAMed, dependencies discussed and handled, and priorities and scope well managed, there should be a noticeable change in confidence across the ART. It’s helpful to once again elicit feedback from low confidence voters to see if there are any red flags that haven’t been previously raised. Some people are just overly pessimistic (they’ll tell you they are realistic) and you’ll likely have a few lingering twos or threes even with a perfectly run PI Planning.

Plan Rework

If the confidence vote is… not confidence inspiring, plan rework may be necessary. Again, business owners will need to make some tough decisions in terms of priority and scope.

This portion of the day can go very quickly or may take quite a while, even bleeding into a third day of planning. It is important to rework the plan until things are right.

Planning Retro & Moving Forward

Once planning has concluded, time should be made for a brief retrospective, led by the RTE. This follows a typical retrospective format:

• What went well?
• What didn’t go well?
• What can be improved?

The end-of-PI Planning retrospective is an important step because it helps the organization improve its planning, thereby improving outcomes.

After the retro, the RTE should outline action items and next steps:

• Ensure team iteration plans and objectives are recorded in your planning software (e.g. Jira).
• Team PI objectives will be rolled up into Program objectives that are recorded and used to measure progress throughout the PI (updated during scrum of scrums).
• Ensure the program board is documented–photographed and physically relocated, and ideally recorded in your software.
• Logistics, such as event space cleanup, travel arrangements, etc.

PI Planning Anti-Patterns

As with anything in technology, there are certain anti-patterns that naturally develop that you’ll need to watch out for.

• Throwing things over the wall. Don’t assume someone else will handle the problem, that the requirements are clear, or that something will get done until and unless you have a commitment from the other person or team.
• Feuds over priorities and content authority. Who owns feature priority and who has content authority over user stories? Someone has to make the call and there’s a clear escalation path in SAFe: * Product Owners have authority over user story content and priority at the team level. They work with the engineering lead and other teams to ensure priorities and content are correct. * Product Managers have authority over feature content and priority at the program level. They work with system architects, other product managers, Product Owners, and engineering leads to ensure priorities and content are correct. * Business Owners have ultimate say over content and priority, but should never make decisions without all necessary context from PMs, POs, system architects, etc.
• The RTE doing everything. The RTE should be delegating tasks to system architects, product managers, and team-level stakeholders as appropriate to ensure PI Planning runs smoothly.