Forecasting Sprint by Sprint: Using Your Own Data Instead of Guesswork
Eighteen months into a disrupted world, a lot of teams were asked the same uncomfortable question: when will it be done? Supply chains were still unreliable, half the team was working from a kitchen table, and the old habit of promising a fixed date based on a wish had aged badly. Scrum offers a better answer, and it does not require a crystal ball. It requires that you actually use the data your team is already producing.
Scrum is built on empiricism: you make decisions based on what is observed, not on what was assumed at the start. Forecasting is simply that principle applied to the future. Instead of declaring a date and hoping, you measure how much work your team has genuinely completed over recent Sprints and project that rate forward, while being honest about the uncertainty around it.
Start by measuring throughput, not promises
The most useful number is also the simplest: how many Product Backlog items did the team actually finish, Sprint by Sprint? This is throughput. You can use story points if your team estimates consistently, but counting completed items often works just as well and removes a lot of argument. Pull the last eight to twelve Sprints of real data. Do not smooth it, do not delete the bad Sprints, and do not include items that were 'almost done' — the Definition of Done is binary for a reason.
Count only items that met the Definition of Done in that Sprint.
Use a consistent window — eight to twelve recent Sprints reflects current reality without ancient history.
Keep the spread visible: a team that delivers 4, 9, 6, 3, 8 is telling you something a single average hides.
Turn the data into a range, not a date
Once you have a Sprint-by-Sprint record, forecasting becomes arithmetic plus humility. The honest output is never a single date; it is a range with a confidence level attached.
Size the remaining work. Count the Product Backlog items still required for the goal you are forecasting. Order the backlog so the most important items are included first.
Find your realistic pace. Take the throughput from recent Sprints. A pessimistic forecast uses your slower Sprints; an optimistic one uses your faster ones.
Divide to get a Sprint count. Remaining items divided by throughput gives a number of Sprints. Doing this with both your slow and fast pace produces an honest 'between X and Y Sprints' window.
Re-forecast every Sprint. New data arrives every Sprint Review. Update the forecast then — a forecast that never moves is being ignored, not trusted.
Make the uncertainty a feature, not a confession
Stakeholders under pressure want a single date, and the instinct is to give them one to look decisive. Resist it. A forecast presented as 'most likely six Sprints, possibly as many as nine if the integration risks land' is far more useful — and more credible — than a confident '24 March' that everyone privately knows is fiction. When the pandemic years taught us anything, it was that variability is real and pretending otherwise just moves the disappointment later. Communicate the range, name the assumptions behind the optimistic end, and let the Product Owner make trade-off decisions with eyes open.
One caution: empirical forecasting only works if your Sprints are real Sprints. If 'done' keeps slipping, if work bleeds across Sprint boundaries, or if the team is interrupted constantly, your throughput data is noise and your forecast inherits that noise. Fix the delivery discipline first; the forecast will follow.
Building a forecasting habit that stakeholders actually trust takes more than a spreadsheet — it takes delivery discipline and clear governance. XNM's program & project delivery advisory helps teams put both in place.