I was going through this interesting discussion1 about PI Planning recently, because I’m in the middle of writing2 about the first PI Planning I participated in as well.

I have not encountered the hosts before, but I take it that this is a discussion between someone who is represents Scrum, Ryan Ripley and SAFe, Yuval Yeret, respectively. I picked up that Yuval represents the business perspective and when he hears statements like “it’s done when it’s done”, he thinks “not mature”. He says you need some predictability to be serious about business. Overall he characterized PI Planning as how to “assume viability, while preserving options”.

For him, PI Planning is one more level of detail than 5-6 sprints ahead with one sprint goal per sprint. He wants the one level deeper I think, not to have a more specific plan that is brittle but because he sees if you don’t think more deeply, you will not consider the possible things that could go wrong and you’ll form an unrealistic plan.

However he sees PI Planning as both producing a forecast–also calling it a hypothesis–as well as a commitment, which are basically the opposite 😂. Rather, yes technically you can commit to a forecast, but “forecast” is by definition, not a commitment.

But he sees PI Planning as coming from a good place, as an improvement upon existing quarterly OKR planning which is like a tablet handed to Moses from a sky god, more or less.

Instead he sees PI Planning as create a runway for collaboration, getting everyone in the room, aligning on priorities, and coming up with a reasonable expectation for the outcome.

I think Yuval has heard the actual utterance “it’s done when it’s done”, but he is framing a strawman argument–most critics of predictability simply prefer to under-promise and over-deliver. He talks about being “data driven” but I didn’t really hear him talk about using error bars in PI Planning.

The other host, Ryan Ripley, says that one sprint backlog is challenging enough but duct taping together 6 is guaranteed failure. Yuval says backlogs are not the deliverable from PI Planning; it’s more like sprint goals and one more level of detail of how those sprint goals are achieved.

Ryan has this good quote, at 13:10 that “you adopt scrum, because you embrace uncertainty and want to manage risk. And instead go SAFe if you reject uncertainty and want predictability.” And Yuval hits back with, 14:50 “can’t have full predictability but can prioritize”.

So I like the collaboration part I hear, I like the words “forecast” and “hypothesis” when I hear it , but I feel like Yuval is trying to have it both ways , in a forecast that you commit to. That makes no sense to me 😂.

The alternative to me is, why not do best of both world’s.

Take the PI Planning’s collaboration spirit , and agreeing on priorities with everyone in the room. And produce OKRs, that are therefore negotiated, coming fairly from all parties involved. OKRs are more battle tested, because the objectives are super clear and the KRs are measurable. And you label what is stretch, which is what makes it more like a forecast with error bars.

And to me predictability should be flipped on its head, as not predict the arrival of each sprint goal, at each sprint, but instead just get good at a predictable throughput of deliveries. But keep it agile, meaning you are open to changing the actual deliverables, because as Ryan also pointed out, all along you are also predicting what is valuable, but you cannot know until after features are delivered and their impact is measured. This is also why in the Shape Up book, they call3 their OKRs “bets”.

References

  1. https://youtu.be/jHRsBDC5E9Q , Yuval Yeret and Ryan Ripley, “Breaking the SAFe: Deconstructing PI Planning”
  2. still writing this.
  3. Shape Up, “Bets not Backlogs”, https://basecamp.com/shapeup/2.1-chapter-07