What is PI planning in agile?

May 5, 2023

4 min read
1311
108

The more teams you work with, the more complex collaboration becomes. A small self-managing team of seven people generally delivers more than three teams of the same size that have cross-dependencies.

A common approach to solving collaboration challenges is by adding processes, but I discourage that because it gets in the way. The best way to increase collaboration is by simplifying it.

Complaining that collaboration is complex isn’t a solution. To succeed, figuring out how to deal with it and aligning in a common direction is mandatory. That’s when program increment (PI) can be helpful.

Skip ahead:

What is program increment (PI) planning?

Program increment planning, or PI planning, is the moment teams get together to align in a shared direction. They agree on what to focus on and what to drop. They also identify dependencies and take action to minimize impacts.

Although program increment planning is typically done with SAFe when defining the agile release train, the idea behind it is applicable to any framework you use.

I recommend keeping it as simple as possible because collaboration usually occurs instead of mechanically.

The result of excellent PI planning is:

• Output — goals are written down, actions to deal with dependencies are defined, and the team roadmap is set
• Outcome — clarity on the direction and empowerment to say no to distractions

What is PI planning vs. sprint planning?

Both PI planning and sprint planning are essential for a successful agile process, however they each serve distinct purposes and operate on different timelines. PI planning works at a higher-level — it’s a strategic event that brings multiple teams together to align on the upcoming program increment and get everyone on the same page. The program implement typically spans 8–12 weeks.

On the other hand, sprint planning is a more granular, tactical activity. Sprint planning is performed by individual teams at the beginning of each sprint, which is every 2–4 weeks in a traditional scrum process. During sprint planning, teams break down the larger objectives established in PI planning into specific tasks and user stories, providing some clarity around the amount of resources needed and the estimated effort to finish the tasks.

Basically PI planning sets the stage for cross-team alignment and long-term focus, while sprint planning ensures teams are well-coordinated and making steady progress towards those overarching goals.

How modern PI planning works

Personally, I dislike the name program increment planning because it sounds bureaucratic and not agile. With my teams, I call it product goal alignment.

I don’t get stuck with names — I focus on outputs and outcomes (as described before). Let me share with you the details behind modern PI planning, aka product goal alignment:

• Why: clear alignment for the next quarter(s)
• What: define which goals to pursue, name dependencies, define responsibilities, and roadmap
• When: 2–3 weeks before the end of the quarter
• Who: product trio of each team (PM, UX, and dev), and company leadership
• How long: 4–6 hours
• How often: Once a quarter

Now let’s address the how-to question in depth during the next part of this post.

How to prepare for PI planning

You cannot benefit from PI planning without proper preparation. The more teams you have in the room, the more preparation you need.

Before the session, the following need to be nailed down:

• Product vision: where do you aim to be with your product in two to three years? Write it down and make it clear to everyone
• Strategy: what’s your strategy to enable your product vision? For example, it could accelerate growth by expanding to new countries while keeping customer satisfaction at the current level
• Status quo: where does the product stand as of now? What’s between you and the product vision?
• Prioritization: based on all the above, what matters most right now? Define a clear prioritization by setting what to focus on and what to say no to

The above are primordial to problem sessions. Otherwise, your result will be watered down. Yet, don’t underestimate the above because you will need to have alignment sessions with all product managers and leadership. You can consider some days of work. If you’re taking weeks, it’s a sign something is going wrong.

Running the PI planning

After you have nailed the preparation, it’s time to run the session. I recommend sharing the summary of vision, strategy, status quo, and prioritization with everyone before the team. This will help them come better prepared and avoid wasting time.

Depending on your setup, you need to prepare either a physical space for that or a virtual session. Either way, the following agenda for a five-hour session will support both approaches:

Successful PI planning will result in clarity for the future and commitment to outcomes.

Bad PI planning will end with too many open questions and confusion. It can also be that teams have committed to outputs instead of outcomes, which will trap them into a waterfall mindset.

Conclusion

PI planning isn’t necessary for everyone. When you have up to three teams, you can live well without it, but as the team grows, you need to add structure to ensure alignment. PI planning can become handy for bigger organizations.

I particularly dislike the name PI planning because of its frequent misunderstanding, but I do like the idea of alignment and commitment to goals.

You will benefit from having quarterly sessions with leadership and part of product teams to align on what to commit to next. But pay very close attention to what you’re committing to. Don’t commit to features, but commit to outcomes because this will leave enough room for creativity.

Planning itself is a means to an end.

The goal isn’t to have a rigid plan on what to deliver and when but to have an alignment on what to pursue and how to deal with dependencies. Flexibility is essential to create value faster.