A Guide to Program Increment (PI) Planning: Why PI Planning is the greatest tool you can have

When it comes to PI planning using a scaled Agile framework, some of the main questions people have are:  

• How am I supposed to plan 3 months’ worth of work? 

• Isn’t the point of Agile to be more flexible, plan constantly, and in iterations? 

The answers to these questions may be confusing to people who do not have experience with scaled frameworks.

In short: Yes, you can plan 3 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 PI Planning?

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 an 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 blog covering PI Planning, but what we want to focus on here at Gorilla Logic is the tricks that we employ to make PI Planning a successful event that will provide organizations with value and a clear vision of the future.

Why is PI Planning important?

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. When you live by only planning every two weeks, it 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.

Now, the keyword here is “enough” data. The first major mistake companies make when they execute PI planning 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 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 recalibrate the plan as needed every Iteration Planning, equipping them with a better shot of delivering what was committed to at the end of the PI Planning event. It also allows product managers and product owners to rectify in terms of product vision, assuring that they are delivering a product that provides the most value 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. 

The team can focus on writing code

If the PI planning event 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?

Allows teams 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 forces teams to think ahead and allows them to ask those hard technical questions at the beginning, reducing the reaction time during the PI and again, preventing the teams from getting stuck in those annoying blockers.

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 train and the company.

Helps allocate time 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 later included in the final product. This also helps team members feel like their work matters and that they are part of something bigger.

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.

Best practices to help you execute PI Planning the right way

There are tons of articles that you can read about how to do PI Planning and what the agenda is supposed to look like. But here 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 being followed. Keep track of the break times and, if at all possible, use a stopwatch for breaks and different activities. This will set the expectation to everyone participating in the planning process.

2. Add the right information to the agenda: Creating an agenda 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 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 a check on the time, and allow the members of the train to understand how much time they have left.

4. Keep in sync: The PO sync up meeting and the scrum of scrums are not only for the execution of the PI. Use these kinds of meetings constantly during breakout sessions to make sure that the teams and their members are doing well, that everything is on track, and most importantly, always communicate the management expectations to the teams, and vice versa. 

5. If you need more time, use more time: 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. It is always better to invest a little more time during this exercise, as it could be the difference between a good plan and a bad one. 

6. Provide time to rest: These types of activities tend to 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 ART 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 we will be 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 features. After all, we are committing to objectives and 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 to mention it here. The trick here, if there is any, is to start the PI Planning retrospective with the action items from the previous PI planning’s 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 the software development industry, 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, 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, as we saw earlier in this article, will bring tons of benefits to our day-to-day. So, 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.

That being said, PI Planning is a very powerful tool that mature Agile teams can use to become more predictable and provide the organization with more accurate and precise estimates that can definitely help the company in their efforts to achieve their strategic 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.