A Guide to Agile Program Increment (PI) Planning
When it comes to Agile PI Planning, some of the main questions people have are:
• How am I supposed to plan three months’ worth of work?
• Isn’t the point of Agile to be more flexible, and plan constantly and in iterations?
The answers to these questions may be confusing to people who do not have experience with scaled Agile frameworks.
In short: Yes, you can plan three months’ worth of work, and yes, you do iteration planning every other week (every iteration). That is how we stay within the cone of uncertainty and get closer to the optimal solution we are looking for.
Now, I know that sounds like a salesperson’s answer… and it kind of is, because I’ve seen the product, and I believe in it. But can we go deeper into what PI Planning is and how it works? Absolutely.
In this article, you will learn what PI Planning is, what the benefits of PI Planning are, and discover some best practices for how to do PI Planning well.
What is Program Increment (PI) Planning in Agile?
Program Increment (PI) Planning, following the definition provided by Scaled Agile®, “is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and vision.”
But what is a more practical definition? PI Planning is nothing more than a planning event that happens every few months (usually once every quarter), wherein all the teams working within a single Agile Release Train get together to plan the work that is going to be coming down the pipeline for the next few iterations (usually 6-7 two-week iterations).
Everything I just told you could probably be found in any article covering PI Planning, but what we want to focus on here at Gorilla Logic is the tricks that we employ to make PI Planning meetings a successful event that will provide organizations with business value and a clear vision of the future.
Why is PI Planning important for Agile development?
Well, the answer to this question can usually be found when talking to stakeholders and VPs. Imagine a major stakeholder, that person who is in charge of allocating budget or planning for a major product release. When was the last time you heard that type of stakeholder say, “I LOVE planning two weeks at the time”? Probably never, right? Because there are positions within every organization that need to plan ahead. Planning every two weeks may be great on the team level, but as we move up in the different levels of an organization, the need to forecast deliveries and releases becomes more and more important. This is precisely why PI Planning is so important; it helps teams provide enough data to certain sections of the organization, allowing them to move forward with their roadmaps, while the delivery organization (ARTs) can focus on actually writing code and delivering value to the customer, and the business.
Now, the keyword here is “enough” data. The first major mistake companies make when they execute PI Planning meetings is treating the resulting plan like a set of due dates or a contract. A better way to look at this plan is as a set of objectives that the teams are committing to. The difference resides in the fact that you can indeed achieve an objective without completing 100% of the product features or user stories.
If everyone in the organization understands this, then the framework does not force the teams to lose flexibility. In fact, it provides a lot of tools for the teams to use to recalibrate the plan as needed every Iteration Planning. This gives them a better shot at delivering what was committed to at the end of the PI Planning meeting. It also allows product managers and product owners to rectify the product vision, assuring they are delivering a product that provides the most value to the customer at the time of its release.
What are the Benefits of PI Planning?
This is a question I get a lot in initial engagements with clients, and the answer is always a lot easier than people may think: The benefits of PI Planning will be evident during the executions of the iterations.
1. The team can focus on writing code
If the PI Planning meeting was executed correctly, then teams will follow a cadence that will maximize the time they spend writing code. I have seen teams do iteration planning for a day before they can start a sprint. With well-done PI Planning, your iteration planning shouldn’t take longer than 30 minutes. Imagine not losing an entire day of your sprint by planning it. Sounds pretty great, huh?
2. Teams are encouraged to think ahead
There are concepts like TDD (test-driven development) that establish that every developer should think about how they are going to test something, even before they start writing code. The same applies to the plan. PI Planning empowers teams to think ahead and allows them to ask those hard technical questions at the beginning, reducing the reaction time during the PI Planning meeting and preventing teams from getting stuck on those annoying blockers.
3. Everyone has a voice
Let’s be honest, us tech people may not always be the most articulate or eloquent when it comes to expressing our concerns or ideas. But during PI Planning, we are all working together, using tools that allow us to provide good feedback, apply everything that we learned during innovation time, and provide value to the solution train, the company, and ultimately, the customer.
4. More time is allocated for innovation
When you have the time to plan ahead, it makes it easier to be more proactive. PI Planning allows teams to allocate a sufficient amount of time to innovation. Even if it is just one week, team members are able to play with sandboxes, build Proofs of Concept, and try new technologies that can be included in the final product. This also helps team members feel like their work matters and that they are part of something bigger.
5. Health check for the entire train
What I love the most about PI Planning is the fact that it makes it a lot easier to understand the mental state of the teams. During breakout sessions, the focus goes to the team level, and team member interactions can provide a lot of good indicators on whether we are over-committing or if there is something wrong with team dynamics. Either way, it is always better to catch these kinds of situations sooner, rather than later.
How do you prepare for PI Planning? Best practices to help you execute the right way
At Gorilla Logic, we have identified a handful of best practices that can be the difference between making your PI Planning a success or a waste of everyone’s time.
1. Create an agenda and stick to it: Creating an agenda is likely not the hardest part of the PI Planning process, but sticking to it can be. As an RTE, always make sure that the agenda is followed. Keep track of the break times and, if possible, use a stopwatch for breaks and different activities. This will set the expectation for everyone participating in the PI Planning process.
2. Add the right information to the agenda: Creating an agenda for PI Planning is a fairly simple task, but creating one that provides the right information to the right people can be a little challenging at times. Making sure that the right information is presented to the right people is the key. Business context doesn’t have to be a deep look into the strategic vision of the company, but make sure that the message is clear and easy to understand. Always remember that most of the people involved in this activity are highly technical.
3. Provide enough time to complete the tasks: A PI Planning session is not going to work if you have people rushing to complete the boards or the team’s backlog. Make sure that you provide enough time for breakout sessions, always keep track of the time, and allow the members of the train to understand how much time they have left.
4. Keep in sync: The Product Owner sync and the Scrum of Scrums are not only for the execution of the PI Planning event. Use these kinds of meetings constantly during breakout sessions to make sure that the teams and their members are doing well and that everything is on track. Most importantly, always communicate management’s expectations for the teams, and vice versa.
5. Use more time if you need it: Most people think that PI Planning needs to be completed in two days, but what if we use three days instead? Is that so awful? The truth is that this is not a problem at all. If needed, plan for a 3-day PI Planning event. It is always better to invest a little more time in this exercise, as it could be the difference between a good plan and a bad one.
6. Provide time to rest: PI Planning meetings can be stressful and exhausting, so make sure that you have enough breaks during the sessions to allow people to walk around, get some coffee, or just chat with their friends.
7. Use the right tool for the job: People used to think that the only way a PI Planning event would work was if we had the entire Agile Release Train in the same room. Well, the COVID-19 pandemic revealed that it does not have to be that way, as long as you have the right tools for the job. Using Zoom and its breakout rooms along with some team-oriented software such as MIRO could take care of the problems and allow everyone to stay connected and have the ability to participate without having to be in the same room. Just keep an eye on those breaks. When doing PI Planning virtually, those breaks could be even more necessary.
8. Do not get caught on the plan: Sure, the plan is important. But remember, we will review it every two weeks, which means it is okay if we do not get it right the first time. We will be adjusting every iteration planning and getting closer and closer to building the right thing the right way, so do not get too fixated on the details for user stories and product features. After all, we are committing to objectives, not user stories.
9. Inspect and Adapt: I know this is not a trick itself, since it is a detailed activity that takes place during the planning retrospective, but it is so important that I decided I had to mention it here. The trick here is to start the PI Planning retrospective with the action items from the previous PI Planning retro. This way, we make sure that someone is doing something about them. We can also ensure that any changes or improvements we need to make to our process are talked about and added to the next version of our PI Planning. Usually, the RTE is in charge of making sure that it happens or that, at least, all the items have an owner.
10. Do it: This is probably the most important trick of them all. Try it and improve upon it. PI Planning is not a silver bullet or the solution to all the problems we may have in Agile software development, but I have noticed that the main problem companies have with a scaled Agile framework is that they simply do not try it. Sure, we all read about it, and we see the videos and the tech talks, but the fear of not getting it right the first time usually stops us from getting into a process that will bring tons of benefits to our day-to-day. Our advice here at Gorilla Logic is try it, improve upon it, find a process that works for you, and iterate. It will work.
Always keep in mind that scaling your framework is not just another step in your evolution as a software development organization. It is imperative to measure the health of the Agile teams before scaling up. If you intend to scale an Agile implementation that is not in good shape, you will end up with a bigger, scaled version of that implementation.
Agile PI Planning: In conclusion
PI Planning is a very powerful tool that mature Agile development teams can use to become more predictable and provide the organization with more accurate and precise estimates that can definitely help the company in its efforts to achieve its strategic business goals. So take it seriously, allocate the right effort and people to getting it done, and, most importantly, always remember to have fun while doing it.
