Editorial note: Transcribed and lightly diarized from audio for readability.

Breaking the SAFe: Deconstructing PI Planning

Host: Ryan Ripley Guest: Yuval Yeret (SAFe Fellow, CST)

Introduction & Is PI Planning Anti-Agile?

Ryan Ripley: Welcome back to another episode of Breaking the SAFe with Ryan Ripley and Yuval Yeret. We’re both professional Scrum trainers with Scrum.org. Yuval has another interesting title after his name: he is a SAFe Fellow. And so, of course, when we talk about breaking the SAFe and trying to figure out what’s good, what’s bad, what’s ugly, we’re going to defer to Yuval quite a bit in his expertise.

But let’s see if I can ask some decent questions this week.

Actually, Yuval, a question came in - your comments, everybody, are awesome. You’re doing a great job in the comments section. Everyone’s playing nice. We appreciate it. Big thumbs up. And the questions are really good.

A number of questions came in around PI Planning, so I went ahead and wordsmithed it a little bit and had a little fun: Is PI Planning big up-front design, anti-Agile, and all-around evil? What do you think, Yuval?

Yuval Yeret: I don’t know. What are your thoughts, Ryan, before I go in? What are your thoughts? What’s your perspective?

Ryan Ripley: Yeah, so Program Increment Planning - I don’t think it’s all-around evil. I think there are some interesting challenges that come when you’re trying to plan that far ahead, right? So the last I knew, and correct me if I’m wrong, I haven’t looked at this in a minute, we’re trying to plan, I think, is it six sprints ahead roughly?

Yuval Yeret: 8 to 12 weeks, so yeah, 5-6 sprints.

Ryan Ripley: 5-6 sprints ahead. I think when we go that far out, I think it’s interesting to play “what if”, and I think it’s good for a Product Owner to look at, her product backlog and say, “What if, we have the most amazing five sprints?

What could we do? How, what kind of progress could we make towards our product goal? Or what kind of sprint goals could make sense?”

But when it comes to dedicating full days to thinking about “what if”, I get nervous only because after the first sprint, most likely everything’s going to radically change. And so, I don’t know how stable SAFe implementations are three, four, five, six sprints out. I know from working with, Todd and I working with thousands of students, I would argue maybe hundreds of Scrum teams, maybe not quite that many, but quite a few Scrum teams in many organizations, just having a sprint backlog that looks reasonable can be difficult enough, and now we’re trying to do that, 5-6 sprints, which could be 12 weeks out.

It just seems like it would lead to a lot of waste and rework, and I’m not even certain within SAFe how you would trigger that reassessment of PI, and whether or not executives expect what’s established in PI to be consistent. I know we have the theory, but you and I are also trying to be very pragmatic.

And what I have seen is that once PI is locked in, there is an expectation that it stays locked in. But planning that far ahead, I think, is just so difficult. So for me, is it all-around evil? No. Does it have elements of anti-Agile thinking?

Probably. Is it all big up-front design? I don’t think so. I don’t think every Product Backlog Item is fully fleshed out at the end of PI Planning. I think they’re framed out, and then we’re trying to figure out six sprints ahead.

So that’s my ramble. What have I done well? What have I done poorly, and where do I need to improve, Yuval?

The Intent and Structure of PI Planning

Yuval Yeret: You represented, I would say, the popular, common perspective about PI Planning out there, so you’ve done great there. A couple of things to keep in mind:

So, the Agile planning onion was not invented by SAFe and is not exclusive to SAFe. We talk about it in our Professional Scrum Product Owner classes, right? Scrum Product Owner classes. Which means you need to plan for different horizons at different altitudes. PI Planning is an implementation of that concept.

Scrum teams have been doing release planning at some level, or organizations have been doing release planning as part of Agile at some level for ages. PI Planning is an evolution of that concept.

What are we trying to do with PI Planning? We’re trying to come up with a reasonable shared understanding across a team of teams that has some dependencies, some coordination that they need to hash out amongst them, of what reality might look like, what we might be able to accomplish in the next 8 to 12 weeks.

Why do we do that? There are a couple of main reasons we do that. One is the business wants some understanding of what to expect. We want to make some plans. We want to prepare for what might be delivered. We want to have an understanding of what’s realistic to expect, what’s, a bit more shaky, what’s beyond any expectation that it would happen.

In order to come up with that sort of forecast, teams need to go through some sort of process. The real magic in PI Planning is how it involves everybody throughout all of the teams or the team of teams that are working together towards these goals to align on what’s important and what’s possible. That’s the magic of PI Planning.

