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.
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:
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.
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:
Now let’s address the how-to question in depth during the next part of this post.
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:
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.
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:
| Activity | Time (minutes) | Description |
| Goal setting | 10 | The head of products (or responsible) sets the session’s goal and why the team is together. |
| Icebreaker | 15 | The session should be as interactive as possible. Help people arrive at it and be fully present. An icebreaker can get this job done. |
| Set the stage | 10 | The head of products (or responsible) reviews the product vision and strategy and shares the eventual change of direction. It’s essential to make it clear why the strategy helps the teams progress. |
| Connecting the dots | 10 | As everyone is on the same page, it’s time to review the status quo and point to the future. |
| Ideation | 90 | Let the teams divide into groups of four or five people and ideate on which goals they could commit to for the next quarter. The goal should be related to the vision and strategy shared previously. |
| Sharing | 30 | Each group presents their results and makes them visible on a board. They may answer questions to ensure understanding, but there should be no discussion on whether the goal is meaningful. |
| Clustering | 30 | As everyone had the chance to present, some ideas may be highly related. Clustering them is an excellent way to simplify prioritization, and naming the cluster will facilitate the next step. |
| Deciding | 30 | Now it’s time to decide what to commit next. These decisions should be high-level, and then the team sharpens the goal. |
| Sharpening goals | 60 | As the direction becomes clear, the teams formulate them better. You can use product goals, roadmaps, or whatever format you are familiar with. The magic happens when you define the outcome you want to achieve instead of the output. |
| Review | 15 | Such sessions can be exhausting. Leave some minutes to review how the participants experienced the collaboration and result. This will help you improve for upcoming sessions. |
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.
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
CPO and PhD Jen Wang covers “The Zone of Absorption” and why product teams are struggling to build when AI is shifting faster than anyone can keep up.
Explore four product team structures, when each works best, and how to choose the right model for speed, ownership, and clarity.
Learn how code-style reasoning helps product managers make sharper decisions, surface edge cases, and write clearer requirements.
A practical framework for product leaders to prioritize better, reduce noise, and focus teams on what matters most.
Learn more →
