Stop Guessing Delivery Dates: Forecasting From Your Own Empirical Data
Scrum is founded on empiricism: you inspect what actually happened and adapt based on evidence, not on what you wish were true. Forecasting is where that principle is tested most directly. A team that forecasts well earns the right to be trusted with ambiguity; a team that forecasts badly gets micromanaged. The Scrum Guide deliberately leaves the method open, which is freedom that many teams misuse.
In early 2022, with hiring churn, return-to-office disruption, and supply-driven dependencies, the temptation to promise a clean date is strong and the cost of breaking that promise is high. A forecast is not a commitment; it is a probabilistic statement built from your real data. Get the distinction right and the rest follows.
Where forecasts go wrong
Treating story points as a unit of time. Points estimate relative effort, not hours, and they drift as the team learns. Converting points to dates with a fixed rate manufactures false precision. Throughput, the number of items finished per Sprint, is a cleaner basis for forecasting.
Forecasting from a single average. Saying the team does about ten items a Sprint hides enormous variation. One number gives you a 50/50 forecast at best. You need the spread, not just the middle, to say anything honest about a date.
Using too little history. A forecast built on two or three Sprints inherits all their noise. Use a rolling window of recent Sprints, enough to capture normal variation but recent enough to reflect the team as it is now, not as it was a year ago.
Ignoring scope growth. Forecasts assume the backlog stops moving, but real backlogs grow as work is discovered. If you don't account for the rate at which items are added, you forecast against a target that keeps receding.
Reporting a date as a promise. A single hard date invites disappointment. Communicating a range with confidence levels sets honest expectations and protects the team's credibility when reality lands somewhere inside the range.
A practical, empirical approach
Start by counting throughput per Sprint over a recent window of, say, six to ten Sprints. Look at the distribution, not just the mean. From there, the simplest honest forecast is a range: at the team's slow weeks it finishes this many items, at its typical pace this many, at its good weeks this many. Map those rates against the remaining (and growing) backlog to produce a likely-by date with a confidence band rather than a single point.
Forecast in items finished, using throughput, before reaching for points.
Express results as a range with confidence, never a lone date.
Account for backlog growth, not just the work you can see today.
Refresh the forecast every Sprint as new data arrives, and let it move.
If you want richer modelling, a Monte Carlo simulation over your throughput history turns the same data into probabilities.
None of this requires a heavy tool; a spreadsheet of completed-items-per-Sprint is enough to begin. The discipline is the point: forecast from what the team has actually done, communicate uncertainty plainly, and update relentlessly. That is empiricism applied to the future, and it is what separates a team people trust from one they second-guess.
If your teams are forecasting on hope instead of throughput and stakeholders have stopped believing the dates, XNM's program & project delivery advisory can help you build forecasts that hold up to scrutiny.