In order to get there, what SAFe did is basically take ideas that come from the work of Jean Tabaka, one of the facilitation gods of, of the Agile space, something, at Rally they called Big Room Planning. Took that approach and basically brought it into SAFe. This approach is a set of facilitation moves that are orchestrated together to go through a sequence of context-setting by leadership, then teams breaking out to come up with their plans, then integrating the thinking, seeing where we’re at, doing some what-if scenarios, then breaking apart again, all of that with the desire to align and come up with a plan that everybody is involved with and is committed to.

In a sense, PI Planning is the way we achieve an empowered Agile Release Train that understands what’s its purpose and is committed towards its purpose.

Now, what PI Planning is not is detailed planning for 5 or 6 sprints ahead. We go into what might happen in each one of these iterations in order to flush out the details, sort of a “cent-up” exercise. But the result of PI Planning is not, which stories are going to happen in which iteration. The outcome of PI Planning is objectives that we believe are realistic for each one of the teams and for the Agile Release Train.

And similarly to the Sprint Goal, that is different than the Sprint Backlog - the Sprint Goal stays stable throughout the Sprint; the Sprint Backlog does not - the PI Objectives are expected to be stable throughout the PI. The backlogs for the different iterations are not expected to be stable, and are not even considered an output of PI Planning.

Ryan Ripley: So if I were to bring this into Professional Scrum, an equivalent would be: We’re going to plan out at a high level what our Sprint Goals are going to be for the next four, five, six sprints. We’re going to think about why those are important, how we’re going to measure whether or not we’ve achieved them, how we’re going to measure the impact of those goals on our product and on our stakeholders.

We’re going to talk about any big dependencies we know up front. We’re going to talk about a risk mitigation plan. We’re going to get our primary portfolio board or program board set up, and then we’re going to execute the sprints and start working through the details now that all of these things are laid out.

Is that accurate?

Theory vs. Practice: Anti-Patterns in PI Planning

Yuval Yeret: Yes. The one thing to acknowledge, though, is that if you and I would go and visit organizations that are running PI Planning, that are implementing SAFe, in a lot of them, it would look more like what you described than what I described, which is an issue, a big issue in my view. I mean, no matter how much as a SAFe Fellow and SPCT I can talk about this approach to PI Planning in training and, even in organizations that I work with, there’s the gravity of “we feel more comfortable with defining the details.” People struggle to follow the principles of “assume variability, preserve options.” This is, a SAFe principle.

SAFe principle number three says we assume variability and we preserve options. Which means let’s focus on objectives. Let’s keep the, the detailed backlogs open. Let me not commit to these. Things might shift throughout the PI.

So there’s a big gap between the theory of SAFe and how it’s practiced in the trenches, which is a gap that we need to work on closing. And that’s part of our role as SAFe Fellows and SPCTs, is to educate people, to help them kind of evolve from, let me call it, “mechanical SAFe” to, SAFe that follows the principles, “professional SAFe”, whatever you want to call it.

Ryan Ripley: Sure. It’s interesting because the advent of remote work, it has allowed me to observe a few PI Planning sessions. You know, we’ve had a few clients who have said, “Hey, what does this look like?

And what are your thoughts?” And it looked like exactly what the anti-pattern you described, right? “Iteration one, here’s everything we’re going to try to do. We might have a Sprint Goal, we might not. But our past cadence or velocity or whatever it is, because we know story points are trash, but the past cadence or velocity is 20.

So we’re going to cram 20 into this one. All right, what does iteration two look like? We’ve got 20 more points.” And so by the end, they actually have fleshed-out backlogs for each iteration. They’re planning these out at six sprints out. And I watch this and I just go: It takes one little thing or one dependency that you think you have managed, but isn’t, and this whole thing just crumbles.

And so it’s good to hear that the theory is actually big goals across the six, some implementation ideas, some dependency management, some risk mitigation, maybe in the upcoming sprint there’s a little more detail, but everything else is kind of vague so we’re preserving options, right?

Yuval Yeret: It’s more in the middle between what you’re describing and what I’m describing. The theory does expect to see less and less detail as we proceed through the PI. We are talking about, having guardrails, buffers, whatever you want to call it, because we know that reality is going to be different than, these post-its that were now put in there for stuff that’s going to happen more than two months from now.

But we are flushing out, at least at some level, we’re breaking down the features that we’re bringing into the PI one level down to get a feeling for what’s possible, what do we think we need from other teams, what’s our hypothesis about what’s going to happen. The challenge is remembering that this is an hypothesis and remembering that there’s going to be a lot of uncertainty as we, as the rubber meets the road for this PI.

