In this article, we will cover the activities that take place during the Product Increment or PI Planning Event and How to facilitate it.
We will start with highlighting the schedule of PI Planning first and then we will look at an example PI Planning Board and how we use it during the facilitation of the event.
The PI Planning event is typically 2 or 3 days depending on each organization.
In my experience, a 3-day planning is better because teams have more time to break down the work and to discuss any risks and challenges they might encounter.
The event starts with Business Context from the leadership. In this session, leadership usually provides an overview of the ultimate goal and the motivation of the organization for why they are pursuing it. This should be a positive message that motivates the teams.
Next, a high-level Product or Solution Vision is presented by the Product Manager. They also quickly highlight the prioritized features they would like to work on for the next 3 months. Keep in mind that at this point the features highlighted are aspirational and not a commitment.
Next, the Architecture Vision is reviewed by the System Architect or technical lead. This might be a high-level technical approach or an overview of an existing platform they want to build on and expand its capabilities.
Next the Release Train Engineer (RTE), provides an overview and explains the Planning Context and process for the next 3 days. In this overview, the RTE shared the entire schedule and expectations for each session.
All the sessions mentioned represent the introduction of the PI Planning and everyone joins them, this means all the agile teams, stakeholders, and the program roles.
After lunch, all the teams split up in different team breakouts based on the features they need to tackle. Usually there are 1 hour sessions for each feature that needs to be worked on and they can be tackled based on their priority. Different teams will work on different features depending how each ART wants to split the work.
The schedule could look something like this.
The schedule of the team breakouts that includes which teams join each session and the time for all of them is all figured out ahead of the event. It’s usually done with all the leads together because it requires collaboration and it usually turns out to be a pretty large schedule matrix. When creating the team breakouts, you also have to consider which business stakeholders are needed and any other dependent teams and make sure there are no conflicts in their schedule. Without participation from the right people, the teams might not be able to properly break down the work for that specific feature, which defeats the purpose of the entire planning event. I recommend the details of the schedule to be confirmed with all parties involved ahead of the event and get confirmation of everyone's commitment to attend the sessions.
During the team breakout, teams use a PI board. During these sessions, they break out the large features into smaller user stories and they list them in the chronological order from left to right across the iterations. They can also mark the dependencies across the user stories or other teams if needed. By the end of the session the team should estimate each user story. Usually this is done in story points. Team should have an idea of their capacity in story points per each iteration. That way, they can commit to user stories for each iteration based on their own team capacity. The capacity should be figured out based on historical data and also take into consideration any team members' vacations or holidays. Teams can mark any milestones at the top of the board.
At the end of Day 1, the teams should present a draft plan for review based on their planning up to that point and highlight if they have any major risks or impediments as well.
The first day should end with the RTE getting all the leads and management for a review and problem solving session. During this session any challenges, risks or impediments are discussed and adjustments are made for the next day of planning if needed.
If we assume a 3 day event, day 2 starts with a quick 30-minute session that goes over any planning and schedule adjustments. After that, teams split into their breakout sessions again until lunch time. After lunch they continue with team breakouts. They end day 2 with a draft plan review for that day and if needed they have a management review session just like they did on day 1.
On the 3rd and last day of PI Planning, the teams get together to finalize their plans and get ready to present them to everyone. During the final plan review all teams summarize all their user stories and features into PI Objectives. Objectives are business summaries of what each team intends to deliver in the upcoming PI based on their capacity. The objectives usually map directly to the Features in the backlog. They should also list out any uncommitted objectives, which is work the teams have low confidence in completing.
After all plans have been presented, remaining program risks and impediments are
discussed and categorized. This is usually done using a ROAM board which covers Resolved, Owned, Accepted and Mitigated risks. At the end of the risk discussion, teams do a confidence vote. They vote from 1 to 5, with 1 being no confidence in the plan and 5 very high confidence. Any low confidence vote might require rework of some of the plan.
The PI Planning ends with a retrospective on how the entire event went and how the teams can improve the event for the next PI Planning.
With that we end our Day 3 and the PI Planning event.
Comments