Responding to change rather than following a rigid plan is one of the main points of the Agile Manifesto which states that there is more value in developing software by responding to changes than by blindly following a predetermined plan.
Nevertheless, the planning process is a crucial element as it allows us to determine what is feasible and what is most valuable to the business in the upcoming weeks.
What is PI Planning?
PI Planning (PI Planning – Scaled Agile Framework) is an event attended by all ART (Agile Release Train) members. It’s a key moment allowing everybody to get to know and understand the strategy, vision, plans, and needs. Program Increment Planning allows us to jointly plan all the upcoming iterations to deliver the most optimal solution for the customer. It’s a timeboxed, 2-day event where the teams, product managers, and stakeholders are focused on analyzing the product backlog to decide on the direction the business is taking. This time must be used effectively.
How do you prepare for PI Planning?
For Agile PI Planning to be effective, we need to prepare for it properly. Let’s group the positive and negative aspects when we refer to the amount of time we dedicate to the PI Planning preparation.
| Less time spent on PI Planning preparation | More time spent on PI Planning preparation | |
| Negative | * Lower quality of tasks during PI Planning * More unexpected occurrences during PI Planning | * Potential waste of time and resources if requirements change during PI |
| Positive | * More time can be spent on innovation, education, or improvement of existing applications | * Efficient collaboration during PI Planning as almost everything is clear and understandable * Improved task quality * Fewer dependencies * Better understanding of customers’ needs |
Now that we know the consequences of both too little and too much planning preparation, let’s see what’s needed before the effective Agile PI Planning event.
What is needed before the Agile PI Planning event?
- Availability — Program Increment Planning is an essential event in the Scaled Agile Framework, which involves mutliple teams, multiple product managers, and many stakeholders. Before planning the event, make sure that everyone that needs to be there is available. It is paramount that this event is attended by everyone that is part of the Agile Release Train.
- Roadmap — The product management needs to establish the vision for the upcoming Program Increment before the PI Planning Event takes place. If this is not in place, those attending the PI Planning session will encounter multiple roadblocks.
- Technology — No matter if you’re running the PI Planning event onsite or online, you need to think of the tools and premises required to accommodate the event. In case the team is spread out across the globe, you can try our PI Planning template to get everyone on one board in real time, no matter where they’re physically located.
7 sins of Agile PI Planning, most common anti-patterns.
1. Product management does not provide a vision or roadmap
Program Increment Planning consists of three inputs:
- Top 10 features
- Vision
- Roadmap
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.
2. 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.
3. 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:
- Calculation of available vehicle payload level
- TOP 10 most frequent routes
- Calculation of the possible distance to battery level
- Automatic return to base after delivery
4. 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.
5. 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.
6. 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.
7. Omitting planning retrospective
PI Planning is an intense process and often makes ART members feel like unwinding and going to the hideaway after the final plan has been agreed upon. It creates a temptation to give up on the Retrospective.
This approach makes us fail to improve the quality of our planning and deepens notorious bad habits. The Retrospective is crucial to plan smoothly and optimally.
How to run a PI Planning event on Whiteboards
Insert a ready-to-use template on your board.
Whiteboards.io offers you plenty of tools and templates you can use for various Agile events. With the PI Planning template, you can host your product increment events with many stakeholders, developers, and project owners to share the same vision and goals for your product.
Prepare at least ten features you plan to develop during the PI Planning session.
Ask the Program Manager to prepare a list of up to ten features your team should develop further or from scratch. Choose the most salient elements that could help your customers use your tool more efficiently based on your market or competitive research.
Calculate your team’s capacity.
With your Scrum Master, check the capacity of each team for upcoming sprints. Remember to exclude such events as team members’ PTOs and public holidays. Do the math, excluding SM and PO roles.
Decide what your team should work on.
Take a look at the features your Program Manager selected in the Program Backlog and choose the ones your team could be responsible for. Add them to the appropriate board dedicated to your team.
Divide epics into stories.
While keeping your team’s capacity in mind, go through the list of features your coworkers should focus on. Treat the features as epics and split them into smaller tasks, so-called stories. Add them to appropriate sprints on the table and estimate them. Use the voting feature for estimation or consider the dot voting method.
Craft your product increment objectives.
Hop on a discussion call with your Product Owner and discuss the goals of the PI Planning session. Be clear and concise, and mark what business and actual value they bring to your organization.
Spot possible risks.
Look at the dark side of feature delivery and list potential risks your team could meet along the way. Place your concerns on sticky notes to discuss later with the entire group.
Resolve, Own, Accept, and Mitigate the threats.
Take risks your team spotted and add them to the ROAM table. Determine which risks qualify as risks for the entire organization.
Conclusion
To err is human, but to persist in the mistake is diabolical.
Lucius Annaeus Seneca
The SAFe PI Planning framework gives us a rich set of practices and tools that we can sometimes use in a different way than the author intended.
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.
