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?
- What is PI planning vs. sprint planning?
- How modern PI planning works
- How to prepare for PI planning
- Running the PI planning
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:
| 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.
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.
The post What is PI planning in agile? appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/NW7QnVr
Gain $200 in a week
via Read more
