The SAFe Scrum Masters' Guide to Successful PI Planning

Great PI Planning doesn't just happen! In this session, the Pretty Agile SPCT Candidate Claire Sanders shares PI Planning tips from her many years of working on and with Agile Release Trains. SAFe Scrum Masters play a significant role in PI Planning. Check out the video and transcript below to understand how to level up your PI Planning game!

 

 

 

 

Claire Sanders: Thank you, everybody, for making it to this meetup, "A Scrum Master's Guide to a Successful PI Planning".

 

It is lovely to see so many familiar faces and some new faces as well. We are Pretty Agile. We are a gold partner with Scaled Agile. It's lovely to see Rob Howard and Belinda Tee - I saw her - there she is.

 

Lovely to have you here from Scaled Agile.

 

We at Pretty Agile, as a lot of you already know, being our clients, either from a training perspective or from an implementation perspective, you would know that SAFe is what we do day-in, day-out. We specialise in SAFe, and we really don't do anything else. So we know the framework inside out; we hold it very close to our hearts. And what I'm going to take you through for the next hour or so, I will leave time for questions, is the learnings that we've had in supporting teams through PI Planning and coaching our patterns through PI Planning.

 

So, lots of tips and tricks coming your way. And a lot of the goodness that we are going to walk you through comes from these two books written by Em Campbell-Pretty and Adrienne Wilson. These are two amazing books, and not because they're written by our founders, but [there are] just so many nuggets of gold in these two books. So, if you are interested in learning more, I would recommend that you pick up one, if not both of these books.

 

I'd like to introduce the Pretty Agile team. We have Nicholene Africa, Melissa Hay and Emma Sharrock with us here today; hi folks. Em and Adrienne are actually teaching at the moment, and they will join us as soon as they can.

 

I should introduce myself, I guess. I came to SAFe in 2014. I was working at RMIT University, and we had five business cases all approved at the same time. And we thought, "Hey, this might be a great opportunity to try this thing called SAFe." We invited Em Campbell-Pretty to come and teach us the ways of SAFe. She helped us flip that delivery organisation from waterfall to SAFe within a very short timeframe. And we used the Quick Start model, which of course we've used with a lot of our clients on the call today. I have had the pleasure of being a Scrum Master in lots of different organisations across different industries. And I started to see that, there are some things we could be doing to make this easier. That, in consultation with my Pretty Agile friends, is the basis of this meetup talk here today.

 

So, Scrum Masters, as you would know, we've got Scrum Masters on the call. We've got Release Train Engineers. You would know that the lift for Scrum Masters is quite heavy at PI Planning. Yes, the PI Planning event is amazing, and it does really leapfrog organisations forward in a much more significant way than any other way of working. But from a Scrum Master's perspective, it can be quite stressful. You might be feeling worried, anxious, stressed, under pressure, overwhelmed, frantic, all of these things can really weigh down on you as a Scrum Master, as you are in the spotlight and representing your team. But don't worry, it does not need to be this way. John. Hi.

 

John: Hi Claire. I wonder if this session is recorded.

 

Claire Sanders: Yes, it is.

 

John: Yes. And then you will send it out afterwards?

 

Claire Sanders: Yes. More than likely, we'll pop it up on our [web]site. So yes, you'll have access to it.

 

John: Thank you.

 

Claire Sanders: You're welcome.

 

So it doesn't need to be all of those scary things. What we are going to do is walk through the things we can do to prepare ourselves better for PI Planning to set the team up for success. As well as having more organisation and less stress during the PI Planning event. So we're going to walk through all of this.

 

So the first thing I recommend doing with PI Planning as a Scrum Master and also as a Release Train Engineer is to reflect on, what did we learn last time? In the standard SAFe agenda and certainly the agenda of all of our clients at PI Planning, the last thing we do is a retrospective.

 

What was great about this PI Planning event that we want to maintain? What wasn't so good, and what can we improve in the future? Before PI Planning, this is the best time to pull out that feedback and have a look at what your former selves said about PI Planning and what the team said and, indeed what the train said. We recommend levelling this up by, at the end of iteration one, have a conversation with your team about, "We are two weeks in, what is it that we wish we would have known at PI Planning?" Now we're two weeks down [the track], and what do we recognise that, "Hey, we didn't know, and it would've been really great to know so that again, the next PI Planning event can be better." I am not suggesting for a minute that the purpose of SAFe is to get really good at PI Planning, it is not that at all. It is about delivering valuable things for our customers. So, it really is part of the mechanics that make SAFe great.

 

