How to Calculate Sprint Velocity: Formula, Steps, and Best Practices

You are in Sprint Planning and the Product Owner asks the same question every cycle: “How much can we actually get done this sprint?” The wrong answer — “as much as we can” — leads to overcommitment, spillover, and a board full of half-finished stories. The right answer starts with a number that most teams already have but rarely use: their sprint velocity.

This guide shows you exactly how to calculate sprint velocity, what unit to measure it in, how many sprints you need before the number is trustworthy, and how to turn it into realistic sprint forecasts. No theory-only fluff: you will get the formula, worked examples with real numbers, and the mistakes that quietly corrupt velocity data.

Quick Answer: How Do You Calculate Sprint Velocity?

To calculate sprint velocity, add up the estimates (usually story points) of every backlog item that was fully completed and met the Definition of Done during the sprint. Divide or average that total over the last three to five sprints to get your planning velocity. Example: if a team completes 8, 11, 9, and 12 points over four two-week sprints, the average velocity is 10 points per sprint.

The nuance: only “done” work counts. A story that is 90% complete at the end of the sprint contributes zero points to velocity, because velocity exists to forecast finished value, not activity.

What Is Sprint Velocity, and Why Does It Matter?

Sprint velocity is the amount of work a Scrum team completes in one sprint, measured in the unit the team estimates with — most commonly story points. It is not part of the official Scrum Guide, which deliberately leaves it out: Scrum prescribes the events and artifacts, while techniques like velocity are practices teams add on top. In practice, velocity is the most widely used tool for the Sprint Planning topic the Scrum Guide calls “What can be Done this Sprint?” — selecting a realistic amount of work based on past performance, upcoming capacity, and the Definition of Done.

Velocity matters for three reasons:

1. It turns Sprint Planning from a guess into a forecast. Instead of asking “can we do 20 points?”, you ask “our average is 10, our capacity is slightly lower next week, so we plan around 9.”
2. It exposes estimate drift. If velocity rises 20% with no change in team size or scope, someone is inflating estimates — and you can catch it.
3. It supports release forecasting. With an average velocity of 10 points per sprint and 130 points of work left, you can project roughly 13 sprints, then adjust as reality appears.

The catch is that velocity is only as honest as your Definition of Done and your estimates. A team that counts “nearly finished” work, changes its point scale, or shuffles team members every sprint will produce a velocity that means nothing.

What Unit Should You Measure Velocity In?

Velocity has no built-in unit. You choose one, and the choice changes what the number tells you:

Story points are the default for a reason: they are relative, so the scale stays meaningful as the team grows and learns. But points only work if everyone understands the scale. If your team describes a 3 as “about half a day” and another team describes a 3 as “a full day”, neither number means the same thing — which is why you should never compare velocity between teams even when both use points.

How to Calculate Sprint Velocity: Step by Step

Step 1: Define what “done” means

Velocity counts only work that meets the Definition of Done — the shared checklist that turns a backlog item into a releasable Increment. Without a DoD, teams count half-finished work and velocity inflates instantly. Write the DoD down, agree on it as a team, and use it at the Sprint Review.

Step 2: Estimate every backlog item in one consistent unit

Every item pulled into a sprint needs an estimate: 2, 3, 5, 8, 13 points (Fibonacci is common). If items have no estimate, velocity is impossible to compute. Estimation happens during backlog refinement, not during the sprint.

Step 3: Complete the sprint and collect the numbers

At the end of the sprint, take the Sprint Backlog and total the estimates of only the items that met the Definition of Done. That total is your sprint velocity. Items that were 99% complete count as zero. New scope added mid-sprint and finished counts toward the total; new scope added mid-sprint and unfinished counts as zero and should not be carried as “partial credit.”

Step 4: Worked example

A six-person team finishes Sprint 1 with these completed stories: a login flow (5 points), an email template (3), a bug fix (2), and a settings page (8). Total: 18 points. Sprint velocity for Sprint 1 = 18 points. If a payment integration story (13 points) was started but not finished, it adds nothing.

