Two sprints can both close at exactly 34 points and mean completely opposite things for your roadmap.
One team hit 34 points by finishing what they planned, on time, with capacity to spare. The other hit 34 points by descoping two stories mid-sprint, carrying a third into next sprint, and quietly inflating the estimate on a fourth so the burndown chart looked less alarming in the retro. Same number. Different reality. If you're using that number alone to tell your VP of Engineering when a feature ships, you're reporting a lagging indicator as if it were a forecast.
Velocity measures what happened, not what's coming
Velocity is an average of completed story points per sprint. That's useful for exactly one thing: sanity-checking how much work a team can plan for next sprint. It was never designed to answer "when will this ship" — that requires knowing scope, dependency risk, and how the current sprint is actually trending, none of which velocity captures.
> A velocity number is a photograph of the last few sprints. A delivery date is a claim about the future. You cannot derive one from the other without additional information the photograph doesn't contain.
Three specific blind spots show up constantly on real teams:
1. Estimate inflation hides in the average. If a team starts padding story points to protect their velocity number, the average goes up while actual throughput stays flat or falls. Velocity looks healthy. Delivery dates slip anyway.
2. Variance disappears into the mean. A team that does 20, 48, 20, 48 points has the same average velocity as a team that does 34, 34, 34, 34 — but wildly different risk profiles for any date-based commitment. Averaging removes the exact information you need to size a buffer.
3. Velocity says nothing about what's blocked right now. A sprint can be tracking at a normal burn rate on day 3 and be in real trouble by day 7 because of a dependency nobody flagged at planning. Last sprint's velocity has no visibility into this sprint's live state.
What actually predicts a delivery date
Forecasting a date well requires combining velocity with two things it doesn't include: a live read on how the current sprint is trending, and a plan for what happens when it's off-track — not after the fact in a retro, but while there's still time to act.
In Spryn, this is why sprint forecast and burndown live on the same board as velocity rather than in a separate report someone pulls at sprint end. Reports let you filter by velocity window so you're comparing forecast against a rolling average instead of a single noisy sprint, and burndown shows the current sprint's actual burn rate against that baseline in real time — so a team on trend looks different from a team about to miss, days before the sprint closes rather than at the retro.
The harder problem is what to do once you see the miss coming. Most tools stop at showing you the burndown line bending the wrong way and leave the "now what" to a Slack thread. Spryn's recovery plans are built as an explicit step after that signal: preview what descoping, re-sequencing, or extending the sprint would actually do to the forecast, apply the change if it makes sense, notify the people whose work shifted, and undo it if the situation changes again. That loop — detect, preview, apply, notify — is the part a bare velocity chart can't give you, because velocity only ever looks backward.
The three-number check before you commit to a date
Before you tell anyone outside the team when something will ship, check three numbers instead of one:
1. Velocity window, not a single sprint. Use a rolling average over your last several sprints, not the most recent one — one great or one terrible sprint shouldn't set the forecast.
2. Current burn rate against that baseline. Is the active sprint tracking ahead, on pace, or behind the velocity-based forecast right now — not at planning, today.
3. What the recovery plan looks like if it's behind. If the sprint is off-track, know what descoping or re-sequencing actually buys you before you're forced to explain a miss after the fact.
A velocity number you report without these three checks isn't a forecast — it's a guess wearing a forecast's clothes. Teams evaluating a self-hosted sprint planning tool for this reason specifically (see spryn.io/pricing) are usually the ones who've already been burned by a Jira dashboard that reports the same lagging average without the second two numbers attached.
Velocity isn't wrong. It's incomplete. Treat it as one input into a forecast, not the forecast itself, and the gap between "the chart said we were fine" and "we missed the date" stops being a surprise.