Here is an example of a retrospective I ran with one of my teams at the end of iteration one. I just ran a really simple, Liked, Learnt, Loved and Lacked so that we could surface, what are we now thinking 2 weeks in? This is a face-to-face PI Planning event; remember those? The no laptop rule was good for face-to-face PI Planning. We lacked dependencies being called out early enough. We learnt things like preparation for PI Planning was good, but more discovery is ideal. And we loved the fact that there was good collaboration within the team. So we haven't necessarily surfaced anything earth-shattering, but really helpful when we are looking at the next PI Planning event. Often, what we see is this big text of what's on screen. Hey, we didn't do discovery last time. We really should do discovery. I am also going to talk through the pattern of discovery that we use at Pretty Agile.

 

So, feature discovery, this is the Pretty Agile pattern for what we do at the team level in terms of continuous exploration. It is a lightweight investment in the features that the team is likely to undertake at the next Program Increment planning. There is, of course, no guarantee that the feature we're discovering is going to get prioritised, but we want to understand the upcoming work enough so that we can plan out at PI Planning if it is prioritised. The things we build into our templates with our clients are things like wireframes, acceptance criteria, a solution on a page, and understanding what parts of the architecture are likely to be impacted by this feature. Are we building, buying, extending, decommissioning? All of those decisions at a high level.

 

Our feature discovery also helps us understand if there are any subject matter experts we're relying on to deliver the feature. If so, we want to bring those folks into PI Planning. Very helpful to have those people to collaborate with in order for teams to come out with a plan that they can stand behind. As we go through PI Planning, sometimes feature acceptance criteria need to be adjusted. I've just got a note here to remember to connect with product management and make sure that they are aligned with us in terms of any changes to feature scope and changes to the acceptance criteria because, of course, product management accepts features. So, feature discovery, at its essence, is really about getting at a high-level understanding of a feature, of a piece of work. We want to cover off, what is the customer problem we're trying to solve? What are the things we as a team know, and what are the things we don't know? So that we can chase down those outstanding questions and be in a better position to plan that feature at PI Planning.

 

This is a really collaborative pattern. And as I said is really a lightweight investment into understanding that potential feature. Of course, when I'm using the term feature, I also mean feature-sized Enabler. I'm not distinguishing there.

 

So, in feature discovery and at PI Planning, we strongly encourage drawing pictures. Not because anybody wants to go out on a limb with their artistic ability unless you're particularly brilliant in this space, but what drawing a picture does is it quickly gets us to understand, are we aligned? Are we all seeing the pink triangle? Or are we, in fact, envisaging three different things or more? Drawing a picture really, really helps us to coalesce on our understanding much more quickly. So in discovery as well as at PI Planning, we know that talking at that conceptual level is really tricky for people; drawing a picture takes it out of the conceptual and makes it more tangible.

 

So, as a Scrum Master at PI Planning... You have the benefit of not only being part of the team but also a little bit separate from the team. Sometimes, you'll see that the team is getting overwhelmed. Perhaps we've drawn a picture, and the team feels like, "This is way too much work. We can't get this done." A question you can ask to help is, where is the gold in this feature? Or, if we could deliver just one thing, what would be the most valuable to the customer? This really helps the team focus on value. The “Turn Up The Good” pattern; how we could make this even better is ask these questions with a customer or an empowered customer representative and the entire team so that we build alignment and that shared understanding of, "You know what? Just this part is the nugget of gold; that's the important part of the feature."

 

Understanding team capacity. So PI Planning matches demand with capacity, and we eliminate excess work-in-process, and that's a wonderful thing. However, it only works if we have a realistic understanding of the team's capacity. So, of course, the SAFe guidance for brand new teams who have not worked together is 8 points per person, per iteration and then adjusted for time off. Where you are an existing team, use historical velocity; that is a great indication of how much work you are likely to be able to complete in any given iteration. Then, we look at the iteration dates. We look for public holidays. If you are a distributed team or a distributed train, don't forget public holidays are different in different parts of the world. So make sure you understand what the public holidays are for your particular team members' locale.

 

