A product manager asks when the reporting module will ship. The tech lead, cornered in a hallway, says "probably early November." Three weeks later that sentence is a milestone on a roadmap slide, in bold, with a little flag icon. Nobody decided to commit to November 3rd. It just happened, the way water finds a crack.

This is how most delivery dates are born, and it's why teams end up "late" against dates they never actually agreed to. The fix isn't better estimation. It's refusing to hand over a single date in the first place. A forecast is a range with a confidence level attached. A date is a promise. Those are different objects, and the moment you let one masquerade as the other, you've lost.

Velocity gives you a way to produce honest ranges with about ten minutes of arithmetic. Let's do the arithmetic, and then, more importantly, talk about how to say it out loud without it hardening into a promise anyway.

The math is the easy part

Take a concrete case and carry it through. Your backlog for the release is roughly 120 points. Your last six sprints came in at 21, 18, 24, 22, 26, and 19 points. Two-week sprints, next one starts the first week of August.

Don't average those numbers. Averages are how you get one date, and one date is the thing we're avoiding. Instead, take the spread:

  • Pessimistic: 120 divided by your worst recent sprint (18) is 6.7, so 7 sprints. That's 14 weeks, landing you around mid-November.
  • Optimistic: 120 divided by your best recent sprint (26) is 4.6, so 5 sprints. That's 10 weeks, landing mid-October.

So the honest answer is "somewhere between mid-October and mid-November, before we account for scope growth." (We'll account for it. It's going to hurt.)

Two rules about which velocity numbers you're allowed to use. First, use a rolling window of the last five or six sprints, not the all-time average. Your team a year ago had different people, a different codebase, and different problems. Old velocity is data about a team that no longer exists. Recent velocity is data about the team that will actually do this work. Six sprints is enough to smooth out noise without dragging in ancient history.

Second, never plan around your best sprint. That 26 probably happened because two stories turned out simpler than estimated, nobody was sick, and no production fire ate a Thursday. Your best sprint is what happens when everything goes right, and everything does not go right for fourteen consecutive weeks. It belongs in the range as the optimistic edge, clearly labeled as the edge. It is not a baseline. Any plan that requires your best sprint six times in a row isn't a plan, it's a wish with a spreadsheet.

Notice what the range does for you psychologically. When you produce a single number, every conversation becomes a negotiation about that number. When you produce a range, the conversation becomes about what drives the width, which is a conversation about the actual work. That's the conversation you wanted all along.

One prerequisite worth stating: this only works if your points mean something consistent. If your team is still fuzzy on that, start with what story points actually measure and come back. Forecasting garbage points gives you garbage ranges, with confidence.

Saying it out loud

Here's how the forecast sounds when you deliver it well: "Based on the last six sprints, this lands between mid-October and the end of November. Mid-October needs everything to break our way. End of November assumes our slowest recent pace plus the scope growth we always see. If you want the range tighter, the biggest lever is the reporting export epic, which is a third of the backlog and the least understood part. Give us one sprint to spike it and I can probably cut three weeks off the uncertainty."

Compare that with "November 3rd." The single date invites exactly one follow-up: can you make it October 20th instead? Now you're haggling, and every concession you make is a promise you can't keep. The range invites a different follow-up: what would tighten it? That question has real answers. Descope the export formats. Stop pulling the team onto support rotations. Fund the spike. You've just converted a pressure conversation into a trade-off conversation, and trade-off conversations are ones where stakeholders can actually help you.

Some stakeholders will push back: "I can't put a range on the roadmap." You can offer the pessimistic end as the committed date and the optimistic end as the internal target. That's not a trick, it's how confidence works. Committing to the date you'll hit nine times out of ten is called being reliable. Committing to the date you'll hit two times out of ten is called being popular in July and unemployed in December.

Scope grows while you burn it down

Now the part that quietly wrecks forecasts even when the velocity math is clean. That 120-point backlog is not 120 points. It's 120 points today. Every sprint, someone discovers the export needs a permissions layer, legal wants an audit trail, and a "small tweak" from a customer demo becomes eight points of work. Backlogs grow while you burn them down. Almost every release does this, and almost every forecast pretends it won't.

