Top 12 mistakes to avoid during PI Planning
Dr.Abdur Rahman Author,ICF-PCC,SPC,AWS-SA,ACP,CSM,CPO
SVP Agile & Data Transformation & Delivery
If you can identify the potential pitfalls of PI planning, you have a better chance of avoiding them. Don’t fall prey to these common mistakes:
1. Skipping or not prioritizing PI Planning
Scaled Agile, Inc. ?says that “PI Planning is essential to SAFe: If you are not doing it, you are not doing SAFe.” This couldn’t be more true!
PI Planning is an absolutely essential aspect of SAFe, and there’s no scenario in which it should be skipped or undervalued. Failing to effectively run a PI Planning meeting can have dire consequences for product development.
Work inevitably gets busy, and when product development falls behind or roadblocks come up, something has to give. However, no matter how tempting it may be, never allow your PI Planning to get pushed, delayed, scaled back, or skipped altogether.
Set your PI Planning date well in advance and stick to that date to ensure everyone can be available and prepared.
2. Failing to thoroughly plan in advance
Pre-PI planning is essential to the success of your event. You’ll have limited time as a group, so it’s essential that you use it wisely once the time comes.
Plan the date well in advance to ensure everyone can attend and access planning materials. Before your upcoming PI, make sure your?backlog items are refined ?and ready so precious time isn’t wasted during the PI event.
3. Running long or boring sessions
PI Planning often includes long and heavy sessions, which can kill the vibe and stifle creativity and problem solving. ??
Do all that you can to engage the team and keep sessions short. This can help a team participate more, invest in the session, and problem solve more effectively. Look for creative ways of running sessions that engage more than just the energetic few. Carefully consider timelines, and ensure no session runs too long to prevent boredom or wasted time.
4. Allowing remote restraints to stand in your way
There may be different challenges with running PI Planning remotely. But with advanced planning and the right tools, you can run a successful planning session no matter where your team is located.
Don’t neglect your PI Planning because your team is remote or temporarily working remotely. There are plenty of tools that can help remote teams engage online with team breakouts, video conferencing, online sticky notes, and?PI Planning plugins .
Virtual breakout sessions are essential to ensuring the right people can engage at any given time and that no time is wasted. Carefully plan your remote PI Planning to ensure everyone is prepared and knows where and when they need to participate online.
5. Missing out on retrospective insights
Not to sound like a broken record, but?retrospective ????? insights ???? are ???? important ????.
We know there’s only so much time allocated for PI Planning and so much to get done, but you need to make time for a short retrospective. Otherwise, you’ll never truly learn how to improve. A post-PI Planning session will allow your team to discuss the planning event, including what went well, what didn’t go well, and what could be improved for next time.
Make sure you record retrospective insights and implement important ideas into the next PI planning meeting. After all, it wouldn’t be agile if you didn’t continually try to improve your systems.
7. Product management does not provide a vision or roadmap
Program Increment Planning consists of three inputs:
The lack of a vision and roadmap will result in all Agile Release Train members not being able to estimate the delivery of the specified features. Without the roadmap, we’re losing the context and the team doesn’t have a clear outline.
Additionally, the vision allows the entire ART to focus on one direction. That is why it is so important not to skip this element in preparation for PI Planning.
8. Planning tasks for the IP Sprint
The last sprint of each Program Increment is called an IP Sprint (Innovation and Planning Iteration – Scaled Agile Framework ) (Improvement & Planning Sprint). During this sprint, teams have time for making improvements, learning, refining quality, preparing for planning, and the planning itself.
A common PI planning anti-pattern is that teams plan tasks for the IP Sprint instead of leaving them empty, i.e., Load = 0. It is important to give teams time and opportunity to gain knowledge, innovate, and prepare for the PI Planning. This approach increases quality, commitment, motivation, and reduces errors.
9. Features Considered as Objectives
It very often happens that teams treat the features (Features and Capabilities – Scaled Agile Framework ) they receive from Product Management as their PI Objectives (PI Objectives – Scaled Agile Framework ). It creates confusion and challenges in understanding what business value each team fulfills when several teams are required to deliver a feature.
Therefore, the SAFe?PI Planning framework recommends collaboratively working out the team’s PI Objectives containing clearly defined value with the Product Owner. Below you’ll find an example of a feature and PI Objectives which are a part of that feature. The team does not have to deliver the entire feature itself but only its components that add up to the overall feature.
Feature:
Autonomous delivery from point A to point B
PI Objectives:
10. Load in Sprints Equals the Capacity
If we don’t leave ourselves a buffer for unexpected situations during a sprint, we will naively believe that everything will work out the first time. Since every team is different, it is best to empirically assess what capacity value works best without letting too many tasks to be carried over to the next sprint. However, in the beginning, you can assume that Load should be a maximum of 70-80% of available capacity.
11. Business Value — 10 for All
The purpose of defining the Business Value is to show the team which Objectives are crucial so they can properly prioritize their activities. We can’t allow the Objectives to be equally important. A good tip for the Business Owner(s) is to first think about what PI Objective will bring them the most value and identify that as 10a and then identify the other PI Objectives.?
12. Averaging the Confidence Vote
A Confidence Vote is used to assess the team’s belief in the final plan. It is important to get to know the rating of each team member. For example, if votes look like this: 5,4,3,2,2,2,?it means that three people do not believe in the plan and it is necessary to approach the planning again.
The average result for such a voting session gives us Confidence Vote = 3, thus we might mistakenly believe that the planning can be completed and there’s no need for rework.
Conclusion
It’s impossible to avoid mistakes, but it’s important to identify and eliminate them in future iterations. Retrospective can definitely help us, both at the team level and at the level of the whole Agile Release Train or tribe.