Also, understand if there are any team changes. If anyone is coming into the team or going out of the team, that impacts your ability to be reliable in terms of your capacity and in terms of your velocity. My recommendation here is for any additions or subtractions, seriously consider going back to that new team guidance. Ask team members if they have planned or proposed leave. Don't worry about the fact that it hasn't been approved yet; taking proposed leave into consideration when you do PI Planning just sets us up for success. If that leave doesn't come to fruition, then okay. We have the opportunity to bring in more work or to make an adjustment. Of course, nothing is said in stone. However, what we don't want to do is assume nobody's taking any leave and make commitments on that basis because that's going to be awkward for the team and for the train.

 

The “Turn Up The Good” pattern is to think about surfacing capacity mid-program increment for the next PI. It might sound a bit crazy. And certainly when you surface this idea with teams, it is like nobody plans that far in advance but I really do think it's a mindset shift. You look at the calendar, if Christmas is falling in the next Program Increment, highly likely you're probably going to take some leave so surface that information. What it does, is once we start getting an understanding of the rough capacity of the Agile Release Train in its entirety, we can start to understand from that product management perspective. Do we have enough work? Do we have too much work? We can also start setting expectations with stakeholders. If it turns out there's a lot of leave in the Program Increment, then we would want people to know that earlier than later.

 

If this is not your pattern or there is some reason why that doesn't work for you at the very least of Scrum Masters, you want to understand the team capacity in the week before PI Planning. This is absolutely something you can take off your plate at PI Planning and prepare ahead of time.

 

Before PI Planning, you also want to sync with your Release Train Engineer and potentially the Trifecta, which is our term for the Release Train Engineer, System Architect and Product Management. So, as part of a Team of Teams, it's important that we align, and it makes sense that we align. Ideally, there are no surprises at PI Planning, at least in this realm of things.

 

We should know feature priorities. We should know the Definition of Done, capacity allocation, and how we're going to do PI Planning. Is it going to be online? Is it going to be face-to-face? Is it going to be hybrid? We would suggest not hybrid, but sometimes you don't have a choice. We want to be clear on the tooling for the event. Are we going to use Miro, Mural? Are we going to use Collaborate? Are we going to use WebEx or Zoom, or MS Teams? Work all of this stuff out well ahead of PI Planning. So, it just lowers the mental load and makes it all a lot easier. Timing for the event is also helpful for the Scrum Masters to know, to start to get an appreciation of, how long are our breakouts going to be? How much time do we have to play with for planning purposes? It's also a good idea to have a conversation as a Scrum Master and Release Train Engineer group about any milestones within the Program Increment. (Note: Program Increment was renamed Planning Interval in SAFe 6.0.)

 

Maybe you have a financial shutdown period where you can't make any changes to the systems that interface with finance, for example. Maybe you have a market commitment that you need to make that may not even be directly part of the Agile Release Train’s work, but it might be tangentially related. Or it could well be something within the Agile Release Train that you want to surface. If you have release windows that [are] defined ahead of time, surface them, make sure that's part of the Program Board. (Note: Program Board was renamed ART Board in SAFe 6.0.) You also want to make sure that the SMEs you invited, though you identified their feature discovery, are invited to PI Planning.

 

Melissa?

 

Melissa Hay: Hello. We're just getting a little bit of staticy feedback. Funny noise, maybe through your headphones. Thank you. I also agree with what you've said.

 

Claire Sanders: All right. Let's see how this goes. As a Scrum Master, you're part of the Release Train Engineers' extended team. So, you want to help the RTE get ready for PI Planning. Particularly if you find yourself with a little bit of time on your hands, reach out to your RTE and see how you can help. The job of facilitating PI Planning, of course, is also a heavy lift.

 

