Sprint Velocity Calculator
The formula
Velocity is a capacity measure, not a scoreboard
Velocity only means something within one team — comparing across teams is meaningless because points are relative to each team’s estimation baseline. Its legitimate uses: forecasting release dates (backlog ÷ velocity) and setting realistic sprint commitments. If velocity trends down over several sprints, look for growing technical debt, increasing meeting load, or unplanned production work — not for people to blame.
Frequently asked questions
Why commit to 90% of average?
How many sprints of history?
Source & methodology
Scrum Guide practice; velocity-based release forecasting (Cohn, Agile Estimating and Planning).
Sprint Velocity: what this tool answers
You are here because you need a specific number, and you want to see how it was produced before you rely on it. There are plenty of pages about Sprint Velocity; almost none of them show the working. This one does: the formula, every input, a fully computed example, and a sensitivity analysis calculated live from this engine’s own defaults.
A calculation like this one is worth roughly as much as a careful sentence: it forces several vague considerations into one comparable quantity. Once Sprint Velocity is on the table, the argument can stop being about impressions.
What makes Sprint Velocity worth calculating is not precision but position: it tells you which side of a threshold you are on, and by how much. A rough figure that settles the direction beats an elaborate one that never commits.
Every figure in the prose is generated by the engine rather than written beside it — the worked example resolves to average velocity = 37.7 points / sprint on the default inputs, and the sensitivity section ranks the inputs that move the result — Sprint −2 story points completed first, at ≈3.6 % of the headline for a ten-percent error either way in that input — which is the thread the rest of this guide pulls on.
The Sprint Velocity formula, explained
The engine implements a single stated model: Velocity = Σ story points completed ÷ sprints; sprints remaining = ⌈backlog ÷ average velocity⌉. There is no hidden coefficient and no login-gated precision — the formula printed is the formula executed, which is also what makes the result citable.
Sprint −3 story points completed (example value 34) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.
Sprint −2 story points completed (example value 41) is a quantity rather than a category — precision here is cheap and worth having. The example value is there to demonstrate the mechanics, not to describe your situation — overwrite it.
Sprint −1 (most recent) completed (example value 38) is a measured number in the unit named by the label; the formula does not convert for you. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
Remaining backlog (story points) (example value 400) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.
Sprint length (weeks) (example value 2) is a measured number in the unit named by the label; the formula does not convert for you. Measure twice and use the unit the label asks for — length terms often scale the result geometrically.
Sprint Velocity on the example inputs: the complete substitution
Abstract formulas are hard to trust, so here is the complete substitution using the default inputs, written the way an examiner would want it. Starting figures: Sprint −3 story points completed, Sprint −2 story points completed, Sprint −1 (most recent) completed, Remaining backlog (story points). Run to the end, the average velocity resolves to 37.7 points / sprint — within the normal band on the bands this tool uses.
- Velocity = completed points per sprint: 34, 41, 38
- Average = (34 + 41 + 38) ÷ 3 = 37.7
- Commitment guideline = 90% of average = 33.9
- Sprints for backlog = 400 ÷ 37.7 = 10.6
Recommended commitment (90%) — 33.9. Read next to the headline, this is the figure that shows the shape of the trade-off.
Velocity range — 34–41. Read next to the headline, this is the figure that shows the shape of the trade-off.
Spread (consistency) — 7.0. If your inputs change, this is usually the first companion figure to move.
Sprints to clear backlog — 10.6. Read next to the headline, this is the figure that shows the shape of the trade-off.
Weeks to clear backlog — 21.2. Read next to the headline, this is the figure that shows the shape of the trade-off.
Re-running with your own figures is instant; re-running by hand once is the best way to know the tool is telling you the truth.
How far Sprint Velocity can reasonably move
The honest version of any estimate is a corridor, and this one is cheap to produce: Sprint Velocity was recomputed at 5 points along the dominant input, with every other field left untouched.
| Sprint −2 story points completed setting | Average velocity |
|---|---|
| 80 % of the example value | 34.9 points / sprint |
| 90 % of the example value | 36.3 points / sprint |
| example inputs | 37.7 points / sprint |
| 110 % of the example value | 39.0 points / sprint |
| 120 % of the example value | 40.4 points / sprint |
That spread — 34.9 points / sprint at the low end, 40.4 points / sprint at the high — is what a careful read of Sprint Velocity looks like: a band you can state out loud, with the reason for each edge. Reproduce it in the form above by editing Sprint −2 story points completed alone; the substitution steps will follow your figures exactly.
What actually moves your Sprint Velocity
This list was computed for this specific engine just now: each numeric input was nudged ±10 % while every other field held its example value, and the average velocity was recalculated from scratch. For Sprint Velocity the ranking is measured rather than guessed, and it belongs to these defaults: shift the starting point and the order can shift with it.
- Nudge Sprint −2 story points completed by ±10 % and Sprint Velocity lands between 36.3 points / sprint and 39.0 points / sprint (sensitivity ≈3.6 %)
- Nudge Sprint −1 (most recent) completed by ±10 % and Sprint Velocity lands between 36.4 points / sprint and 38.9 points / sprint (sensitivity ≈3.4 %)
- Sprint −3 story points completed +10 % → Sprint Velocity = 38.8 points / sprint · −10 % → 36.5 points / sprint (the average velocity shifts ≈3.0 %)
Sprint −2 story points completed is the dominant lever here: ten percent either way moves the result by about 3.6 %, from 36.3 points / sprint to 39.0 points / sprint. Measure that input from a document rather than from memory, and Sprint −1 (most recent) completed is effectively tied with it (≈3.4 % for the same nudge), so verify the pair together. Everything below that can stay approximate, which is a licence to stop chasing data that would not change the decision.
Is your Sprint Velocity good — reading the result bands
A number on its own is trivia; a number against a range is intelligence. The default case lands in the “within the normal band” band, and bands are deliberately wide because real situations overlap. How much of that band is luck? On Sprint −2 story points completed alone ten percent either way covers 36.3 points / sprint to 39.0 points / sprint. The practical reading rules: read the band as a starting hypothesis, then test it: change the two dominant inputs by ten percent and see whether the verdict survives. Verdicts that survive stress are the ones worth acting on.
Where Sprint Velocity sits next to similar measures: this tool answers “how much is the Sprint Velocity”, while the related calculators answer “what do I do about it”. Reading the result alone tends to over-weight a single snapshot; pairing it with the companion tools above turns the number into a decision.
How people get Sprint Velocity wrong
Reusing a Sprint Velocity from last season. In Technology & Computing the inputs are the thing that drifts; the formula does not.
Reusing a Sprint Velocity from last season. In Technology & Computing the inputs are the thing that drifts; the formula does not.
Attention is also misallocated between fields. Having measured this engine, we can say where it belongs: Sprint −2 story points completed first, everything else second.
Another is comparing across contexts: a Sprint Velocity computed with one set of conventions should never be lined up against a figure computed with another. Check the inputs behind both before ranking them.
Before you trust your Sprint Velocity: a short checklist
- Verify each input against its original source document, not memory.
- Record the date and the inputs alongside the number so future-you knows what was assumed.
- Re-verify Sprint −2 story points completed against a source document — ten percent of error there moves the headline by ≈3.6 %.
- Compare the result with one independent method or published benchmark.
- State, in one sentence, which convention each rate, unit or period in the form is using.
- Repeat the ±10 % test on the inputs that matter and see whether the decision — not just the number — still holds.
Five steps from raw inputs to a figure you can defend
The tool does the arithmetic; the routine below is what makes the arithmetic trustworthy. Five steps, a minute total — and afterwards you will know not just what the number is, but which assumption produced it.
Step 1 — gather before you type. Sprint Velocity depends on sprint −3 story points completed, sprint −2 story points completed, sprint −1 (most recent) completed, remaining backlog (story points), sprint length (weeks). Collect them from a source document — a statement, a report, an invoice, a log — rather than from memory, because recalled inputs are the single largest cause of wrong results. Write the figure down before moving on; memory flatters whichever number you saw last.
Step 2 — baseline before exploration. Get one defensible Average velocity on screen before you start nudging numbers. Without a baseline, every variation looks interesting and none of them means anything. Note the assumption you are least sure about; that is where the real risk lives.
Step 3 — measure what deserves measuring. The ranked levers above tell you where a careful figure pays off. Everything else can stay approximate, which is a licence to stop hunting for data you do not need. One decimal place more than your data supports is one decimal place of fiction.
Step 4 — compute a corridor, not a point. Three runs — worst, likely, best — turn Sprint Velocity from a snapshot into a range. Plan against the pessimistic end and treat the optimistic end as the upside story. Numbers are cheap to produce and expensive to retract; the extra minute is the cheapest insurance available.
Step 5 — save the story with the figure. A number without its inputs and its date is unusable within a quarter. Record 37.7 points / sprint, the assumptions behind it, and today’s date; your future self will be auditing a stranger’s arithmetic. The test of a good estimate is not that it feels right but that it changes what you do.
From calculation to decision: where Sprint Velocity earns its keep
In Software Development the figure computed here is usually the first one somebody asks to see. Having it — with the formula behind it — changes your position in the conversation from participant to reference. Write the figure down before moving on; memory flatters whichever number you saw last.
Professionals in Software Development use this style of calculation as a screening filter before spending real money or effort: a quick Sprint Velocity check eliminates weak options in minutes, and the survivors earn the deeper, slower analysis. Repeating a calculation with the same numbers proves only that the arithmetic is reliable — which is worth knowing.
Treat Sprint Velocity like a smoke alarm rather than a painting — its value is in being tested periodically, not in being admired once. The test of a good estimate is not that it feels right but that it changes what you do.
Sprint Velocity — frequently asked questions
What affects Sprint Velocity the most?
The short answer: Sprint −2 story points completed. The longer answer is the sensitivity table on this page, where every numeric input was probed by ten percent and the average velocity recalculated — Sprint −2 story points completed moved it furthest, by roughly 3.6 % (36.3 points / sprint to 39.0 points / sprint).
Do sprint −1 (most recent) completed and sprint −2 story points completed matter equally?
Effectively. Measured on this engine they land at ≈3.6 % and ≈3.4 % for the same ten-percent nudge, so the honest advice is to get both right; chasing precision in only one of them buys almost nothing.
What is a typical Sprint Velocity?
On the worked example above Sprint Velocity comes out at 37.7 points / sprint. Treat that as one point on a distribution rather than a norm: the bands, the companion outputs and the sensitivity ranking tell you how wide the plausible range really is.
How do I calculate Sprint Velocity by hand?
Three steps: write the formula (Velocity = Σ story points completed ÷ sprints; sprints remaining = ⌈backlog ÷ average velocity⌉), insert your values, and simplify. The worked example section shows exactly that chain for the default inputs; replicating it once on paper teaches you more about Sprint Velocity than any number of calculator runs.
What happens to Sprint Velocity if sprint −2 story points completed changes by 10 %?
The engine was re-run with that field moved by ten percent while everything else stayed fixed: the average velocity goes across 36.3 points / sprint to 39.0 points / sprint, a swing of roughly 3.6 % around the 37.7 points / sprint baseline. That ratio is the practical definition of how much this input matters.
Is the Sprint Velocity result of 37.7 points / sprint good or bad?
Neither, on its own — the label “within the normal band” is the band this figure falls in for the example inputs, and your own inputs will place you elsewhere on the same ladder. Judge the number against your history and your alternatives, and remember that a ten-percent error in Sprint −2 story points completed alone moves it by ≈3.6 %.
How often should I check Sprint Velocity?
Whenever an input changes by more than a few percent, and otherwise on the rhythm of your decisions — before a purchase, a review, a renewal. Sprint Velocity is a snapshot, not a subscription; stale snapshots are the most common silent error in Technology & Computing planning.
Is Sprint Velocity accurate?
The arithmetic is exact: Velocity = Σ story points completed ÷ sprints; sprints remaining = ⌈backlog ÷ average velocity⌉ is evaluated with full floating-point precision and every substitution is printed in the worked example. What limits accuracy is input quality and the model’s assumptions, so treat the 37.7 points / sprint result as the correct answer to the question you typed — and check the assumptions section before acting on it.
Why commit to 90% of average?
Because the average includes lucky sprints. Committing slightly below capacity protects against sick days, carry-over and urgent fixes, and teams that consistently hit 100% of commitment usually estimate with hidden padding anyway.
How many sprints of history?
Three is the practical minimum; five to eight gives a rolling average that smooths holidays and anomalies. Re-baseline after any significant team change.
Can this tool see the numbers I type?
It cannot. There is no submission step: the calculation happens in your browser and the result disappears when you close the page. Treat the fields above as a scratchpad rather than a form.
What the labels on this page mean
- Recommended commitment (90%)
- 33.9 for the Sprint Velocity worked case; it sits next to the main result because it carries context the headline leaves out.
- Velocity range
- 34–41 in the default Sprint Velocity calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Spread (consistency)
- 7.0 in the default Sprint Velocity calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Average velocity
- The primary output of this tool: 37.7 points / sprint for the default inputs, computed exactly from Velocity = Σ story points completed ÷ sprints; sprints remaining = ⌈backlog ÷ average velocity⌉.
- Worked example
- The calculation written out in full so that nothing on this page has to be taken on trust.
- Verdict band
- The plain-language label — here “within the normal band” — mapping the computed figure onto experience-based ranges for Technology & Computing.
- Sensitivity (±10 %)
- How far the Sprint Velocity moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
The provenance of this Sprint Velocity calculation
There is no black box on this page — the engine evaluates Velocity = Σ story points completed ÷ sprints; sprints remaining = ⌈backlog ÷ average velocity⌉. Source of record: Scrum Guide practice; velocity-based release forecasting (Cohn, Agile Estimating and Planning). Any other implementation of this model should return the same figure for the same inputs. If one does not, the difference is in its assumptions — which this page prints and that one probably does not.
Treat the output as a precise answer to the question you typed: exact arithmetic, transparent formula, published source, no hidden rounding. The design constraint was set by usefulness rather than by comfort: an estimate you can interrogate beats an answer you have to trust.
Turning this Sprint Velocity into a decision
Save the number together with its inputs and today’s date; a Sprint Velocity figure without context is unusable the moment an input changes.
Whoever you are (people who need one trustworthy number before their next decision), the next step is the same: replace the example inputs with your own, note the date, and re-run whenever a figure moves. In Technology & Computing, a dated figure is a trend, and an undated one is a rumour.