Who wants to join the PI Planning Committee?

… was the question that came one day from our Engineering team at Socialbakers. I had no idea what PI stands for, but it sounded interesting and I like planning. Count me in…

And so the PI Planning committee was established with representatives of the Engineering team, Design Team, and Product Team to do all the preparation and materials for the meeting.

But first thing first — what is PI Planning? PI Planning stands for “Program Increment Planning” and it’s a part of the Scaled agile framework. (It’s something like scrum for multiple teams who work together on the same product). It’s two days meeting helping companies with bigger development team to:

• communicate the priorities from the product team
• define the dependencies across the development teams to avoid potentials problems
• increase the visibility of the work, show the Program Increment for next quarter

In nutshell, it’s a meeting where everybody meets and plans the upcoming quarter (or half of the year) to deliver the right features at the right time. The goal of PI Planning is to get all your teams aligned strategically and enable cross-team collaboration to remove dependency problems. Easy to say, harder to do… And that’s why the Committee was established to make sure we have all preparation done.

Meeting preparation

As was mentioned, PI Planning is defined in the SAF framework and has some rules. But at the end of the day, it’s not so important to follow each of the rules strictly. It’s important to manage the preparation and meeting in a way that works for your company, for the teams, and for people to find it beneficial. The ultimate goal is the same for the whole company. This is, in high-level, what we did:

Phase 1:

Committee:

• define the tools for communication, planning & risk boards
• set the dates
• prepare the guidelines for the product team, development teams, technical owners, scrum masters, and others

Engineering:

• organize developers to the teams
• set the team capacity (split between new work, tech debt, unfinished work, bugs etc.)

Product team:

• prepare a list of features and sort them based on the priorities for each value stream
• set the priorities across all product value streams

Phase 2:

Committee:

• prepare the planning & risk boards for the meeting (assign teams, sprints, define the relationships etc.)
• all communication channels are set up
• perform the trainings to everybody involved in PI planning. Each role has its tasks and responsibilities set and clarified

Engineering:

• assign dev teams to each value stream. In case there are more (or less) dev teams than value streams, take values stream prioritization into consideration
• assign Technical Owner, Architect, Designer or any other important roles to each of the feature

Product team:

• prepare business specification for at least two most important features (each value stream)
• meet with the Designer, Technical Owner and Architect to introduce the feature

Phase 3:

Committee:

• organize the PI Planning Rehearsal (it was our first PI Planning meeting so the test was needed)

Engineering:

• technical owners prepare a technical specification for each priority feature

Meeting Day 1

Let the bosses speak! Everybody should be aligned with the Product vision and goals for at least next quarter (Product Boss) and technical scope to support the new features (Engineering boss). Product Managers introduce the top priority features.

Now the work can start! Based on the split to the teams and the feature evaluation, everybody joins their “team breakouts” meeting and starts to work on their Team Board. Each team has a board with sprint columns, that they fill in with sticky notes (virtually) to break down their feature and to estimate the work that can be done approximately in one sprint. Once this is done, the dependencies and risks are identified. Each team contacts other teams that their work will be dependent on and try to synchronize their deliveries.

If the risk or dependency can’t be solved within the teams, the potential issue is marked in the Risk Board. Then it’s up to the stakeholders to set the priorities for the teams, find a solution to mitigate the risk, or simply accept the risk.

At the end of the Team Breakout session, each team moves their high-level sticky notes (Features, Epics) to the Program Board and mark the dependencies to other teams. The stakeholders evaluate the Program Board in order to make sure the high-priority features will be delivered as per the expectations.

The first day is officially over. But the teams can continue to discuss their features or contact others to discuss the dependencies.

Meeting Day 2

Teams digest their plan, risks, and dependencies over the night. Stakeholders discussed the plan and made a decision about the risks in Risk Board. Now it’s time to meet again.

The second day starts with stakeholders informing about decisions that were made or changes that should be introduced to the team’s plans.

Now the teams join their “team breakouts” meeting and look at their sticky notes again. Discuss the features, ask questions to the Product team, connect with other teams, etc. in order to increase their confidence in the plan they did so far.

(It’s important to mention, that PI Planning is not a grooming. It’s expected the plan may evolve in time, but the teams try to minimize that as much as possible.)

If needed stakeholders evaluate the risks and dependencies from the Risk Board again.

At the end of the PI Planning session, each team votes from 1 to 5 to express their confidence with the planning. For example, each team member raises the hand with fingers showing the number. If the team average is less than 3 the team needs to get back to the board, revise the sticky notes, the planning, and the risks.

And the work is over… As a last step, everybody gets together again to hear from others about their confidence in the Program Board plan and to wrap-up the two days meeting.

Good luck with your own PI Planning meeting!