Okay, from a Scrum Master perspective, you can set your team up for success by having a facilitation plan, particularly for day one. The facilitation plan for Day Two (or Day Three if you're doing a day three [pattern]) will evolve, but Day One really sets you up for success. So, we want to consider how many features or feature-sized enablers your team is planning to pull apart as part of Day One. You should pull apart all of the features or enablers that you are likely to do in the Program Increment on Day One so that you can get to that draft plan.

 

Consider, do you need help from anyone else? Is there guidance you need from the Architect based on some late-breaking news? [If so,] talk to the Architect. Let them know which feature you need help with and when you expect to be planning that feature. And then go ahead and break apart that time box. So if you expect that the breakout window is going to be 2 hours, think about how much of that 2-hour window are you going to spend on the 1st feature versus the 2nd or 3rd feature. And look at the sizing that your team has done on the feature to guide you. If you have a big feature, you're going to invest more time. If you have a small feature, you're going to invest less time. Think about how you're going to size your stories. We still use the Fibonacci sequence at PI Planning. Use planning poker cards. You can use online planning poker. There are websites dedicated to this technique. There are mobile phone apps. Whatever it is that works for your team, make sure that everybody is clear on the technique you're going to use.

 

Agree a plan with your team around meal times. One of the things that happens as we get busier and we have a lot of feature work to do, and as delivery teams, we get very excited about delivering and carving out a plan and doing the right things by our customers and our stakeholders; we forget to eat. So I recommend that Release Train Engineers put meal breaks into the agenda. But then, at the team level, you want to have a conversation about, will we work through? If so, do we need to have something ready like a sandwich or something so that you can eat and continue planning or if we're at a face-to-face event, will there be catering? You want to give yourself the flexibility to be able to work through meal times if you are in a jam. But of course, most teams would much prefer to stop and have a break and carve out a facilitation plan that will let you do that if things are going well.

 

Going into PI Planning, you should know which features and enablers you are going to be planning out. Think about which ones it might be more difficult to position with your business owners. I was talking with a data analytics team earlier today, and they were saying, "Yes, that's tricky for us. We're not entirely sure how we are going to position the business value exactly." Recruit people who are going to be able to position this for you. Don't be afraid to bring in the Architect on more technical pieces. They'll often be quite used to representing the Business Value behind technical pieces of work. So leverage help.

 

You want to agree a plan with your team for dependencies. Just because you're the Scrum Master does not mean you need to have all dependency conversations. In actual fact, you are much better to send the person with the most information about the dependency to go and agree a dependency with another team. So let's say...

 

Melissa Hay: I think we lost Claire.

 

Claire Sanders: That was unfriendly, wasn't it? Let's say-

 

Melissa Hay: I was just going to say how should I finish the sentence? So if you've got a dependency, you should definitely go to the circus. No? Is that what you were going to say? Let's try again, Claire.

 

Claire Sanders: Okay. Thanks. Let's say you have a dependency on another team to deliver an API for you. Send the person who knows the most about the data you're going to send versus the data you want to receive back so that you can just have that conversation once. Rather than you going and saying, "Yeah, we need something from you. Can you do that for us?" Also, agree a plan with your team for Scrum of Scrums. Scrum of Scrums ideally happens every hour or so during PI Planning. Note: Scrum of Scrum was renamed Coach Sync in SAFe 6.0.) The last thing you want to have your team do is down tools because you've gone to Scrum of Scrums. Have a conversation with the team about who might be best placed to pick up the metaphorical whiteboard marker while you are gone.  Have a conversation about if anybody is planning to miss PI Planning, they have leave or another priority or if they're going to be at PI Planning, but they just have to step out. Think about how you are going to bring that person back up to speed and how are you going to make sure that their voice is represented while they're out? So [it’s a] big job.

 

This is an example of a face-to-face PI Planning board. This is obviously literally a whiteboard. This is an example of the things you might want to draw out. So the goal is to get a draft plan, in this case, by 4:30. We have two features, and we have an SME for each of the features who are going to come and set context with the team. We've met with these people before, but just to remind us that, okay, here we are. We're at PI Planning, bringing together everything we already know about this feature. We hear from our customer representatives on what is important to them. These two features are of different sizes so they get different amounts of the time box. We have a hard stop to make sure that we don't forget to set aside some time for PI objectives. The secret here is not only to have an agenda but to visualise it. By visualising it you're letting your team know that, "It's okay. We've got a plan here. It's going to be right." But also, if anybody else pops into your group, they can have a look at where you are on the agenda. “Oh. You're still talking about the first feature; I'll come back, [it] looks like sometime after 3:00 pm, and we can talk about the second feature”.

 