If we don’t go one level down, if we just keep it at “these are the features, let’s see what fits in,” the risk is that our plan is not going to be realistic. It’s not going to have enough meat on the bones to really stress-test it, to really say we’re confident in it or we’re not confident in it.

Managing Uncertainty and Predictability

Ryan Ripley: You know what, though? Some would say that you adopt Professional Scrum because you embrace uncertainty and want to manage risk, and then they would say you embrace SAFe because you reject uncertainty and you want to have predictability. And so you see those implementations play out. Now, again, on the Scrum side, there are definitely mechanical - I mean, Zombie Scrum, Barry and Christian, Barry Overeem, Christian Verwijs, who’s out of the Netherlands, their Zombie Scrum Survival Guide is exactly because there’s bad Scrum implementations.

So we have to concede that, right? But at the same time, when you have a framework like SAFe that is hell-bent on giving the illusion or the actual implementation of predictability, it also makes it hard to also say your whole PI Planning is a hypothesis, and all the work you just did to plan can and will change, right?

I guess or tell me if I’ve mischaracterized. I want to make sure I’m fair with you.

Yuval Yeret: I think you’re mischaracterizing it a bit. So it’s in the nuances. SAFe does try to achieve predictability, some predictability of what the business might expect. And I think in many environments with Scrum, we try to achieve some predictability as well despite the uncertainty and risk.

We use Scrum - and SAFe, by the way - to manage risk, manage uncertainty in a way where, despite all of the uncertainty, we can have some predictability.

Now, this is magic, right? How do you do that? You cannot have full predictability to everything that will happen. But what you can do is you can prioritize. You can decide those are the things that are really important to me. I know a lot is going to shift, but that’s my core. That’s the main bone through this PI that we’re going to focus on, and we’re going to throw a lot overboard in order to protect this core stuff.

And PI Planning is a lot about this, and PI execution is also a lot about this: identifying what’s the core, what are the things that we really want to focus on. And that’s why it’s so valuable to have the stakeholders beyond, Product Owners and the teams, to have stakeholders from the business outside the team available throughout the PI Planning process, like we have them in the Sprint Review in Scrum, to give feedback on: Is this really the core stuff that we should be protecting for?

Is this stuff that could be a sandbag that we throw overboard if push comes to shove? We are willing to, have some space in the PI, not load it to 100%, for sure not load it to 120%. We even have an IP iteration towards the end of the PI, two weeks which we don’t plan for at all. A lot of things that we do to achieve predictability, some predictability, not full predictability, some predictability, while acknowledging that there’s a lot of uncertainty in the work that we’re doing.

Deconstructing the PI Predictability Score

Ryan Ripley: Something else that I see applied heavily to PI Planning is that when you go back to retrospective about the last product increment, is that there is a lot of discussion around planned versus actual. There are teams that want to see how accurate they were at planning five to six sprints out.

And to me, that’s again, it’s that bent on predictability, but I think even you would agree, we’re never going to be good at this, right? If we’re getting 100% of our PI Planning correct, I’m either calling foul, someone’s cooking the books, or we sandbagged so badly that we couldn’t possibly miss. You know what I mean?

Yuval Yeret: Yeah. So let’s talk a bit about that, and I know you and Todd had a deep conversation about PI predictability score, how it caused the Southwest Christmas Armageddon.

Ryan Ripley: Oh, you found the trap! Okay, so…

Yuval Yeret: So, let’s remember what PI predictability is about and what’s the context. And again, it goes back to our previous conversation about SAFe taking…

Ryan Ripley: But wait, I want to hold your feet to the fire a little bit. So the people in that video that we published that were giving a talk at the SAFe Summit used that as a metric for success. So I want to make sure we’re clear. I’m not going to comment on that. I got that, but I just want to make sure people aren’t thinking that I just pulled this unfair argument out of the air.

That was from their mouths, right? Okay, cool. Go ahead, Yuval.

Yuval Yeret: So, PI predictability score - why do we even have that metric, and what it’s about? So again, SAFe is taking the evolutionary path. Organizations, project managers, PMOs, leaders have been doing plan versus actual for ages. One approach to that would be to say, we’re in an evidence-based world of empiricism.

Just, break that habit cold. Just stop it, right? That’s one way to do it, to say you don’t, it doesn’t make sense to do any sort of plan versus actual. Whatever we manage to do, we manage to do. Predictability is not that important. It will be done when it’s done. I remember, in one of the Agile Israel conferences, we were doing a panel, and one of the well-known Scrum Alliance CSTs, you probably know the guy, was on the stage and somebody was asking, “You know, we need to have a big release at some point and we need to know - the business needs to know when it’s going to be ready.” And the CST answer was, “Well, you can’t know.

