If you have ever Googled "velocity calculator" hoping to find a magic number that tells you whether your Scrum team is performing well, you are already using velocity wrong. And you are not alone — velocity is the most widely used and most widely misused metric in agile software development.
Velocity was never designed to measure team performance, compare developers, or justify headcount decisions. It was designed to do one thing: help a team plan how much work it can realistically take on in the next sprint. The moment you turn it into a performance scorecard, you break the very thing it was built to protect — honest estimation and sustainable delivery.
This guide will show you how to calculate velocity correctly, why most teams misuse it, and how to use it as the planning tool it was always meant to be — including what changes when AI enters your agile workflow.
What is velocity in agile?
Velocity is an agile metric that measures the amount of work a Scrum team completes during a single sprint, expressed in story points. It is calculated by summing the story points of all user stories that meet the team's Definition of Done at the end of a sprint. Partially completed work does not count. Velocity is used exclusively as a planning and forecasting tool — not as a measure of productivity or performance.
That definition matters more than most teams realize. Velocity is descriptive, not prescriptive. It tells you what happened, not what should have happened. It reflects the team's capacity under the specific conditions of that sprint — the people available, the complexity of the work, the interruptions they faced, and the technical debt they navigated.
When teams treat velocity as a target to hit rather than a signal to read, they stop estimating honestly. And when honest estimation dies, so does the entire empirical foundation that makes Scrum work.
How to calculate agile velocity the right way
The formula for calculating sprint velocity is straightforward:
Velocity = total story points of completed user stories in a sprint
To get a reliable average velocity for planning, use the last three to five sprints:
Average velocity = total story points completed across sprints ÷ number of sprints
A practical example
Suppose your team completes the following over three sprints:
Sprint 1: Committed to 35 story points, completed 28
Sprint 2: Committed to 30 story points, completed 32
Sprint 3: Committed to 34 story points, completed 30
Your average velocity is (28 + 32 + 30) ÷ 3 = 30 story points per sprint.
What counts and what does not
Only user stories that fully meet the Definition of Done count toward velocity. If a story is 90% complete, it contributes zero points. This is not a technicality — it is the mechanism that keeps the metric honest. The moment you start giving partial credit, your velocity number becomes fiction.
A few rules that protect the integrity of your velocity calculation:
Never include incomplete work. A story that is not done is not done.
Do not count story points for bugs or technical debt unless your team explicitly estimates and includes them in sprint planning.
Use at least three to five sprints before relying on average velocity for forecasting. One sprint tells you almost nothing.
Keep your estimation scale consistent. If you switch from Fibonacci to T-shirt sizes mid-project, your historical velocity data becomes meaningless.
If you want to visualize how velocity relates to remaining work, pair it with a burndown graph — it shows whether you are on track to complete your sprint goal and makes velocity trends visible at a glance.
Why velocity is not a performance metric
This is the single most important thing to understand about velocity, and the thing most organizations get catastrophically wrong.
Velocity measures output volume, not performance, not quality, not value delivered. A team with a velocity of 50 is not "better" than a team with a velocity of 30. They are different teams, estimating with different scales, working on different problems, with different skill compositions.
What happens when you use velocity as a performance metric
When management starts treating velocity as a KPI, predictable dysfunction follows:
Story point inflation. Teams start estimating stories higher to make their velocity number look better. A task that was a 3 becomes a 5. Nothing changes except the numbers — and the trust.
Gaming the system. Teams split stories into smaller pieces not because it improves delivery but because closing more tickets inflates velocity. The WIP goes up, context-switching increases, and actual throughput drops.
Cutting corners on quality. When the goal is to close points, teams rush to mark stories as done. Testing gets skipped, edge cases get ignored, and technical debt accumulates silently until it explodes.
Demoralized teams. Developers who feel they are being judged by a number they know is arbitrary stop caring about accurate estimation. They disengage from sprint planning, and the ceremony becomes theater.
Loss of transparency. The entire point of velocity is to give the team an honest signal for planning. The moment it becomes a target, Goodhart's Law kicks in: when a measure becomes a target, it ceases to be a good measure.
The 18th State of Agile Report from Digital.ai confirms that organizations still struggle with using metrics to drive behavior rather than to inform decisions. Velocity misuse remains one of the top dysfunctions in agile teams globally.
What to tell your manager
If your leadership team is using velocity to compare teams or evaluate developer performance, here is a concise way to reframe the conversation:
"Velocity is our internal planning tool — like a speedometer. It tells us how fast we are going so we can plan our route, but it does not tell you whether we are going to the right destination. For that, we need outcome metrics like customer satisfaction, cycle time, and value delivered."
5 common velocity mistakes and how to fix them
1. Comparing velocity across teams
Every team estimates differently. A team of five senior engineers will have a different baseline than a team of eight mixed-experience developers. Comparing their velocities is like comparing test scores from two different exams — the numbers are meaningless without shared context.
Fix: Use velocity only within a single, stable team. If you need to compare teams, use normalized flow metrics like throughput (items completed per unit of time) or cycle time.
2. Setting velocity targets
The moment you say "we need to hit 40 points this sprint," you have turned a diagnostic tool into a performance weapon. Teams will find ways to hit 40 — none of them good.
Fix: Let velocity emerge naturally from honest estimation and consistent delivery. The goal is stability, not growth. A team whose velocity is consistently 28–32 is healthier than a team that swings between 20 and 50.
3. Using velocity for long-range forecasting without confidence intervals
Saying "our velocity is 30, so we will finish 300 points of backlog in 10 sprints" sounds precise. It is not. It ignores variance, team changes, holidays, emerging requirements, and the dozens of unknowns that affect real-world delivery.
Fix: Use velocity ranges rather than single-point estimates. If your velocity over the last five sprints was 26, 30, 28, 34, and 32, forecast with a range of 26–34. Mountain Goat Software's velocity range calculator is a practical example of this approach — it uses historical data to provide confidence intervals rather than false certainty.
4. Counting velocity from day one
New teams do not have a reliable velocity. Their first two to three sprints are calibration — learning how to estimate together, understanding the codebase, and finding their rhythm.
Fix: Do not use velocity for forecasting until you have at least three to five sprints of data. During the calibration phase, focus on learning and process improvement rather than planning precision.
5. Ignoring velocity trends
A single velocity number is a snapshot. The real insight comes from tracking trends over time. A steadily declining velocity might signal burnout, accumulating technical debt, or growing complexity. A sudden spike might mean story point inflation or a particularly straightforward sprint.
Fix: Review velocity trends in retrospectives. Ask why the number changed, not just what the number is. Velocity is a conversation starter, not a conversation ender.
What velocity actually tells you and what it does not
This is a question agile coaches, engineering leaders, and Scrum Masters frequently ask — and it is one of the most important things to get right.
Velocity tells you:
How much work (in story points) your team typically completes in a sprint
Whether your sprint commitments are realistic based on historical data
How stable and predictable your team's delivery cadence is over time
When something has disrupted the team's normal rhythm (a sudden drop or spike)
Velocity does not tell you:
Whether the team is delivering value to customers
Whether the code quality is improving or degrading
Whether individual team members are productive
How your team compares to other teams
Whether your product is getting closer to market fit
If you need metrics that address those deeper questions, look at outcome-based measurement frameworks. Our guide on OKRs vs KPIs in agile breaks down which metrics framework helps you measure what actually matters — value, outcomes, and impact rather than just output.
How to use velocity for sprint planning without gaming the numbers
Sprint planning is where velocity earns its keep — when used correctly. Here is a practical approach:
Step 1: Calculate your average velocity
Use the last three to five sprints. If your team has had a major change (new members, different project, changed sprint length), restart the count.
Step 2: Use velocity as a guide, not a commitment
Your average velocity tells you roughly how many story points the team can handle. Pull stories into the sprint until you approach that number — but leave a small buffer. Teams that pack sprints to 100% of their velocity consistently fail to finish everything.
A practical rule: plan to 80–85% of your average velocity. This leaves room for unexpected complexity, production issues, and the reality that not every sprint goes according to plan.
Step 3: Let the team decide
Velocity belongs to the team, not to management. The development team pulls work into the sprint based on their own assessment of capacity and complexity. If the Product Owner pushes for more, velocity data gives the team an evidence-based way to push back.
Step 4: Adjust for known disruptions
If team members are on vacation, if a holiday falls during the sprint, or if the team has a major production deployment scheduled, adjust your expected velocity downward. The formula is simple:
Adjusted velocity = average velocity × (available working days ÷ normal working days)
Step 5: Review and adapt
At the end of each sprint, compare planned versus completed story points. Not to assign blame — but to improve your planning accuracy. Over time, the gap between planned and completed should narrow, and your sprint velocity should stabilize.
Velocity in the age of AI: why the metric needs to evolve
Here is where most agile content stops — and where the conversation needs to go. AI is fundamentally changing how software teams work, and velocity as traditionally measured is starting to show its age.
The AI acceleration problem
When AI coding assistants help developers write code two to five times faster, what happens to velocity? Story points are supposed to measure relative complexity, not time. But in practice, most teams unconsciously anchor their estimates to effort — and when AI slashes the effort required, the relationship between story points and actual work breaks down.
A story that used to take three days might now take three hours with AI assistance. If the team still estimates it as an 8, their velocity skyrockets — but nothing meaningful has changed about their capacity to handle complexity.
Jeff Sutherland, co-creator of Scrum, has started advocating for separating "Human Points" from "AI Points" — distinguishing work that required human cognitive effort from work that was largely automated. This forces a different conversation: not how fast the team is moving, but how effectively they are shifting work from manual effort to automated delivery.
What this means for your team
If your team is integrating AI into its workflow, consider these adaptations:
Re-estimate after AI adoption. Your historical velocity data from before AI tools may no longer be a reliable baseline. Give the team three to five sprints to recalibrate.
Track what AI accelerates. Identify which types of work AI handles well (boilerplate code, test generation, documentation) and which still require deep human effort (architecture decisions, user research, complex debugging).
Shift focus from velocity to flow metrics. Cycle time, throughput, and work-in-progress limits become more meaningful than story points when AI changes the effort-to-complexity ratio. These metrics measure the system's performance rather than individual output.
Rethink sprint planning. When AI accelerates delivery, rigid two-week sprints might feel like artificial constraints. Some teams are moving toward continuous flow models — read more about how AI is breaking the corporate sprint and what alternatives are emerging.
AgileRestart, an Agile training and implementation framework designed for the age of AI, specifically addresses this challenge. Their AI-readiness assessments help teams evaluate how their metrics, processes, and planning practices need to evolve as AI tools become part of daily development work.
Better metrics to pair with velocity
Velocity works best when it is part of a broader metrics ecosystem — not when it stands alone. Here are the metrics that high-performing agile teams track alongside velocity:
Cycle time
How long it takes a single work item to move from "in progress" to "done." While velocity measures batch output per sprint, cycle time measures flow at the individual item level. A team can have stable velocity but terrible cycle time if items sit in review queues or waiting states for days.
Throughput
The number of work items completed per unit of time, regardless of their size. Unlike velocity, throughput is harder to game because it counts items rather than estimated points. It is especially useful when combined with cycle time to identify bottlenecks.
Sprint goal success rate
The percentage of sprints where the team achieves its sprint goal. This measures planning effectiveness and the team's ability to deliver on commitments. A team with a 90% sprint goal success rate and moderate velocity is healthier than a team with high velocity that never finishes what it promised.
Escaped defect rate
The number of bugs found in production after a sprint. High velocity means nothing if the team is shipping broken software. This metric keeps quality in the conversation and prevents the "close points at all costs" mentality.
Flow efficiency
The ratio of active work time to total time (including waiting, blocked, and review states). If a story takes 10 days from start to finish but only 2 days of actual work, your flow efficiency is 20% — meaning 80% of the time is waste. This metric reveals systemic problems that velocity completely hides.
Making velocity work for your team
Velocity is a simple, powerful tool — when you let it be what it is. It is a planning input. A forecasting range. A conversation starter in retrospectives. It is not a grade, not a target, and not a basis for performance reviews.
The teams that get the most value from velocity are the ones that:
Estimate honestly because they know nobody will punish them for a low number
Track trends instead of obsessing over individual sprints
Use ranges instead of single-point forecasts
Pair velocity with flow and outcome metrics for a complete picture
Revisit their approach as AI tools change the nature of their work
If your organization has been using velocity as a weapon — comparing teams, setting targets, or tying it to performance reviews — the fix is not to abandon the metric. It is to educate leadership on what velocity actually measures and introduce complementary metrics that address the questions velocity was never designed to answer.
If your agile transformation has stalled, your metrics are driving the wrong behavior, or your teams are struggling to adapt their practices for AI-augmented workflows, this is exactly what AgileRestart's training programs are built to solve. Their coaching and assessment services help organizations move from metric dysfunction to data-informed delivery — with specific frameworks for teams navigating the shift to AI-assisted development.