During PI Planning, reassure your team that it's okay if they don't know everything upfront. In fact, that is expected. Make some educated guesses and make sure that we have just enough information now to move on. Things will change. Things will evolve. We expect that, and in fact, the SAFe principles tell us that will happen. It's A-okay. We don't need to know if it's going to be a radio button or a checkbox. We'll work it out in implementation.

 

During PI Planning, you want to start with your highest priority feature. You want to talk about the customer problem. As I said earlier, draw a picture. It's a really great way of understanding are we speaking the same language or not. As a Scrum Master, ask your team how are we going to solve this customer problem and what is the work? You do not have to be technical. You do not have to know how the team is going to implement the code or resolve the individual problems. But you want to ask the questions that will help them open up and surface the plan to the rest of the team. Size the work and capture your acceptance criteria or thoughts.

 

At PI Planning, you will not have time to write the "given/when/then" or even complete sentences as dot points for acceptance criteria. That's okay, folks. What we are looking for is to have a conversation about what the work is. Capture whatever is said. So maybe as we're talking about the story, someone says, "We've got automated tests in this space. We're going to need to enhance them." Take notes on that so that when you come back to refining these stories, you've got a head start.

 

During PI Planning, don't forget SOS in terms of Save Our Souls. Don't be afraid to ask for help. The beautiful thing about PI Planning is everyone is there. If you need help, all you need to do is ask. Also, don't forget Scrum of Scrums. This is your opportunity to bring your head up out of the weeds of individual stories and story points and consider, “Oh my goodness, how are we going to get all of this done?” And look at the bigger picture. We have 45 minutes until Draft Plan [review] or whatever else is going on. Offer hyper transparency to the Release Train Engineer. Surface if you think there is a problem brewing, let your Release Train Engineer know so that they can help you. Accept help when you need it. There's no point in trying to battle through when you need assistance.

 

Finally, ask the team. The point of PI Planning is to carve out a plan that the team can stand behind. So don't forget it's them doing the planning. Ask them what they need so that you can get them the help that is necessary before PI Planning. At PI Planning, check in. Make sure that people are having their voices heard and that we're understanding if there are any problems to resolve. On day two or whatever your last day of PI Planning is, start asking, "How confident are we in this plan?" Get your team members to give you a fist of five in terms of confidence. Not that we're going to back them into a corner and say, "Hey Johnny, you voted four when I asked you earlier and now, in the whole of train, you are voting three." That's not the idea. The idea is to surface if somebody is secretly saying, "I don't understand the plan." Great. Let's walk through the plan so we understand it much better to be able to do that so that - for that person to save face at final plan review as well.

 

This is a question slide. It's slightly invisible, but I would like to know, do you have any questions folks? Is there anything we can do to fill in any gaps that I might have inadvertently stumbled into over the course of that presentation?

 

Mariya Khatiba: I want to ask Claire, you spoke about pre-PI sync up with Trifecta. So what should be the outcome of that? Because I think we are missing that.

 

Claire Sanders: Yes, sure. So, really, the point of that sync is to make sure that as a Scrum Master, you have all of the appropriate information going into PI Planning. So you want to align with the Release Train Engineer or the Trifecta and understand, when are we going to know what our finalised list of priorities for PI Planning is? Which is the outcome of WSJF when we have that information. And then, walking through each of these aspects, have there been any changes to the definition of done? This is something that should evolve over time. So let's check in and make sure we know what the latest definition of Done is from the train perspective. Capacity allocation often changes. How we are running PI Planning can also change. The Release Train Engineer is often really busy and quite focused on getting ready for PI Planning. And this is just a checkpoint to make sure that we are communicating back and the Scrum Masters have that information for their teams going into PI Planning. Does that help?

 

Mariya Khatiba: Yes.

 

Claire Sanders: Lovely.

 

Thanks for the question.

 

James?

 

James: Hi. You mentioned that during the PI Planning, there may not be enough time to have all those acceptance criteria on the backlog of... Within the team. If that's the case after the two or three days of PI Planning, that means the stories still haven't met the definition of ready, or there aren't enough healthy stories to get executed. So, can you share some experience on how would you address that?

 

Claire Sanders: Yes, sure. Great question. Thanks, James. So, two things;

 

Before we go into the first iteration, we are going to need to finalise the stories for iteration one and make sure we have acceptance criteria, and the stories are clearly understood by the team and are sized appropriately for the acceptance criteria. We normally do this in backlog refinement. So, we do backlog refinement at least once in an iteration in preparation for the next iteration. We know that the team backlog will age pretty badly if we refine it too much in advance. So it's a matter of refining it on a just-in-time basis for the next iteration is a good choice.

 

