PI planning ends the way it should. The next eight weeks are planned down to the story. The quarter after that is a set of epics with rough sizes. The far horizon is three lines on a roadmap. The team looks at the near wave, takes its confidence vote, and commits to a release date. Nobody plans month six in detail, because nobody honestly can. That’s rolling wave planning, and it is the right way to plan.
Twelve weeks later, the release lands three weeks late — and no one can point to the meeting where that happened. That part isn’t rolling wave planning failing. It’s the one mechanic the method quietly assumes you’ve staffed, and almost nobody has.
What rolling wave planning actually is
Rolling wave planning is progressive elaboration with a calendar: plan the work in front of you in detail, keep distant work coarse, and add detail in waves as each horizon approaches. The PMBOK calls the underlying idea progressive elaboration; SAFe teams do a version of it every Program Increment whether they use the term or not. It exists because early estimates live inside the cone of uncertainty — pretending you can specify month six today isn’t planning, it’s fiction with extra steps.
So the method is sound. The near wave is detailed because it’s knowable. The far wave is coarse because it isn’t. The commitment, though — the release date your team voted on — usually spans several waves. And that’s where things get interesting.
Every wave re-opens the plan. Few teams re-check the date.
Each wave boundary is a re-planning event. Epics split into stories. “TBD” becomes twelve tickets. Integration work that was one line in January becomes a sprint of its own in March. This is the method working as designed: the plan is getting more accurate.
But watch what walks in through the same door. The three things that erode a committed release date all enter at wave boundaries. Scope creep, because elaboration almost never finds less work than the epic promised — and scope creep doesn’t wait for your next PI planning. Dependencies surfaced too late, because the detail pass is exactly when you discover the platform team’s handoff lands in your busiest sprint. Capacity changes, because the roster elaborating wave three is rarely the roster the vote assumed in wave one.
None of this means the confidence vote was wrong. That vote was expert engineering judgment on the evidence available at the time — the near wave in detail, the rest in outline. The judgment was sound. The evidence has simply changed since, one wave at a time, and in most teams nothing is responsible for noticing.
Keep the vote’s evidence current through every wave
A confidence vote is a snapshot. Rolling wave planning guarantees the picture changes after you take it — elaborating later is the entire point. So the question isn’t whether to plan in waves. It’s what keeps the commitment honest between the vote and the release.
That’s the job Release Management, Roadmaps & Product Portfolio for Jira was built for. Your team still owns every assumption behind the date — which throughput window to trust, whose capacity counts, what’s in scope. The app does the arithmetic at Monte Carlo scale and keeps it current: every story that elaboration adds to the Fix Version lands in the forecast the moment it lands in Jira, the simulation re-runs against the team’s actual throughput, and the committed date is carried with a live 50/85/95% confidence band. When wave-two detail moves the 85% date, you see the movement in days — that week, not in the retrospective.
Make the wave boundary a renegotiation point
With the forecast live, wave boundaries change character. Instead of being where erosion sneaks in, they become scheduled checkpoints where the team re-reads its own commitment: elaborate the wave, watch the band, and if the 85% date has drifted past the committed date, renegotiate scope while there’s still runway — move a Should below the cut-line, resequence the dependency, or re-vote with current numbers if the picture warrants it. The conversation happens before the slip, with evidence, instead of after it, with apologies.
Rolling wave planning tells you when to add detail. A live forecast tells you what that detail just did to your date.
Plan in waves. Commit with confidence that keeps up.
You don’t need a heavier planning process — you need the one you already have to stay honest between waves. Try Release Management, Roadmaps & Product Portfolio for Jira on your next PI and watch what each wave of elaboration does to your committed date, in days. For the mechanics, see how the live forecast tracks a committed date across planning waves in the docs.
Leave a Reply
Your email is safe with us.