How to Facilitate a Successful PI Planning Agenda
In the last article, we talked about why PI Planning is so “magical” and how to prepare (there’s an art) for PI Planning. We continue the conversation with Enterprise Transformation Coach David Gipp and dive into the PI Planning agenda, how it’s similar to other Agile events, facilitating for the best outcomes, and if SAFe is flexible enough to accommodate a request that comes in the night before the event.
How much do you refine and plan during PI Planning?
We always want to plan enough to know that the work will fit in the PI, but we do not need to discover each individual story, even coming out of the PI planning event. We will discover approximately 50% or more of the work, in story form. In the near-term iterations, we’ll know exactly what we’re doing. The farther-out iterations might only have a few things in them, and the very last one may have nothing in it because we know that we’re going to discover new things along the way. There is a ratio between the work we want to know going into it versus leaving some room.
Is PI Planning like Sprint Planning on steroids?
In some ways, you can think of it like that. Let’s talk about the ways it is similar and then we’ll talk about the ways that it’s not.
In the ways that it’s similar, you’re still making a commitment over a time box. In a sprint, you’re making the commitment to complete certain stories within a sprint. In PI Planning, you’re making a commitment (more later about voting on it) to what features and objectives you can commit to during that PI and which ones you cannot.
What’s a little bit different about PI Planning is that we’re still maintaining flexibility on how we’ll get to those features. A lot of things can happen in a quarter. As planning progresses, you can discover some interesting things that can completely change your idea of what features are going to be talked about that day.
As a coach, have you seen that happen?
I’m sure every coach has seen this. It can be very common that once you get everyone talking together you’ll occasionally have surprises. That might mean that a feature you initially think can accomplish is not doable by a certain milestone or release. The ability to accommodate change is built into the system. PI Planning is two days for a reason.
On the first day, we’re doing divergent thinking, we’re examining the solution and we may need to change our thoughts. If we end day one with some unmet expectations, we can use day two to recover and adjust our plan. We may intentionally decide to deprioritize something in favor of another. We may also decide that now is not the right PI to do a particular thing because of the risks that we uncovered, or have a very fast-moving item that needs to jump up in priority. This happened to us in the last PI, we had a legal-related feature request come in the first day of the event so we adjusted the PI plan to accommodate it. That is the beauty of the event being two days. If you only do one day, you’re not going to get the value of being able to adjust your plan.
Two days sounds like a long time and also not a very long time at all, especially when you’re trying to account for the fact that there could be hundreds of people in one room with possibly competing priorities. How do you facilitate? Do you have any tips or advice?
It is a big time investment to bring that many people together in a room. Sometimes we’ll hear leaders say, “why would I bring 90 developers into a room for two days?” To answer that question, I like to point out that the developers are still doing something for those two days. Is their time better used sitting in a cubicle not talking to each other? Or is their time better used talking to each other?
It’s the amount of conversation that happens in those two days that make the investment 100% useful. Those conversations would take weeks or months to happen if they were to have them individually. So that’s what we’re doing, we’re actually saving money by having all those conversations together and we’re not we’re not spending anymore, because it’s two days wherever you sit.
There are some very clear results that we’re looking for and the schedule for the two days is designed to drive maximum value. It’s way more than just getting in a room and talking for two days. It’s the RTE’s (Release Train Engineer) job to maintain that schedule.
So the RTE is the emcee??
Yes the RTE is definitely the emcee, the conductor of the train. It’s very common, especially on a new train, for coaches to help emcee. At some point, the coach will move to the back of the room and hand off the leadership.
Is there any room for a third day?
I’ve seen it go to a third day, but only unusually large groups or dynamic pivots (Covid Pivot is a good example) would cause that need. It’s actually preferable to push through and get to a plan that passes the vote. Just letting the event end with major unsolved problems will always catch up to you.
How do you know PI Planning was successful? What are you looking for?
We’re looking for confirmation that the teams can commit to doing a certain number of features. We want at least a rough plan of what features will be accomplished iteration over iteration .
We care less about the number of stories; that’s not a health metric coming out of PI planning. One success criteria we’re looking to get out of the event is for each team to understand the feature(s) and how they will be contributing (the team objective).
So in the process of communicating objectives, there might be concerns. We might hear, “I’m not sure if we can make that we’ve got a risk of some sort.” We’re looking for risks to be exposed. If we come out of PI Planning with no risks, then we haven’t done enough talking.
So to know if the PI planning was successful, we should have team objectives, identified any risks, and have created a dependency map, also known as the program board.
What does the program board show?
[The board shows] when everyone needs each other*. We need that in order to do releases, so coming out of the PI Planning, we’ll know exactly what the releases will look like and all releases will be confirmed for the program increment we’re talking about.
By confirmed, do you mean they’ll have dates?
We will, hopefully, know almost to the day, when each release will be ready. If there’s an existing release cadence, we’ll know which one we can fit in. That’s usually by the day. If we’re releasing with more flexibility, we will have chosen a date, or at least a sprint or an iteration to release it. Sometimes you can’t choose the release date due to an immovable timeline or event. Features required for the Olympics is a good example that I’ve actually had to work with. The teams in that case needed to scope their work to a date vs pick a date.
But sometimes you can choose between multiple release options, and you make that decision during PI Planning.
Sounds scary.
Well, that brings us to the vote. The most important outcome of PI Planning is that we’ve reviewed our plan and everyone agrees on the plan. During PI Planning, every team shares their team objective and how they will contribute to the features and their team objectives. However, teams do not share the details of every story. In fact, if someone is beginning to explain their plan, and they’re talking [about every sprint], we usually stop them. [We ask] the teams to give us the elevator pitch: What are you contributing to the features? How will that work be done? What are the risks?
The elevator pitch should be given in non-technical language. There can be some technical language but everyone in the room should be able to understand each team’s plan.
Now, that brings us to a very, very interesting component of PI Planning, the vote. Some people wonder who’s voting… It must be the teams just voting on their plan, right? No, everyone who has heard the plan, votes. It makes for a very interesting form of peer review.
So each team will stand up and say: “This is Team Rocket Ship. We’re going to be contributing to this feature by x and here are the risks.” Then people vote?
We hear all the plans in sequence so we can build a complete picture. If you plan your pitches and readouts correctly, a very nice story develops.
So, each team is a car on the train, each car goes in sequence, and by the end, you should have objectives from the first car to the caboose?
Yep. Anyone that’s heard [all of the objectives] gets to vote on the validity of what they heard. Some people think that teams are just voting on their part of the plan but by the time they’re explaining their plan, they should already believe in it. You don’t present a plan that you don’t believe in. The real question is, do you believe in the plans of other teams?
This exposes some very interesting moments. I’ve heard teams out of concern say, “No…I’m worried about you guys. You said you could complete those features but you have all the work planned until the end of the PI and I can’t confidently vote that I think you’ll be able to accomplish that without personal sacrifices like long nights. I’m worried about you.”
From an empathy and culture standpoint, that’s an awesome conversation to have.
When does the vote happen?
Everyone hears the plan and then we take a small breather. I’ll usually ask for everyone to stand and pass out some mics. Then on the count of three, everyone holds up their fist to five.
We’re looking for threes and above. We will pass the mic to the twos and the ones to hear from the people that are low. The best way to facilitate this is to not have a coach talk to a one or a two, but to have a five talk to a two. Sometimes, the conversation between a low score and a high score solves it. “Oh, you’re so confident because we have the new library. I’m confident now too.” If we have any sticking points, we take those as leadership actions and might have a quick pause to see if we can solve them immediately. If we can’t solve them, we might have some more reprioritization to do. Most of the time, we can come up with a way to become confident in the plan.
Does every vote count equally?
We want to promote that every vote is equal and support anyone who’s willing to vote a two or a one. Those are the people that I will go stand right next to so that they don’t feel alone. I’m never comfortable when you’re having a confidence vote that is all fours and fives and you escape without discussion. That’s not the point. You need to be sure that you’ve examined [the plan] and that means someone’s got to play that person. We make [the environment] safe going into the vote. If you really want to vote a two or three, we’re looking for you to help expose risks.
*A program board shows dependencies between the work and people. There’s a lane for each team, and the board show major dependencies along the way needed to deliver each feature.
In the next and last article of the series, we’ll talk online vs onsite PI Planning, the importance of fun, and share examples of how an airline took their PI Planning events to the next level.
Read the whole series:
If you’d like to learn more about how our SAFe services like facilitating PI Planning drive to outcomes, click here.
Leave a Reply