The other thing is, as you go through the PI Planning event, sometimes on day two, assuming you're running a two-day PI Planning event, there will be teams who have done all of the planning that is necessary and are basically ready to move on. For those teams, we'll invite them to start refining their stories into those small pieces. Those 1, 2 or 3-point stories, with acceptance criteria so that they're ready to roll into iteration one. Does that answer your question, James?

 

James: Yes. Thanks very much, Claire.

 

Claire Sanders: Thanks. You're welcome.

 

Lim: Hey Claire. Lim here. Hey, I know both Scrum Master and SPC can both facilitate the PI Planning session. Is there a distinction having either a role facilitate a PI Planning session, or would you say, under certain circumstances, it's better to have a Scrum Master facilitate a PI versus an SPC?

 

Claire Sanders: Thanks Lim, for the question. When you say an SPC, do you mean a train coach? Is that the role you...

 

Lim: Yes, exactly.

 

Claire Sanders: Okay. Ideally, the Scrum Master who is with the delivery team day-in, day-out facilitates PI Planning because partly it's about the conversations we have at PI Planning, and it then sets up the team for success going into the Program Increment. That said, if there is a reason that the Scrum Master isn't at PI Planning, perhaps they're on leave, or they have other commitments on the PI Planning dates, absolutely an SPC or a train coach can come in and support the team.

 

Lim: Cool. Thanks, Claire.

 

Claire Sanders: Great question.

 

Janelle: Hey Claire, can I just get that clarified because I thought an SPC or an RTE will facilitate the PI Planning, but the Scrum Masters will facilitate the team in PI when they go into their breakouts to nut out what their deliverables are. Not that the Scrum Master will facilitate a PI Planning session.

 

Claire Sanders: Yes. Good clarification, Janelle. Yes. So, the Release Train Engineer facilitates the whole PI Planning event. It's a Scrum Master who's facilitating the team breakouts. So, the sections where we pivot away from the entire Agile Release Train and into our smaller team group to carve out a program increment plan for that team. Does that help? Did I clarify?

 

Janelle: Definitely. I hope Lim gets that clarification, too.

 

Claire Sanders: Thanks, Janelle.

 

Lim: Yes. I think either Scrum Master and SPC or even RTE could facilitate the PI Planning. I don't think there's going to be a fixed role that says that someone has to do that. I think depends on circumstances and…

 

Janelle:  I just find that if you have a Scrum Master playing two roles, it's very, very difficult to facilitate a PI Planning event and be a Scrum Master for a team. I find that it's much better if you have dedicated Scrum Masters for your teams and a dedicated role, whether it's an RTE or SPC, to facilitate the actual PI event in its entirety.

 

Claire Sanders: Totally agree, Janelle. That's what I was going to say at scale. It's really important to make sure that there is somebody running the overall event, being the Release Train Engineer, and that's freeing up the Scrum Masters to focus on their own team. But it's a question of scale.

 

David?

 

David: Hey. Got any advice if you[‘re] a Scrum Master for multiple teams at PI Planning, which I am, and it didn't work very well at the last PI Planning. We're trying to resolve it, but we haven't come up with a perfect solution yet.

 

Claire Sanders: Yes, that's definitely a challenge. Typically, with our clients, we try to get one Scrum Master per team for exactly that reason. Cloning would be a good choice. However, if that's not possible, asking somebody within the team if they're willing to fulfil the role of Scrum Master for the team at PI Planning is typically the choice that we'll make there because you can't be in two places at once.

 

David: Okay.

 

Claire Sanders: Incredibly difficult.

 

David: What about if it... What about the product owner? Would they do, or are they too valuable applying business value?

 

Claire Sanders: Yes. So there should be a really nice, healthy tension between the Scrum Master and the Product Owner. The Scrum Master should be there making sure that we're protecting the team, whereas the Product Owner is really advocating for the customer and for the business. So certainly, in our experience and for folks who come and train with us, we understand having a Product Owner and Scrum Master and the one person is an equally difficult place to be.

 

David: Well, good. Thank you.

 