One sprint is not a planning number. The team runs three more sprints and delivers 18, 14, 20, and 16 points. Average velocity = (18 + 14 + 20 + 16) / 4 = 17 points per sprint. Now the team plans around 17 points, adjusted for capacity changes.

Step 5: Recalculate and review every sprint

Velocity is a rolling number, not a stored truth. Recompute after each sprint, keep the last three to five values, and discuss the trend in the Retrospective. A rising trend with stable scope means the team is improving or estimates are drifting; a falling trend means capacity loss, morale problems, or estimation inflation in reverse.

How Many Sprints Do You Need Before Velocity Is Reliable?

Use at least three sprints, and prefer five. A single sprint is a sample size of one: a holiday week, a nasty integration, or a sick teammate can move it by 30–40%. Five sprints smooth out the noise while still reflecting the team’s current reality. There is a trade-off — averaging ten sprints is stabler but ignores that the team changed — so keep the window short enough to stay relevant and long enough to be meaningful. If the team changes (a senior leaves, a junior joins), treat the velocity history as suspect and reset the baseline after two or three sprints with the new lineup.

How to Use Sprint Velocity for Capacity Planning and Forecasting

Velocity alone is a forecast of output. Capacity is the team’s available person-hours, and combining the two gives you a much sharper planning number.

Scenario 1: Planning the next sprint with capacity

A five-person team has an average velocity of 25 points. Next sprint, one developer is on leave for a week, so capacity drops from 10 person-days per person to 45 total person-days (5 people × 9 days) versus a normal 50. Planning 25 points blindly would repeat the overcommit pattern that caused the last two spills. Instead, scale velocity by the capacity ratio: 25 × (45 / 50) = 22.5, so the team plans about 22 points and protects the remaining buffer for unplanned fixes. This is the practical way capacity and velocity work together.

Scenario 2: Forecasting a release date

The product backlog has 210 points of work left for the MVP. Average velocity is 30 points per two-week sprint. Simple forecast: 210 / 30 = 7 sprints, or 14 weeks. Reality check: velocity is rarely linear, so the team forecasts 7–9 sprints (14–18 weeks), re-forecasts after each sprint, and uses the burndown to track whether reality matches the projection. The number answers the stakeholder question “when is this live?” with a range instead of a guess.

Scenario 3: Catching estimate inflation

A stable four-person team with unchanged scope sees velocity climb from 20 to 24 to 29 over three sprints — a 45% jump with no new people and no overtime. That is almost never real speed; it is point inflation, where stories quietly get estimated a little bigger each refinement. The Retrospective agenda: re-validate the point scale against two or three reference stories (“is a 3 still a 3?”), and check whether the team is inflating to look productive or to defend against a punishing workload.

What Is a “Good” Sprint Velocity?

There is no universal good number, because velocity is relative — a raw number carries little objective value; the trend is what matters. A 10-point sprint is good for a team whose average is 8; the same 10 is a step backward for a team averaging 12. Judge velocity only against the team’s own history, in its own unit, with its own Definition of Done. What you can monitor usefully: consistency (is the spread small?), trend (is it drifting up or down?), and predictability (did the team hit its forecast?). A predictable team at 12 points is more valuable than a chaotic team at 18.

Common Mistakes When Calculating Sprint Velocity

• Counting unfinished work. A story that is 90% done adds 0 to velocity. Partial credit destroys the forecast’s meaning.
• Using one sprint to plan. One sprint is noise. Use the last three to five.
• Changing the point scale mid-stream. If a 3 stops meaning a 3, your history becomes meaningless. Lock the scale and reference stories.
• Comparing teams or evaluating people. Velocity is a team forecasting number. Tying it to performance reviews incentivizes inflation and hiding estimates.
• Ignoring the Definition of Done. Without DoD, “done” means different things to different people, and velocity measures whatever each person decided to count.
• Not adjusting for capacity. Planning full velocity while someone is on leave guarantees spillover.
• Hiding scope changes. If mid-sprint scope keeps inflating velocity, log and review it instead of celebrating the number.
• Forgetting velocity is a forecast, not a target. As one practitioner warns, when a measure becomes a target, it stops being a good measure — teams game it.

