What Is Sprint Velocity?

Mention velocity in any Scrum team and you will see two reactions: the team that measures it religiously and plans every sprint from it, and the team that quietly suspects it is being used to judge them. Both are partly right, and both are missing the point. Sprint velocity is a forecasting number — the amount of work a team actually completes in a sprint — and it is one of the most useful and most misused metrics in agile. Used correctly, it turns sprint planning from a guess into a calculation and lets you answer “when will this be done?” with a defensible estimate. Used incorrectly, it becomes a cross-team leaderboard that motivates people to inflate estimates and hide problems. This guide defines sprint velocity precisely, shows how to calculate and use it, exposes the common mistakes, and gives you the tools to track it without turning it into a weapon.

Quick Answer: What Is Sprint Velocity?

Sprint velocity is the total amount of work a Scrum team completes in a sprint, measured in story points (or another consistent unit of estimated effort), counting only Product Backlog items that meet the Definition of Done. Teams use it to forecast how much they can commit to in future sprints and to estimate when larger pieces of work will be delivered.

The nuance that matters: velocity is a historical fact about the team, not a target or a performance rating. It is calculated after the sprint from what was actually done, and it becomes useful when you look at the trend — typically the average of the last three to six sprints — rather than a single sprint’s number.

Why Velocity Is Not in the Scrum Guide

This surprises a lot of people: velocity does not appear in the 2020 Scrum Guide at all. The Guide does not define it, require it, or forbid it. What the Guide says is that various practices exist to forecast progress — like burn-downs, burn-ups, or cumulative flows — and that while they are proven useful, they do not replace empiricism. “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.”

That last line is the philosophical foundation of velocity. Velocity is empiricism in action: you look at what the team actually completed in past sprints and use that history to forecast future sprints. It is a forecasting technique that fits inside the Scrum framework, not a part of the framework itself. Teams that treat velocity as a Scrum requirement, or as a measure of how “fast” a team is, are using a forecasting tool as a scoreboard.

How Do You Calculate Sprint Velocity?

The formula is simple:

Sprint velocity = the sum of the story points (or estimated effort) of every Product Backlog item fully completed in the sprint.

Three rules make the calculation correct:

1. Only count items that meet the Definition of Done. If an item is 90% done, it counts as zero. This is the single most important rule — partial credit destroys the meaning of the number.
2. Count the items as sized when they were selected, not re-estimated at the end. If a story was estimated at 5 points and delivered, it contributes 5 points, even if it took longer than expected. Re-estimating after the fact makes the trend untrustworthy.
3. Use the same unit consistently. If the team sizes with story points, use story points; if it sizes in hours or days, use that — but never mix units between sprints.

A worked example

A team of five completes the following items in a two-week sprint:

The finished items total 8 + 3 + 2 + 2 = 15 points. The unfinished 5-point item does not count. The team’s velocity for this sprint is 15 points, and it carries the unfinished item into the next sprint.

Story Points vs Hours: What Should Velocity Measure?

Velocity is usually measured in story points, but it can be measured in any consistent unit of effort — hours, ideal days, or T-shirt sizes converted to a scale. The choice matters less than consistency, but the trade-offs are real.

Story points measure relative size: complexity, uncertainty, and effort combined, compared against a reference item. They are deliberately not tied to hours, so they do not collapse into “how long did it take,” which keeps estimates honest and comparable across team members with different speeds. The cost: points mean nothing to stakeholders outside the team, and a team’s scale is only meaningful to that team.

Hours feel intuitive and answer “when?” directly, but they collapse into actual time and create pressure: if a 5-point story is actually 8 hours and the estimate said 4, the number starts leaking judgment. Most experienced Scrum teams prefer story points precisely because they resist that collapse. Whichever unit you pick, the rule is the same: stable scale, consistent unit, count only done work.

How Many Sprints Do You Need for a Reliable Velocity?

Do not trust velocity from one or two sprints. The first few sprints are noisy: the team is learning the product, the process, and each other, and estimates are rough. Practitioners generally look for three to six sprints of data before using velocity for real commitments. A team that averages 12, 18, 20, and 14 points across four sprints has an average of 16 points — far more reliable for planning than the single 20-point sprint that looked impressive.

The stability test is the trend, not the average. If velocity is climbing steadily, the team is still improving (or inflating estimates — investigate before celebrating). If it is swinging wildly, look for root causes: capacity changes, estimation drift, or Definition of Done erosion. Only a stable trend deserves to drive commitments.