Claire Sanders: Thanks for the question, David. Sorry, I don't have a silver bullet there.

 

Lisa?

 

Lisa: Hi Claire. Thanks for the session. It's been great. My question was around OKRs, and I apologise if you did touch on it. And I'm a bit new to PI Planning as well. Where do the OKRs sit as far as this event? Is it pre-work, or is it during or...?

 

Claire Sanders: So very much in the context setting, understanding what it is that we are hoping to achieve. So we really didn't cover off on it in this session. It's probably more of a higher level consideration and really the context setting at the start of PI Planning, which is a really important part of PI Planning that we've been much more focused on the Scrum Master role here today.

 

Lisa: Okay, great. Thank you.

 

Claire Sanders: Thanks, Lisa.

 

Mariya?

 

Mariya: Claire, we spoke about feature discovery and if we are going for PI two or PI three. Let's say planning, and we are introduced [to a] new feature on the day of PI Planning. Then sometimes [the] team is not confident to even estimate, or they don't understand the feature. Then how, as a Scrum Master, can we navigate through this or how can we improve the process [so] that such things don't happen and we know the feature beforehand like that?

 

Claire Sanders: Yes. I love that question, Mariya. That's awesome. So, how do you protect your team? Encourage the team to ensure that any PI objectives that are written in relation to that feature are uncommitted. It's not fair to ask the team to commit to delivery of a feature or of a program increment... Sorry for a PI objective for that feature if they've never seen it before.

 

And I love that you asked that question of what is it about the system that we could fix so that this occurs less frequently. That's an awesome question to ask, particularly as a Scrum Master. So, bravo to you! So you want to make sure that we're having that conversation back with the Trifecta, with the Release Train Engineer, System Architect, Product Management about what happened there, and is there any way we can foresee a feature joining the PI Planning event ahead of the event itself? Sometimes it will be unavoidable, and that's okay. But it certainly shouldn't be the norm, and you're absolutely right to look at the system of work and see what is it that we could improve about the system of work so it is a less common occurrence.

 

Mariya: Okay. So go back and discuss with the Trifecta.

 

Claire Sanders: Yes.

 

Mariya: Okay. And one more thing. I think Nicholene is there and Nicholene is there on call. I have seen this. That they have experienced a pivot in the middle of PI. So I want to understand what are the factors that pivot should be acceptable, or is it okay to have a pivot in the mid PI and going to start with the new feature from scratch? So, I want to understand that part as well.

 

Claire Sanders: That's a great question, too. So PI Planning is a workshop, and we need to remember that. So sometimes, it will be the right thing to do to pivot during PI Planning. From a Trifecta perspective, you want to be really careful about when you ask teams to pivot. Again, we want to look at the system of work and make sure that we're only making those decisions where it's unavoidable ahead of time. But in the case that you are asked as a Scrum Master for the team to pivot, of course, we're going to do that. Because what PI Planning does is it surfaces information that previously wasn't there. It is the responsible thing to do, and it is the agile thing to do to make the best of the information we now have, and sometimes that will be pivoting.

 

From a team perspective, something you can do is to remember that when you are doing discovery, when you are preparing for PI Planning, remember this feature may not be prioritised. It's a question of if we were to deliver this feature, what might that look like? We want to make sure we don't over-invest in discovery. And it's another reason for not writing stories ahead of PI Planning because that's an over-investment, and then if you pivot, it starts to feel like a lot of waste and... Well, it's a lot of waste and gets people quite unhappy about the situation. Does that answer your question Mariya?

 

Mariya: I think you talked about pivot in the planning, but if there is pivot in the mid-PI. We have already started working on a feature.

 

Claire Sanders: Yes. Well, look, similar things apply. From a leadership perspective, you want to make sure that the train leadership has made all of the right decisions and considered the implications of pivoting before we pivot. Also, we want to take work off the plate of the team that is more significant than size than the work we're adding, and we want to make sure we're having those conversations about why it's so important to make that pivot.

 

Mariya: So to keep the morale of the team still high, we have to give them the proper reasons “why are we doing this”?

 

Claire Sanders: Yes.

 

Mariya:  So I think-

 

Claire Sanders: Absolutely. Yeah, absolutely. The why is so important.

 

Mariya: Cool. Thank you.

 

Claire Sanders: Thanks, Maria.

 

