The PI planning room agreed on December 12. Nobody in it was guessing. The teams had twelve weeks of throughput on the wall, they had walked the program board dependency by dependency, and they knew who was out over the holidays. The fist of five came back high, the date went on the slide, and everybody went back to work.
Six weeks later, December 12 is still on every slide. The difference is that nobody can tell you whether it is still true — and not because anyone got careless. The commitment reaches twelve weeks out. The evidence behind it reaches about five. Classical planning has a name for that distance: the planning horizon.
What a planning horizon actually is
Your planning horizon is how far into the future your current information can honestly support a decision. Inside it, you are planning. Past it, you are extrapolating — and the quality of the answer degrades a good deal faster than most plans admit.
This is not a new idea, and agile practice already leans on it. Rolling wave planning is built on exactly this premise: elaborate the near wave in detail, leave the far wave deliberately coarse, and re-elaborate as the horizon advances. The discipline is sound.
The trouble is that a release commitment does not respect the horizon. The confidence vote is taken once, at the start, and it covers the whole increment — including the weeks that sit well past the point where anyone’s information is any good.
The far end blurs for three specific reasons
It is worth being precise here, because the usual diagnosis — “the estimates were optimistic” — is both unkind and wrong. A fist-of-five vote is expert engineering judgment. The teams who raised five fingers were reading their own throughput, their own dependencies and their own roster correctly, on the day they read them.
What degrades is not the judgment. It is the inputs the judgment was formed on, and they degrade in three specific ways after the vote: scope is added one small approved change at a time, a dependency surfaces that nobody had drawn on the board, and capacity moves when someone is pulled onto an incident or leaves the team. Those are the three things that quietly move a committed release date after everyone has already agreed to it — and every one of them lands in the part of the increment that was past the horizon to begin with.
You cannot lengthen the horizon. You can keep moving it.
Teams usually try to solve this by planning harder up front: more detail in the far wave, more buffer, a longer estimation session. It does not work, because the missing input is evidence that does not exist yet. No amount of care on planning day produces sprint-seven throughput in week one.
What does work is re-running the arithmetic as the evidence arrives. The team still owns every assumption — which throughput window is representative, whose capacity counts, what is genuinely in scope. Release Management, Roadmaps, Portfolio PPM & Timeline takes those assumptions and does the Monte Carlo arithmetic against the team’s actual delivered throughput, then does it again whenever the underlying Jira objects change. The committed date is carried with a confidence band — P50, P85, P95 — rather than as a bare date on a slide.
The band is the planning horizon made visible. Where the evidence is thin, the band is wide. As sprints complete and throughput history accumulates it narrows — not because time passed, but because delivered work reduced the variance. And when scope is added or a dependency surfaces, it widens again, in days, attributed to the thing that caused it.
What it changes in a review
Instead of “are we still good for December 12?” — a question the far end of the horizon genuinely cannot answer — the conversation becomes: December 12 currently reads 62% on present throughput, down from 88% three weeks ago, and nine of those days came from the two stories added in sprint 4.
That is a renegotiation you can hold in week six, while there is still room to cut scope or move the date deliberately, rather than a slip you discover in week eleven. It is also why committing to a release window instead of a single date is the more honest promise when the horizon is genuinely short.
Three things to do on Monday
- Name your horizon. Ask the team how far out their throughput numbers still feel trustworthy. Five weeks is a common answer for a twelve-week increment. Write it down next to the committed date.
- Carry the confidence with the date. A date on a slide with no percentage beside it is a claim about the far end of the horizon with nothing standing behind it.
- Re-read it weekly, not at the PI boundary. The vote was a snapshot. Keeping it current is what turns a week-eleven slip into a week-six renegotiation.
The neutral reference for how the percentile levels are computed is in the planning horizon documentation.
Keep the horizon moving. Release Management, Roadmaps, Portfolio PPM & Timeline runs natively on Atlassian Forge, reads the throughput your teams already produce, and carries every committed date with a live confidence band. Find it on the Atlassian Marketplace.
2 Comments
Leave your reply.