How Do You Use Velocity in Sprint Planning and Forecasting?

Velocity has two main jobs.

Sprint planning. Once you have a stable average, the team knows roughly how much it can pull. A team averaging 16 points plans a sprint around 16 points (adjusting for known capacity changes like holidays). Without velocity, the team guesses and either over-commits (missed Sprint Goals) or under-commits (wasted capacity).

Forecasting. Velocity lets you estimate “when will this be done?” For a release of 80 points of refined backlog, a team averaging 16 points per sprint needs about five sprints. For an epic of 40 points, about two and a half. This turns the most stressful question stakeholders ask — “when?” — into a transparent calculation that the team can defend, and it makes scope-cut conversations concrete: reducing the release by 16 points removes a sprint.

The discipline is to treat velocity as a range, not a promise. Use the average, acknowledge the spread (say, 14–18 for the team above), and re-forecast as new data arrives. A single sprint’s miss is information, not failure.

How Do You Adjust Velocity for Capacity Changes?

Velocity is measured, not set — and it quietly assumes a roughly constant team. When capacity changes, adjust the forecast explicitly:

• Holidays and leaves. A two-week sprint with a team of five losing one member for a week has about 10% less capacity; plan around 90% of typical velocity.
• Headcount changes. Adding or losing a developer shifts velocity over time — usually with a lag, because new members take sprints to ramp up. Do not expect an instant +20%.
• Part-time members and cross-team duties. Count them as partial capacity and reflect that in the forecast.
• Sprint length changes. Velocity is per sprint, not per week. If you move from two-week to three-week sprints, the number will rise — that is not improvement, it is a longer box. Normalize per week if you want to compare.

The practical move: when capacity changes, adjust the forecast, not the historical velocity. History stays what it was; the forward estimate reflects the new reality.

Velocity vs Burndown vs Burnup: What’s the Difference?

Velocity, burndown, and burnup answer different questions, and teams confuse them constantly.

• Velocity is the rate: how much work the team completes per sprint. It is a number per sprint, best seen as a bar chart over time.
• Burndown chart shows work remaining in the current sprint (or release) day by day, against the plan. It tells you mid-sprint whether you are on track — not how much you can do next sprint.
• Burnup chart shows work completed toward a fixed target, showing scope additions and progress in one view. It is honest about scope creep in a way burndown is not.
• Cumulative flow diagram (more kanban-flavored) shows work-in-progress across columns, exposing bottlenecks.

The rule: use velocity for planning next sprints and forecasting releases; use burndown during the sprint to steer; use burnup when scope is volatile. They are complements, not substitutes.

Real Scenarios With Numbers

Scenario 1: Forecasting a release

A team of six has averaged 30, 28, 32, and 26 story points over four sprints — an average of 29, roughly 27–31 in range. The Product Owner wants to ship a release built from 145 points of refined backlog. Forecast: 145 / 29 ≈ 5 sprints (about 10 weeks at two-week sprints). The team presents this as a range — “around 5 sprints, realistically 5–6” — and the stakeholder asks what dropping 30 points of scope would do: that removes about one sprint. The conversation shifts from hope to arithmetic.

Scenario 2: Capacity adjustment for a holiday sprint

A five-person team averages 20 points per sprint, but the sprint before a holiday falls on a week where two members are out for two days each and one member for a full week. That is roughly 3 of 10 available person-weeks gone. The team plans for about 70% of normal velocity, pulling ~14 points instead of 20. The sprint completes at 13 points, comfortably within the adjusted forecast. The alternative — planning the full 20 and missing — would have produced a failed Sprint Goal and a demoralized team.

Scenario 3: Detecting (and correcting) inflated velocity

A manager starts using velocity as a performance target. Within four sprints, the team’s velocity climbs from 22 to 34 — but delivered value does not change, and stakeholders start complaining that estimates feel padded. Investigation shows the team quietly re-estimating stories upward to hit the “target.” The fix is cultural, not numerical: velocity is removed as a target, the team re-calibrates its scale against a reference story, and velocity settles back to a stable ~24 where it stays. The lesson: velocity is a forecast input, and the moment it becomes a score, it stops being a fact.

Scenario 4: A new team building its baseline

A freshly formed team of four has no historical velocity. They run three two-week sprints with results of 10, 14, and 12 points. They refuse to make big commitments in sprint four, planning for ~12 points based on the three-sprint average of 12. By sprint six, the trend has stabilized between 12 and 14, and stakeholders finally get a reliable “when will it be done” answer for the roadmap. Had they committed to 20 points in sprint two on the strength of one optimistic estimate, the Sprint Goals would have failed and the baseline would be untrustworthy.