Know This Before You Choose

Before you pick the tool and the unit for measuring sprint velocity, answer these questions:

• Does every backlog item get an estimate in a single, agreed unit before it enters a sprint?
• Is the team’s Definition of Done written down and enforced at the Sprint Review?
• Have you collected at least three sprints of data before trusting the number?
• Is the point scale stable, with reference stories the team can re-check?
• Will you use velocity only for forecasting, not for performance review?
• Do you have a way to adjust for capacity changes (leave, new members) when planning?
• Does your tooling calculate velocity automatically, or will someone maintain a spreadsheet?
• Who owns the conversation when velocity drops — the Scrum Master, or the whole team?

Which Tools Calculate Sprint Velocity Automatically?

A few real options, each with honest trade-offs:

• Jira (Atlassian) — the standard for Scrum teams. Velocity charts and reports come built in, and burndown charts pair naturally with them. Pros: automatic velocity calculation from completed story points, deep Agile reporting, industry default. Cons: heavyweight configuration, and teams must actually use estimates and DoD statuses for the report to mean anything. Best for software and product teams already on Jira.
• Azure DevOps — strong velocity, sprint burndown, and capacity reports for Microsoft-centric organizations. Pros: first-class capacity planning tied to velocity, clean sprint analytics. Cons: the Agile vocabulary and UI take time to learn; estimation features are less polished than Jira’s. Best for .NET/enterprise teams on the Microsoft stack.
• ClickUp — velocity and burndown views inside a broader work-management tool. Pros: flexible, good for hybrid teams mixing Scrum with other work. Cons: velocity reporting is less prominent and can feel buried under the platform’s many views. Best for teams that want Scrum metrics without leaving a generalist tool.
• Linear — a fast, modern option for product teams. Pros: effortless issue tracking, clean sprints (cycles) with automatic cycle metrics. Cons: metrics are lighter weight, and it is aimed at software products, not general project work. Best for startup product/engineering teams.
• Spreadsheets (Excel / Google Sheets) — a manual velocity tracker. Pros: free, fully custom, no estimation tool lock-in. Cons: manual updates decay quickly, no automatic DoD enforcement, and the number is only as fresh as the last update. Best for small teams or as a stopgap before a dedicated tool.

The pattern holds across all of them: the tool does the arithmetic, but you supply the discipline — consistent estimates, a real Definition of Done, and honest status updates. A tool with perfect velocity charts is worthless if “done” means whatever each developer decides it means.

When a Tool Helps Keep Velocity Honest

If you have watched sprint data rot in a spreadsheet because nobody updated it, a tool that stores estimates, checklists, and completion status together makes the numbers nearly free. The same logic applies at the level of the whole planning stack — a project management platform where planning, execution, and reporting share one workspace keeps every sprint metric honest. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. In Doitify, tasks carry owners, due dates, checklists, and quality control, and you can run sprints and backlogs, track progress on boards and Gantt-style schedules, and pull work and performance reports from live data — so your velocity conversation in Sprint Planning is based on what the team actually completed, not on memory. If your planning meetings keep relying on “it felt like a big sprint,” that connected planning-to-execution picture is the use case it was designed for; if your current setup produces forecasts you trust, keep it.

Conclusion

Sprint velocity is a simple calculation with a fragile reputation: sum the estimates of completed, Definition-of-Done work, average it over the last three to five sprints, and use the result to plan the next sprint with a capacity adjustment. Keep it a forecasting number, never a scoreboard. Pair it with a written Definition of Done, a stable point scale, and a tool that keeps the data current, and Sprint Planning stops being a guess — you will commit to what the team can finish, forecast releases with honest ranges, and catch estimate drift before it becomes a habit.