Sprint Velocity & Burndown Calculator
Compute rolling average velocity from past sprints. Project release date from remaining backlog. Best/worst/likely range. Free, no signup.
Sprint Velocity & Burndown Calculator
Enter recent sprint velocities (story points completed). The tool computes rolling average + standard deviation, and projects remaining-backlog completion in best / likely / worst sprint counts and weeks. Default sprint length: 2 weeks.
| Sprint | Velocity (points) |
|---|
How to Use the Velocity Calculator
Enter your last 3-6 sprint velocities
From Jira's Velocity Chart, Linear's velocity widget, or your team's spreadsheet. Use story points completed (Done column), not points committed. Most teams stabilise after 3-5 sprints.
Enter the remaining backlog
Sum of story points for all backlog items planned for this release. Include only refined / sized items — anything unestimated should be estimated first or excluded from the forecast.
Confirm sprint length
Most teams use 2-week sprints; some use 1 or 3. The tool multiplies sprint count by length to get a weeks-to-finish + calendar date.
Quote the worst-case to stakeholders
The "likely" finish date is a 50/50 bet. The "worst case" uses your team's bad-sprint velocity. Quote that to stakeholders if you have to commit to a date; quote "likely" to peers.
Velocity — The Most Misused Agile Metric
What Velocity Is and Isn't
Velocity is the average number of story points a team completes per sprint, measured over the last 3-5 sprints. It's a forecasting tool — given a stable team and a stable definition of done, velocity predicts how much work the team can absorb in a future sprint. It's not a productivity metric, not a cross-team comparison tool, and not a performance-review input. Teams that drift into using velocity for those purposes invariably watch it inflate over six months until it loses all forecasting power — Goodhart's Law in action.
The Scrum Guide doesn't actually require velocity tracking; it just notes that "the Scrum Team's use of empirical process control depends on inspection and adaptation." Mike Cohn's "Agile Estimating and Planning" (2005) is the canonical reference for velocity-based release planning. Velocity assumes stable team membership, stable definition of done, stable sprint length, and stable estimation calibration. Change any of those and you have to rebuild a velocity baseline — typically 3-5 sprints to re-stabilise.
Why Best / Worst / Likely Beats a Single Number
A team averaging 25 points per sprint with ± 5 SD is fundamentally different from a team averaging 25 with ± 2 SD, but the average alone treats them identically. The first team needs a wider buffer on release commitments; the second can commit closer to expected. Showing best (avg + 1 SD), likely (avg), and worst (avg - 1 SD) makes this explicit. For a backlog of 180 points and avg = 25 ± 5, the range is 180 ÷ 30 = 6 sprints best, 180 ÷ 25 = 7.2 sprints likely, 180 ÷ 20 = 9 sprints worst — a 3-sprint spread that should drive how you commit dates to stakeholders.
Critical caveat: velocity-based forecasts assume the backlog is fully refined and the velocity-generating sprints used a similar work mix. If your historical sprints were 80% feature work and the remaining backlog is 80% migration / infra work, your velocity won't transfer. Re-baseline by running a few sprints of the new work mix before forecasting.
"Velocity is a forecasting metric, not a performance metric. The moment leadership starts measuring teams by velocity, teams start inflating points. Within 6 months the forecast is worthless and the team is exhausted."
Burndown and Burnup — Two Views of the Same Thing
A burndown chart shows remaining work over time (down-and-to-the-right is good). A burnup chart shows completed + scope on two lines (gap between lines = remaining work). Burnups are better for projects with scope changes mid-release because they make the scope change visually obvious; burndowns are simpler for fixed-scope sprints. Most modern Agile tools (Jira, Linear, Asana, ClickUp) generate both automatically — the choice is mostly stylistic. The tool here outputs the forecast inputs you'd then plot in either format.
What To Do When Velocity Is Trending Down
A declining velocity trend usually means one of four things: technical debt is accumulating (each story takes longer than its point value implies), team composition changed (new joiners ramping up), scope of stories drifted larger (without re-pointing), or non-sprint work is bleeding in (production incidents, ad-hoc requests). Diagnose first, then act: if it's tech debt, dedicate 20% of capacity per sprint to paydown; if it's ramping, recompute velocity from sprints since the team change; if it's scope drift, re-baseline points; if it's interruptions, formalise a separate support track with its own capacity allocation. Don't treat declining velocity as a discipline problem — it's almost always a structural signal.
10 Facts About Velocity and Burndowns
Velocity = mean story points completed per sprint over the last 3-5 sprints.
The Scrum Guide (2020) does not mandate velocity tracking — it's an industry convention popularised by Mike Cohn.
Teams stabilise velocity after 3-5 sprints of consistent membership + practice.
Velocity is not transferable between teams — each team's points reflect its own calibration.
Goodhart's Law: when velocity becomes a target, it stops being a useful measure. Teams inflate points.
Story points are unitless by design — typically Fibonacci (1, 2, 3, 5, 8, 13).
Burndown shows remaining work; burnup shows completed + scope — better for scope-changing projects.
Atlassian's State of Agile 2024 report: 87% of Scrum teams track velocity; 64% use it for release planning.
2-week sprints are the modal Agile sprint length (~60% of teams per Atlassian); 1-week and 3-week are common alternatives.
#NoEstimates movement (Vasco Duarte) argues velocity tracking and story-point estimation produce more friction than value.
Frequently Asked Questions
- Velocity is the mean of story points completed (moved to Done) across the last 3-5 sprints. Don't include partial credit for unfinished work — completed only. Don't include points carried over from previous sprints unless you're using cumulative-flow accounting. Most modern Agile tools (Jira, Linear) compute this automatically from your sprint history.
- 3-5 sprints is the sweet spot. Fewer than 3 doesn't smooth out one-off events (vacations, illness, big incidents). More than 5 dilutes recent changes (new team members, new tools, new ceremonies). If your team is new, start with 3 sprints; after 10+ sprints with stable membership, you can extend to 5-6.
- Because bad sprints multiply across long forecasts. If your worst sprint was 18 points vs an average of 25, dividing a 180-point backlog by 18 gives 10 sprints — vs 7.2 at the average. Three extra sprints. This is why stakeholders need to see the range, not just the average. The "average finish date" is a 50/50 bet.
- No. Story points are calibrated per-team — each team's "5" is its own reference. Team A's velocity of 30 and Team B's velocity of 60 don't mean B is twice as productive; B might just point everything double. Cross-team comparisons via velocity are the #1 anti-pattern that destroys velocity as a useful metric. If leadership demands it, use a different metric (cycle time, throughput in PRs / week, customer outcomes).
- High variability (SD > 30% of mean) usually indicates one of: inconsistent definition of done, sprints with very different work mixes, frequent team-membership changes, or unmanaged interruptions (production incidents, ad-hoc requests). Diagnose the cause before forecasting. Quick wins: enforce DoD consistently, protect sprint scope from mid-sprint additions, dedicate a 20% capacity buffer for interrupts.
- No — plan to 70-85% of average velocity. The remaining 15-30% is buffer for support, code review, bug fixes, infra work, and unplanned production issues. Teams that consistently commit to 100% of velocity ship a smaller percentage of committed work than teams that commit to 80%, because over-commit creates context-switching that drags everything.
- Not directly — this tool computes the forecast inputs (velocity + projected sprint count + finish date). For actual burndown / burnup charts use Jira, Linear, or Asana, which auto-generate them from your sprint data. The math here is the same math those charts use; this tool just exposes the projection without committing you to a specific Agile-tool dashboard.
- For 3-6 sprint forecasts on stable teams, velocity-based estimates land within ± 20% of actuals most of the time. Accuracy degrades sharply at 10+ sprint horizons because backlog scope changes, team composition changes, and tech-debt accumulates. Use velocity for quarterly commits; for annual commits, use rougher estimation (Fermi-style, "we ship one major area per year" benchmarks) plus continuous re-forecasting.
- The #NoEstimates movement (popularised by Vasco Duarte and Woody Zuill) argues that velocity / point estimation creates more friction than value, and recommends tracking throughput (count of stories completed per week) instead. This works for teams shipping similarly-sized stories. For teams with high story-size variance, points still beat raw counts. Either way, the projection math is the same: divide backlog by recent average, with a range based on variability.
- US clients are typically more tolerant of velocity-based "we'll ship every two weeks" framing than European or Japanese clients, who often want explicit dates with confidence bands. Singapore + Hong Kong financial-sector clients usually want a quarterly Gantt-style commit on top of sprint velocity. The forecast math is identical; the deliverable is different — for date-driven clients, take the worst-case velocity output and present that as the commitment, with the better case as upside.
Related News
You may be interested in these recent stories from our newsroom.
-
Snowflake jumps 36 per cent in a day on an earnings beat and a US$6 billion AWS chip deal
Snowflake had its best day as a public company on 28 May, closing up 36 per cent after a clean first-quarter beat and a five-year, US$6 bill...
-
MAS Scraps Mandatory Financial Advice for Most Complex Product Buyers in Retail Shake-Up
Singapore retail investors buying structured notes, derivatives and investment-linked policies will no longer need mandatory financial advic...
-
SEC Rewrites Float Rules, PSE Moves to Implement Them — Clearing the Path for GCash's USD 1B Philippine IPO
The SEC lowered the public float floor for large Philippine issuers in February 2026. The PSE followed with a consultation paper in April. T...
75 more free tools
Calculators, converters, security tools — no signup.