Akshay?

 

Akshay: Yeah. Hi Claire. So, my question is also related to pivot itself. So how is it if we already allocate some additional capacity in the beginning of the PI Planning itself towards... Let's say if there is a pivot, we are anticipating. It comes, it doesn't come; that's a different story, but if it comes, ultimately, the team is not sure what needs to be done because it's introduced at the last moment. So is it the only solution when we can have some extra capacity already planned for the tackling the pivot, or do you suggest any other measures that we as a team can discuss with RTE Trifecta if any pivot comes in?

 

Claire Sanders: So I think it's important to make sure that we are really cognizant of what are the challenges that might require, might necessitate a pivot. Maybe it's a decision that needs to be made; we're all tracking towards that decision being made, and then once it is made, then we're able to carve out a plan going forward. I'd be a little bit reluctant to reserve capacity for the reason that what if you don't need to pivot? Then you still don't have a plan. It necessitates re-planning in both situations, whether you need a pivot or not if you have reserved capacity. So I think I'd much prefer just going with the highest priorities as we know it today and then responding in the case of a pivot with, "Okay, so what are we going to take off the plate of the team so that we can change directions here?" Because it can just create more noise to have space in your plan.

 

Akshay: Yes. Thanks. And one more thing. So, as Mariya already mentioned, so what will be the best measures that the Scrum Masters should take to keep the team motivated apart from what Mariya discussed? Can you just throw some light on that, but in case if there's a pivot?

 

Claire Sanders: Okay. So I do think, going back to that point with Mariya, I think it's really important for the team to understand why is it necessary to make this pivot? What is the customer impact going to be? Potentially, is the impact for current or prospective customers? I really do think it's getting closer to the customer understanding why this is necessary. Because we think of the top of SAFe, the House of Lean in SAFe, it's all about the delivery of value. (Note: The SAFe House of Lean was replaced with Lean Thinking in SAFe 6.0.) That is our reason for being connected back with that, is my suggestion. Thanks for the question.

 

Akshay: Thank you.

 

Claire Sanders: We have three minutes left. Let's make sure we get to these last two questions.

 

Vignesh? You're on mute.

 

Vignesh: Sorry. Thank you for the presentation. That was a wonderful presentation.

 

I just have a question in relation to the... What would you expect as a precondition before you start the PI? What I mean by that is that in some organisations, what I have seen is that we have pre-PI sessions where we have a clear understanding of the organisational priorities. The epics we wanted to deal with. We are well clear to add a good understanding of what the dependencies were and all of those things well in advance before going into the PI. But it does give us the ability to actually get on with the work and so we can plan what stories we can tackle during the iterations, and whether we have the necessary resources. Do we have enough information into the PI so that we can say, putting your hand in the heart and say, "Yes, we can complete this task and define the objectives as well?" From your experience what you have seen with your clients, what are all the things you would consider as a precondition for a PI?

 

Claire Sanders: Great question. So, I think SAFe does a really nice job of articulating this in terms of readiness for launch for a brand new Agile Release Train. A lot of what's in that toolkit continues to apply for existing Agile Release Trains. So things like we know who is in each team, they've been trained, and they have the right skills and capabilities to be able to deliver something of value to our customers. We understand the features that have been prioritised. We know what those priorities are. We appreciate which team is expected to plan which feature; we also, of course, need people who are going to provide the business and the product context ahead of PI Planning and then all of the logistics considerations as well as what's on the slide here. Sorry, not this one.

 

Now we'll go back to the preparation with... Yes, this [slide]. The sync with the Release Train Engineer. So, making sure we understand the Program Increment dates, the iteration dates all of those important inputs to PI Planning. I think we just also need to be careful. SAFe is a Lean Agile framework. We want to make sure that we get that balance between enough preparation without it being too much preparation because, of course, lead time matters. Our customers are waiting, so we don't want to over-prepare. And I think our pattern of feature discovery, where we understand the breadth of the feature but not necessarily all of the detail, cuts a nice balance for that particular problem.

 

Vignesh: Thank you.

 

Claire Sanders: Thank you. Thanks for the question. Folks, we have just hit 6:01 p.m. Thank you all for the great questions. And it was so lovely to see a lot of our return frequent flyers from Pretty Agile. Thanks so much, everybody.

 

Akshay: Thank you.