Why Using Historical Velocity For Sprint Forecasting Breaks Down (And How To Do It Right)

Most sprint forecasts fail for one boring reason. Teams treat historical velocity like a promise instead of a range.

Velocity can help you forecast. But only if you handle it like a probabilistic signal, not a performance target. Otherwise you get the usual pattern: a “commitment” that drifts, a mid-sprint scope swap, and a retro full of half-truths.

AgileHour’s view is simple. Using historical velocity for sprint forecasting in agile teams works when you forecast capacity and uncertainty, not when you use velocity to pressure people.

What velocity is actually telling you

Velocity is a record of how much “done” work a team finished per sprint, measured in whatever unit you use (often story points). That’s it. It’s not productivity. It’s not value. It’s not effort.

That matters because forecasting is about what’s likely to happen next, given what happened before. Velocity is one input, and it’s noisy. Team composition changes. Work mix changes. Dependencies change. Your definition of done changes. Even your estimation habits shift after a few painful misses.

If you want a grounded framing, Mike Cohn has long positioned velocity as a planning tool, not a scorecard. His company’s planning resources are a useful reference point for how practitioners think about it. See Mountain Goat’s velocity overview.

Velocity is descriptive, not prescriptive.

The most common failure mode: forecasting with a single number

Open any Jira board, look at the last five sprints, average the velocities, and you’ll get a neat number. It feels scientific. It also leads teams straight into false certainty.

Here’s what usually happens:

• The team picks the average velocity (say, 38 points) as the sprint “capacity.”
• They fill the sprint with 38 points.
• Unplanned work lands on Tuesday. A dependency slips on Thursday. A key engineer is out sick.
• Now the team either misses the sprint or cuts corners to “hit 38.”

A single-number forecast has no room for variation. And variation is the default state of software delivery.

Unhedged opinion: if your sprint forecast is one number, you’re not forecasting. You’re guessing with confidence.

Build a forecast that respects variation

Using historical velocity for sprint forecasting in agile teams gets more reliable when you move from “What will we deliver?” to “What’s the likely range of outcomes?”

Step 1: use a range, not an average

Start with your last 6 to 10 completed sprints, from the same team, with a stable definition of done. Pull the finished velocity per sprint. Don’t include sprints with major anomalies unless you’d expect similar anomalies again.

Now compute three numbers:

• Low: the 20th percentile (or roughly the second-lowest in a set of 10)
• Middle: the median
• High: the 80th percentile (or roughly the second-highest in a set of 10)

If your last 10 velocities were: 31, 34, 35, 36, 36, 38, 39, 41, 44, 46, your range might be roughly 34 to 44, with a median around 37 to 38.

That range is your planning envelope.

Step 2: forecast at a confidence level

Stakeholders don’t actually need certainty. They need a probability they can plan around.

Try language like:

• “We have an 80% chance of finishing 34 points or more.”
• “We have a 50% chance of finishing around 38 points.”
• “If everything goes well, we might reach 44, but plan on 38.”

This aligns with how serious forecasting works in other domains. Weather forecasts aren’t one number for rainfall. They’re probabilities.

If you want a statistical backbone, a readable starting point is the NIST Engineering Statistics Handbook. You don’t need to become a statistician. You just need to stop pretending variability doesn’t exist.

When historical velocity becomes misleading

Velocity only helps when the future resembles the past. In enterprise software, that’s often untrue for long stretches.

Here are common cases where historical velocity should not be your primary forecasting input:

• New team or newly formed squad. You don’t have a stable system yet.
• Major change in team composition. Losing a tech lead for a quarter isn’t “noise.”
• Large shift in work type. Maintenance to greenfield, or UI to platform, changes estimation behavior.
• Definition of done change. Adding security review, performance testing, or documentation will reduce throughput.
• Sprint length change. Two-week to one-week sprints changes overhead and flow.

This is where teams get trapped. Leadership asks, “Why did your velocity drop?” and teams respond by inflating story points to make the chart look better.

Jira makes that temptation convenient. It will happily plot velocity charts sprint over sprint, even when the work is not comparable. Atlassian’s own docs explain the mechanics in Jira’s velocity chart guide, but the tool can’t tell you when the underlying system changed.

Humans have to do that.

A practical forecasting workflow you can run in sprint planning

This is the workflow we’ve seen work in real teams because it fits into the meeting you already have. No new ceremony. No spreadsheet theater.

1) Set capacity in hours first, then translate to points

Before you talk points, do a quick capacity check:

• Who’s out for PTO or on-call rotation?
• What’s the expected interrupt load (support tickets, production incidents, customer escalations)?
• Any planned work outside the sprint goal (security patch window, audit requests, training)?

Write down an honest capacity adjustment. Example: “We’re down 15% due to two days of PTO plus on-call.”