Tell the business you can’t know,” right?

Now, there’s some truth to that statement, but there’s also a lot of arrogance and disregard for what’s driving business. I know you, when you run a Professional Agile Leadership class at Scrum.org, predictability is one of the highlights of the conversation, right?

Predictability is important to business leaders.

Ryan Ripley: It is. Absolutely. Totally concede the point. The context of predictability, though, is what’s I think important. So when someone says, “Can we predict down to the person what they’re going to do in a sprint?” The answer’s no. “Can we predict down to the Product Backlog Item what’s going to happen in a sprint?” The answer’s no. “Can we from a predictable standpoint say that each and every sprint we will commit to a Sprint Goal and achieve it?” Now we’re in the “yes” zone.

Now we can say yes.

Yuval Yeret: Right! You’re playing into my hand. Thank you.

So what is the predictability score measuring? It’s measuring those PI Objectives that I talked about. Remember, the backlogs are not the output of PI Planning. We don’t even look at them. Some teams look at them. Some teams take the output of PI Planning and put it straight into Jira, Azure DevOps, whatever, or their boards, but they’re not the output we commit to from PI Planning.

We commit to the PI Objectives. What we commit to in a practical sense, we commit to PI Objectives. Some organizations, by the way, don’t use PI Objectives, which is a shame. You might have seen in PI Plannings that you attended, people don’t have time for this, they don’t really understand this. It’s like people don’t have Sprint Goals, right?

Same story. We have a lot of work to do. We’re going to be busy for many years to come. No worries there. The money will never run out! Yes, yes.

So when we finish the PI - actually, every two weeks, at the… Or let’s start with the theory and my addition on top of it.

The theory is, at the end of the PI, we look at that plan of record PI Objectives, and we look at, okay, how did we do with these objectives? And we can, compare plan versus actual. There’s an additional level of granularity there, which is each PI Objective, both at the beginning and at the end of the PI, gets some sort of business value score on how much value, how much impact do we believe this PI Objective has on the business, or we believe it will have, and at the end of the PI, how much are we seeing before we even release it, which is a side conversation we can get back to.

And that enables us to get an understanding of: Are we even in the ballpark? Like, are we smoking something good when we’re planning the PI and ending up with 25% of our objectives achieved? Or are we more or less in the ballpark?

Like, is it 80%, 90%, 70%? That means we can, when teams commit to PI Objectives, it means something. That’s the conversation there. It’s not about PBIs. It’s about objectives and goals.

Ryan Ripley: I agree with you, and that’s heavily tied to, if we’re to pull in another idea to complicate this, if we’re looking at Evidence-Based Management, for example, that’s very heavy in Time-to-Market. It’s very disconnected from value because you’re even evaluating this before you release.

And so what I find though as the anti-pattern here is that there is some value-specific thing imbued on this metric, even though it is strictly tied to a time-to-market, delivery-based idea. Is that fair?

Yuval Yeret: I think, as you and I discussed, I’m not sure where to fit the PI predictability score to EBM. I think that’s a movie in and of itself that I’m happy to go into. But I fully agree that there’s a catch here that we are predicting, still predicting business value when we’re finishing the PI, unless we already delivered stuff, which you can do, by the way.

But most organizations don’t do it throughout the PI. I actually wrote a blog post, we can link to it in the notes, that talks about actual business value. I even talked at a SAFe Summit about this, to talk about, this gap that we need to close if we really want to be evidence-based in the conversations about PI Objectives.

Agile Release Trains and Continuous Delivery

Ryan Ripley: Well, and even like the heavy connection to the train and the release, right? Even this - because you just said, “You can release at any time during the train execution, or the PI work,” but you also said most organizations don’t. And that’s kind of an interesting - maybe that’s a future video, but that disconnect from value along with this PI score is interesting to me.

I’m not going to beat this point down any further, but that disconnect I think is problematic with this particular metric.

Yuval Yeret: Yeah. It’s an interesting - the name Agile Release Train is not a name that makes too much sense these days, if I’m honest about it. It’s kind of a side topic, but if you think about it, it makes a lot of sense when you think about where it’s coming from, but not the reality of Agile today.

The history of Agile Release Trains was, organizations, delivery organizations were struggling with the fact that since they didn’t have a cadence, or, their business, marketing, constantly pushed more and more stuff onto the release, and the release just, was a big avalanche, snowball that, never managed to cross the finish line.

And by moving into a train mode, it enabled control, it enabled some predictability of at least when the release was going to come out and also some of its content, and SAFe used that term to describe a structural element, which is the Agile Release Train, the team of teams. That has nothing to do with actual releases.

