Every delivery lead has lived this moment. The forecast said the release would land on the 7th. The team believed it, leadership repeated it in a board deck, and then — week by week — the date quietly walked away from everyone. No one lied. The number was simply built on the wrong history.
A release forecast is only as honest as the agile throughput behind it. Throughput is the count of work items your team actually finishes each sprint, and it is the raw material a probabilistic forecast turns into a date. Give it a fair picture of how your team really delivers and the date holds up. Give it a holiday lull, a one-off crunch, or the pace of a team that has since been reorganized, and the forecast will be confidently, precisely wrong.
Agile throughput is the raw material of a release forecast
Under the hood, a good forecast does not guess. It samples your recent throughput — the last several sprints of completed work — and runs a Monte Carlo simulation across that window thousands of times to produce a range of finish dates. Advanced Release Planning reports that range as a committed date carried with its confidence: P50, P85, and P95, rather than one hopeful number. The math is only ever as good as the window it samples — which is why the window, not the model, is the decision that matters.
Consider two teams with the same average throughput. One has delivered a steady eight items a sprint for six months; the other averaged eight only because one frantic sixteen-item sprint offset weeks of three. Averaged blindly, they forecast the same date. But their spreads are nothing alike, and a forecast built on real sprint-by-sprint history will show it — the steady team lands a tight, trustworthy band; the volatile one a wide band that honestly says “we don’t know yet.” That honesty is the whole point.
Choosing a representative window is the team’s call
Here is the part the tooling cannot do for you, and should not pretend to: deciding which stretch of history represents your team’s real pace. That is expert engineering judgment, not a setting. Only the people in the room know that one sprint was gutted by an incident, that December straddled a shutdown, or that half the team joined in April. The raw throughput number carries none of that context. The team does.
In practice it is a short, repeatable conversation:
- A holiday or shutdown sitting inside the window? Widen it, or exclude the dead span, so a pause the calendar caused is not mistaken for your pace.
- A heroic crunch spiked one sprint? Reach for a longer window so the spike is averaged, not treated as the new normal.
- A reorg or a wave of new hires just landed? Shorten the window to the team that will actually do the work.
- Stable team, steady flow? The recent rolling default is exactly right.
None of these is a trick the software plays behind your back. It is the team applying what it knows, and the forecast doing the counting — the same division of labor as a SAFe confidence vote, where the room supplies the judgment and the vote simply records it.
Keep the window live, and the committed date stays honest
A confidence vote has one weakness: it is a snapshot, accurate the day it is cast and only that day. A throughput window has the same weakness if you set it once and forget it — so the forecast does not. As each new item completes, the window rolls forward and the simulation re-runs, so your committed date’s confidence reflects the pace you are holding this month, not the one you assumed in the planning room. The vote stops going stale the moment everyone leaves.
That live window is also what makes the three things that erode a committed release date — scope creep, late-surfacing dependencies, and capacity changes — visible in days instead of surprises. All three are measured against the committed date. If the throughput underneath that date was never representative, the erosion hides in the noise; get the window right and keep it current, and the same signal that reassured you at planning keeps warning you all the way to release.
For the mechanics — how the window is sampled and how it updates — see the feature doc Throughput Windows & the Release Forecast. For the wider picture, release date forecasting and forecasting from your team’s real track record are good next reads.
Forecast from the pace you actually hold
Your team already knows its real pace — the wins that will not repeat, the weeks that should not count, the version of the team that is actually shipping. Give it a forecast that respects that judgment and does the arithmetic at scale. See how Advanced Release Planning turns your team’s throughput into a release date you can defend — free for 30 days on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.