What Tools Track Sprint Velocity?

Jira (Atlassian)

The most common home for velocity: the velocity chart and burndown come built-in for Scrum projects, computed automatically from story points and sprint completions. Pros: zero setup for teams already in Jira, automatic and consistent. Cons: the number is only as honest as the team’s completion discipline and estimation scale. Trade-off: automation versus the risk of trusting a number you did not verify.

Azure DevOps Boards

Includes sprint metrics and burndown charts with solid scrum tooling. Pros: integrates with the Microsoft dev stack. Cons: engineering-oriented; non-developer teams find it heavy. Trade-off: depth versus accessibility.

ClickUp

Offers sprint views, story points, and burndown/velocity-style reports within a broader work platform. Pros: flexible, one workspace for agile and general work. Cons: less opinionated than Jira; you configure what counts as done. Trade-off: flexibility versus discipline.

Linear

A fast, modern issue tracker popular with product teams, with velocity-style reporting and clean sprint boards. Pros: fast, beautiful, developer-loved. Cons: narrower ecosystem and fewer enterprise features. Trade-off: speed versus scale.

Spreadsheets (Google Sheets, Excel)

A simple velocity log (sprint, points completed, notes) is fully transparent and zero-cost. Pros: full control and auditability. Cons: manual data entry and no integration with execution. Trade-off: control versus effort.

Doitify

Doitify is an all-in-one platform for project management, team management, and goal achievement. It supports sprints and backlogs, story-point-style estimation within tasks, task owners and due dates, and work and performance reports — which means a Scrum Master or Product Owner can track sprint completions, see the trend across sprints, and connect that forecast to the roadmap and goal tracking in one workspace. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. The trade-off: as a broader platform it is not a single-purpose agile analytics tool, so teams wanting Jira’s deep agile reporting may prefer a specialist — but teams that want sprints, velocity-informed planning, goals, and reports unified find that home here.

Common Mistakes

• Using velocity as a performance or productivity metric. Velocity is a forecasting input. Using it to judge people or teams motivates estimation inflation and hides problems.
• Comparing velocity across teams. Every team’s point scale is its own. A 30-point team and a 15-point team may be delivering equally; the numbers are not comparable.
• Counting partially done work. A 90% item counts as zero. Partial credit destroys the trend’s meaning and invites gaming.
• Changing the estimation scale mid-stream. Re-basing points, or switching from points to hours, breaks every historical comparison.
• Trusting one sprint’s number. A single sprint is noise. Use three to six sprints of history and look at the trend.
• Ignoring capacity changes. Planning a holiday sprint at full velocity guarantees a miss. Adjust the forecast, not the history.
• Re-estimating delivered items at the end. Score what was planned at selection; re-estimating after delivery makes the trend untrustworthy.
• Using velocity to promise single-sprint dates. Forecast with a range and re-forecast as data arrives; a single number promises precision that the data does not have.

Know This Before You Choose

• Decide what velocity is for in your team. If the answer is “to judge performance,” stop — it will corrupt the number. If it is “to plan and forecast,” you are on the right track.
• Pick one estimation unit and protect it. Story points are the most robust for most teams; whichever you choose, keep the scale stable and documented.
• Establish a real Definition of Done before trusting the number. Velocity only means something if “done” means done.
• Plan for the ramp-up. Give a new team three to six sprints before using velocity for big commitments.
• Normalize for capacity and sprint length explicitly. Adjust the forward forecast for holidays, headcount, and sprint duration.
• Track the trend, not the number. A velocity chart over time tells you far more than this sprint’s point total.

Conclusion

Sprint velocity is a forecasting number, nothing more and nothing less: the amount of work a team genuinely completes in a sprint, measured consistently, and used to plan the next sprint and forecast the release. Get the basics right — count only done work, keep the estimation scale stable, use three to six sprints of history, and adjust for capacity — and it becomes one of the most reliable tools in your agile kit. Abuse it as a performance scoreboard or a cross-team leaderboard, and it will quietly turn your team into expert estimators of work they do not ship. The discipline is cultural: velocity tells you what your team has actually done; it is up to you to use that fact to plan honestly instead of to judge. When you want sprints, backlogs, velocity-informed planning, goals, and reports in one workspace, Doitify’s project management platform keeps the whole loop — plan, execute, measure — in a single place.