Sprint Velocity Calculator

Calculates sprint velocity by summing story points completed across recent sprints and computing the moving average. Standard practice uses the last three to five sprints to smooth out variation. Output also includes range (min/max) and standard deviation for capacity planning.

Velocity is a planning tool, not a performance metric. Comparing velocity across teams is fundamentally invalid because story-point estimates are team-relative.

Story points originated as a relative-sizing technique to escape the false precision of hour estimates. A team agrees that this small task is "1 point" and uses it as the reference; subsequent stories are sized as multiples or fractions. The Fibonacci scale (1, 2, 3, 5, 8, 13, 21) is conventional because it forces meaningful size differentiation — a 5-point story is "noticeably larger than a 3-point but smaller than an 8-point" rather than a precise multiplier. Over time, the team's velocity (points per sprint) becomes empirical: not a target but an observation.

The moving-average computation smooths out single-sprint noise. A three-sprint moving average dampens the swings caused by one-off events (vacations, production incidents, dependency blocks). Five-sprint averages further smooth but begin to lag real capacity changes (new team member adds capacity over weeks, not months). Standard deviation indicates predictability — a team averaging 30 points with σ=3 is more predictable than one averaging 30 with σ=12, which matters for forecasting commitments.

A worked example for a six-sprint history of points completed: 28, 32, 27, 35, 30, 31. Three-sprint moving average over the last three: (35+30+31)/3 = 32. Five-sprint: (32+27+35+30+31)/5 = 31. Standard deviation across the six sprints: σ ≈ 2.7. Forecasting next sprint: commit to 31, with high confidence in delivery between 28–34. Upper-bound commitment of 35 risks missing; lower-bound commitment of 27 leaves capacity unused.

The cross-team comparison failure mode is worth understanding deeply. Team A on a greenfield project develops a calibration where typical features are 8 points. Team B on a legacy maintenance codebase develops a calibration where typical features are 13 points (because they're harder). Team A's velocity of 40 and Team B's velocity of 65 do not mean Team A is less productive; they mean the teams calibrated points differently. Management pressure to "increase velocity" leads to point inflation, which corrupts both estimation accuracy and forecasting reliability. The metric works only when treated as a calibration internal to the team.

Limitations: velocity as a planning tool assumes the team composition, codebase, and work type are stable. Major changes — new team members, a pivot from greenfield to maintenance, infrastructure migration — invalidate historical velocity until a new baseline emerges over three sprints. Velocity also does not capture quality; a sprint that completes 35 points by accumulating tech debt looks the same as one that completes 35 points cleanly. Pairing velocity with quality metrics (defect rate, deploy frequency, MTTR) produces a healthier picture.