So in an Agile Release Train, we say that it develops continuously, we release on demand. So releases could happen at any time throughout the PI, could happen at the end of the PI, could happen once every couple of PIs if that’s your reality. But a lot of people still associate - every time I work with an organization, every class, people still associate, just because of the language, language is so important, people still associate an ART with a release, and by default go into this mode of “you don’t release throughout the PI, you release at the end of the PI.” So, I sometimes wish that the name for an ART would be different, but there’s a lot of legacy.

Changing the name of the ART is like - would we go and change Scrum Master to a different name in this day and age? Right. There are some problems with that name, but we’re not going to change that name.

Conclusion & Alternative Views of PI Planning

Ryan Ripley: No. And to me, as we come up on the half hour here, I look at PI Planning and, of course, I’ve taken a few shots at it, and I think there’s some interesting points for us to continue working through on future videos. We certainly want all of your questions and comments below. Make sure that you let us know your thoughts on PI Planning, your questions about it.

The charitable way that I look at this, right - so if I take some of the criticisms aside - what I think PI Planning has done is really taken the time that teams should be spending on Product Backlog refinement and formalized it. That’s kind of how I’ve rationalized it in my head. It’s basically saying Product Backlog refinement is now an event, and we’re calling it PI Planning, and you’re going to look at your Product Backlog and you’re going to add some detail, you’re going to forecast it out, you’re going to figure out some Sprint Goals, you’re going to do this as a team with your stakeholders, and you’re really just saying it’s no longer optional.

And when I think about it like that, I kind of close my eyes and I think this is probably okay. When I open my eyes again, I’m like, “No, no, no, we can’t do that.” But that’s kind of where my head space is at with it at this point.

Yuval Yeret: Let me suggest - that’s an interesting way to look at it. An alternative is to say PI Planning is the future of quarterly planning. Quarterly business planning, whatever. We understand, okay, what do we need to achieve as a business?

What can we actually do? Involving everybody that has a stake in actually making these things happen, rather than telling them, coming up with arbitrary - let’s talk OKRs. You know, one option is to come up with arbitrary objectives and key results and tell people, “This is what you’ll be able to do, this is what you’re going to do,” and then be surprised that doesn’t happen or the people are frustrated at the end of the quarter.

The alternative is to involve people and say, “Okay, this is where we want to go. This is what’s important to us. Let’s collaborate on the art of the possible. Share our thoughts, have a couple of rounds, and converge to a baseline plan, a starting point. We will evolve it throughout the PI or throughout the quarter for how are we going to run this quarter.” And it energizes people, it connects people.

It’s an opportunity, especially in this day and age of remote work, to actually get teams together, whether it’s together on Zoom or Teams or actually in the same room, and create some runway for collaboration for the next quarter.

Ryan Ripley: I wish every SPCT would watch this and execute PI Planning just as you described it. Because I wonder - and we have this problem on the Scrum side, right? Does the Scrum Master off the street execute Scrum the same way that someone who’s committed to this as a lifelong career?

Or does a SAFe Fellow needed to get PI Planning to this level? And so I, the way that you describe it, I would do what you just said over annual planning every day of the week and twice on Sunday, right?

I think that’s an excellent vision. What you described and what’s actually out in the world - and again, we have plenty of these issues on the Scrum side as well - I think what you described and what’s in practice, there’s a separation.

Yuval Yeret: Yeah. Jerry Weinberg called it the Law of the Raspberry Jam.

Ryan Ripley: Yeah. The further it spreads, the thinner it gets.

Yuval Yeret: Yeah. SAFe is very successful, and here it’s, it’s an issue. The expertise around how to do these sort of things well and understanding of the principles, it’s not spread as widely as I wish it would be.

Ryan Ripley: Very good. Well Yuval, thank you for talking through PI Planning, and thank you for working through some of those ideas. What do all of you think, right? How did - I think Yuval did great. How do you feel about it?

What are your questions? What are your comments? What have you seen in PI Planning? Leave it below. We’d love to see your comments. Your comments turn into future videos, so keep the good questions coming and we’ll keep recording videos.

Like and subscribe so you don’t miss future episodes. We’re going to keep publishing these probably once a week or so, so you don’t want to miss when these drop.

And again, just thanks for the great conduct in the community. We really appreciate it. We’ll be back next week with another Breaking the SAFe topic. For Yuval, I’m Ryan. Go forward and do your research. All of our resources are dropped in the description, so you can check out the websites we’re looking at and come to your own conclusions.

And let us know how that goes. We’ll see you next week.

Yuval Yeret: See ya, Ryan.