Then apply that to your velocity range. If your median velocity is 38 and you’re down 15%, your median forecast becomes about 32.

This is more defensible than hand-waving after the sprint fails.

2) Plan to the median, keep a small buffer

Fill the sprint to the median forecast, not the high end. Keep a small buffer, usually 10% to 20%, for the work you don’t know about yet.

Yes, you’ll occasionally “under-commit.” That’s fine. Under-commitment is cheaper than a sprint goal that collapses on day eight.

One sentence that changes planning behavior: “We’re optimizing for hitting the sprint goal, not for filling the sprint.”

3) Use a sprint goal as a forcing function

Velocity forecasts don’t protect you from a sprint stuffed with unrelated items. A sprint goal does.

If the sprint goal is “Enable SSO for Enterprise customers,” then stories that don’t support it become optional, regardless of points. When new urgent work arrives, you can trade it against optional scope without turning the sprint into a scrap pile.

Scrum.org’s Sprint Goal guidance is worth a skim if your goals have turned into vague labels like “Sprint 14 work.”

4) Re-forecast mid-sprint, but don’t renegotiate reality

If you’re using historical velocity for sprint forecasting in agile teams, you should also accept that forecasts update. Mid-sprint check-ins should answer two questions:

• Is the sprint goal still achievable?
• If not, what will we remove or split to protect it?

Don’t turn that into a morale-killing status ritual. It’s a planning adjustment, not a courtroom.

Stop using velocity as a performance metric

Velocity-as-KPI is the fastest way to ruin both your forecasts and your culture.

When leaders compare team velocities, teams respond rationally. They change what the metric measures. Story points creep upward. Estimation becomes political. Engineers avoid necessary refactors because they’re “hard to point.” QA work gets shoved to the next sprint to keep the chart green.

This isn’t theoretical. It shows up in the artifacts. You’ll see velocities that rise while cycle time stays flat. Or worse, defects rise.

If you need metrics that are harder to game, complement velocity with flow metrics like cycle time and throughput. Actionable Agile’s resources are a practical starting point for that mental model, including their flow metrics explanations.

Velocity should stay inside the team. Forecast outputs can go out. Raw velocity charts shouldn’t.

Better than velocity alone: pair it with cycle time for forecasting

Velocity works best when you deliver in reasonably similar-sized slices. Many enterprise teams don’t. They have a mix of “2-point” tweaks and “13-point” cross-service changes that touch auth, billing, and data migration.

That’s where cycle time can rescue your forecasting.

If you track how long work items take from “in progress” to “done,” you can forecast delivery dates using probabilistic methods (often Monte Carlo simulation). You don’t need to implement a full simulation to benefit. Even a simple cycle time scatterplot will tell you if your system is stable enough to forecast.

Concrete example: if your last 30 stories show a cycle time between 2 and 9 days, with a median of 4, then a batch of 10 similar stories isn’t “10 x 4 = 40 days.” It’s a distribution. Some will finish fast. A couple will drag.

Velocity ignores that shape. Cycle time exposes it.

In Jira, you can approximate this with control chart data, or export issues and compute cycle time externally. Many teams use Jira plus a spreadsheet for this, or add-ons that compute cycle time automatically. The tooling matters less than the habit of looking at the spread, not just the average.

Common questions teams ask when they start doing this seriously

How many sprints of history do we need?

Six is a minimum. Ten is better. More than 12 can be misleading if your system changed. If you’ve had a reorg, a platform migration, or a major product shift, reset the window.

What if our velocity swings wildly?

Then your system is unstable, and the forecast is telling you that.

Look for root causes you can actually change:

• Too much work in progress, leading to half-finished stories at sprint end
• Dependencies that land late and block finishing
• Stories that are too large and hide risk until the end
• Interrupt load that’s unmanaged and unplanned

Don’t respond by demanding “better estimates.” That’s the lazy move.

Should we re-estimate unfinished work?

Re-estimate when you learned something real. Don’t re-estimate to protect velocity. If a story was “8” and it turns out you uncovered a data quality mess and it’s now a bigger problem, re-estimate. If it just didn’t get done, keep the estimate and ask why flow broke.

Next sprint, run this as an experiment

Pick one team and try a two-sprint experiment. Keep it small and observable.

1. Pull the last 10 sprint velocities.
2. Compute a low, median, and high (20th, 50th, 80th percentile).
3. Adjust the median for known capacity hits (PTO, on-call, training).
4. Plan to that adjusted median. Keep 10% to 20% buffer.
5. Publish the forecast as a range with a confidence level, not a single number.
6. In the retro, compare forecast range vs actual, and name the top two sources of variance.

If your stakeholders push back because they want a single number, don’t argue theory. Show them how often that single number has been wrong.

Historical velocity can be useful. Treat it like weather data, not a quota, and your sprint forecasting will finally start behaving like forecasting.