You have two defenses, and you should use both. The blunt one: add a growth factor. If your backlog historically grows 10 to 20 percent over the life of a release (look at past releases, you'll find it), forecast against 135 to 145 points, not 120. In our example, 140 points at 18 a sprint is 8 sprints, which pushes the pessimistic edge to late November. That's where the "end of November" in the stakeholder script came from. It wasn't padding. It was history.

The precise one: re-forecast every sprint. Ten minutes at the end of sprint planning. New backlog total, divided by current min and max velocity, updated range. When the range moves, say so immediately, while the movement is small and boring. "The window shifted a week right because we found the permissions work" is a calm sentence in week three. It's a career conversation in week thirteen. Teams that surface drift early get trusted with ranges. Teams that sit on drift get micromanaged with dates, and honestly, they've earned it.

The two lies

Velocity forecasts fail honestly when the work surprises you. They fail dishonestly in two specific ways, and both are self-inflicted.

The first lie is cherry-picking the window. The forecast looks bad, so someone suggests dropping sprint 14 from the calculation "because half the team was out" and sprint 16 "because of the migration." Every excluded sprint has a reason. That's the trap: there's always a reason, because something disruptive happens in most sprints. Sick days and migrations and production incidents aren't anomalies, they're the texture of real delivery, and your forecast needs to include their cost. The window is the window. Last six sprints, whatever they were. The moment you start editing history to improve the forecast, you don't have a forecast anymore, you have a pitch deck.

The second lie is counting carry-over as done. A 13-point story that's "90 percent finished" at sprint end contributes zero to velocity. Not 11.7 points. Zero, until it's actually done. This feels brutal, and teams soften it by awarding partial credit, and then their velocity numbers describe effort spent instead of work finished. Forecasts built on effort tell you when the team will be tired. Forecasts built on finished work tell you when the customer gets software. Only one of those is worth putting in front of a stakeholder. If the zero stings, good. The sting is information: your stories are too big, or your sprints are ending on hope. If big stories are the pattern, that's a refinement problem to fix in sprint planning, not a bookkeeping problem to fix in the velocity spreadsheet.

Do you need Monte Carlo?

Somewhere around here, someone mentions Monte Carlo simulation. It's a real technique: instead of just min and max, you randomly sample thousands of possible sprint sequences from your history and get a full probability curve. "85 percent confidence of finishing by November 20th." Tools exist that do this from your issue tracker automatically, and for large programs with many teams and real money riding on the date, they're worth it.

For one team forecasting one release? The min/max range gets you 80 percent of the value with none of the setup. The hard parts of forecasting were never mathematical. They're behavioral: keeping the window honest, counting only finished work, re-forecasting when scope grows, and having the spine to present a range when someone senior wants a date. No simulation fixes those. Get the habits right first. Upgrade the math later if you still feel the need. Most teams never do.

When this doesn't work at all

Velocity forecasting has real preconditions, and pretending otherwise produces ranges that are just theater with error bars.

A brand-new team has no velocity. Three sprints of history is barely a trend; one sprint is an anecdote. For the first couple of months, say the honest thing: "We don't have enough data to forecast yet, ask me again in six weeks." That answer is uncomfortable exactly once. A made-up range is uncomfortable forever.

A team whose sprint scope swings wildly can't forecast either. If half the team gets yanked onto a different product every other sprint, your velocity history describes five different teams wearing the same name. Fix the staffing chaos first; no math survives it.

And if your points have been quietly corrupted into hours, with a conversion table on a wiki somewhere and estimates that are really day-counts wearing Fibonacci costumes, your velocity is measuring the wrong thing entirely. There's a longer argument about when hours work and when points do, but the short version is that a forecast built on corrupted points inherits all the problems of hour-based project estimation while pretending it hasn't. If that's where your team is, either rehabilitate the points, with real relative estimation in planning poker (this is roughly why ScrumMastr exists), or drop the pretense and forecast in hours honestly.

Make the range the habit

If you do only one thing from this article, do this: at the end of your next sprint planning, spend ten minutes producing the range. Backlog total, divided by your slowest and fastest of the last six sprints, plus your historical growth factor. Write down both dates and the assumptions next to them. Then, and this is the actual discipline, repeat it every sprint and report the movement, not just the answer.

The range itself is almost trivial. The habit of re-forecasting in public is what changes how your organization treats you. Stakeholders stop asking "when will it be done" and start asking "what moved the window," because you've taught them that the window is alive and honest. That trust is the real deliverable. The dates are just arithmetic.