I was the enterprise coach for a PI Planning event on an enterprise client’s Lead to Cash redesign and platform replacement. More than a dozen teams in the room, a tight leadership-mandated timeline, and the kind of scope that made everyone a little nervous walking in. Then came the leadership review and problem-solving session, a standard part of any PI Planning event I was there to facilitate, and the math came back clear: the total planned load ran three to four sprints over what those teams could actually deliver in that Planning Interval.
Leadership understood exactly what that meant. They took the number up the chain and told their executive leaders the truth. The executives didn’t move the date. The teams were told to proceed and keep leadership updated as the Planning Interval played out. That’s the moment PI Planning is actually built for, surfacing a real capacity problem before a single sprint starts. But surfacing a problem and fixing it are two different things, and only one of those was in the team’s control.
The Problem-Solving Session Did Exactly What It Was Supposed To
We consistently see teams treat the PI Planning problem-solving session as a formality, something you get through on the way to the plan of record. It isn’t. It’s the one point in the whole Planning Interval where a room full of the people actually doing the work gets to say, out loud, “this doesn’t fit,” before anyone has committed to it publicly.
That only works if the backlog going in is refined enough to produce an honest number. Guess at scope, and the math you get back in that session is just as much of a guess, and easy for leadership to wave off. Getting a room full of teams to a real, defensible capacity read is exactly what the WSJF Workshop Guide is built to produce, a repeatable way to size and sequence a backlog so the numbers that show up in problem-solving are numbers people actually trust.
Escalating a Problem Isn’t the Same as Solving It
Here’s the part that’s harder to talk about. Leadership did their job. They didn’t bury the number, they carried it to the people who could change the date. The people who could change the date chose not to.
That’s a gap we see constantly between portfolio-level commitments and team-level reality: someone sets a date based on market pressure or a board commitment, and by the time it reaches the teams who have to deliver against it, there’s no mechanism left to reopen that conversation, only a mechanism to report on progress against it. Closing that gap is the whole point of a Strategic Themes Workshop, connecting the portfolio-level decisions that set dates to the team-level data that tests whether those dates are real.
Scaled Agile’s own team makes a version of this same point in their Business Agility Podcast, worth a quick watch if this pattern sounds familiar:
Three Sprints Late, and What Came After
The teams delivered three sprints late. Given the size of the gap identified back in problem-solving, that outcome shouldn’t have surprised anyone, and to this client’s credit, it didn’t turn into a blame exercise. Leadership ran a full, detailed roadmapping session and a genuine retrospective on what had actually happened, not a quick recap, a real look at the outcomes.
Expectations got reset based on that work, and future delivery dates moved based on real data instead of the original mandate. That’s a heavier lift than a normal end-of-PI retro, and it’s exactly the kind of after-action review a lot of teams skip once a deadline has already been missed and everyone just wants to move on. A Sprint Retro Survey is a lighter-weight way to keep that muscle in shape every Planning Interval, not just after a miss.
This Isn’t Really a Story About Missing a Date
Here’s the reframe. The interesting part of this story isn’t that the team was three sprints late. Overcommitted plans run late, that’s not a surprising outcome, it’s close to a guaranteed one. The interesting part is which number won when the planning was happening: the mandated date, or the real capacity data sitting right in front of everyone in that problem-solving session.
The date won that round. It usually does, in the moment, because changing a date that’s already been communicated upward costs someone political capital, and ignoring a capacity number costs nothing until sprints start slipping. But the org didn’t stop there. The retrospective and re-plan that followed put the real data back in charge for the next round, and that’s the part worth learning from, not the miss itself.
So the real question after a PI Planning event isn’t whether the math came back clean. It’s what your leadership actually does the moment it doesn’t.
If this sounds like where your organization is right now, this is exactly the kind of work we do at Stephens Insight Group. Talk to us about your transformation
Sources
- PI Planning — Scaled Agile Framework
- Inspect and Adapt — Scaled Agile Framework