Velocity in Agile: How to Measure It and What It Really Tells You

The Dashboard That Ruined Sprint Planning

A VP sees a dashboard showing Team A at 45 velocity and Team B at 28. The obvious conclusion: Team A is more productive. The obvious next step: ask Team B why they’re falling behind.

Except that’s not what the numbers mean. Team A has 8 people and estimates generously. Team B has 5 people and estimates conservatively. Team B might actually deliver more value per person. But the dashboard doesn’t show that, and now Team B feels pressured to inflate their estimates.

This scenario plays out constantly in organisations that treat velocity as a performance indicator. Velocity is one of the most misused metrics in Agile. Understanding what it actually tells you, and what it doesn’t, is essential for any team that wants to plan honestly.

What Velocity Actually Is

Velocity is the total number of story points your team completes in a sprint. That’s it. No formula more complicated than addition.

If your team finishes stories worth 3, 5, 8, 5, and 2 points in a sprint, your velocity for that sprint is 23. Stories that weren’t completed don’t count, even if the team did 90% of the work. Only finished stories contribute to velocity.

The metric becomes useful when tracked over multiple sprints. A single sprint’s velocity is a data point. Three to five sprints of velocity data give you a trend. That trend is what you use for planning.

How to Calculate Velocity

The calculation is straightforward, but a few details matter:

Step 1: Count Completed Stories Only

A story is either done or it’s not. If the team finishes 80% of a story, it contributes zero points to velocity. This strict rule keeps the metric honest. Partial credit creates incentives to start many things instead of finishing a few.

Step 2: Add Up the Story Points

Sum the story points of every completed story. Include all work the team finished, whether it was planned at the start of the sprint or pulled in mid-sprint. Some teams only count planned work. Either approach is fine, but be consistent.

Step 3: Track Over Multiple Sprints

Record velocity for each sprint. After three to five sprints, calculate the average. This average velocity is your planning baseline. It tells you roughly how much work your team can handle per sprint.

Here’s an example over five sprints:

• Sprint 1: 25 points
• Sprint 2: 30 points
• Sprint 3: 22 points
• Sprint 4: 28 points
• Sprint 5: 27 points

Average velocity: 26.4 points. For the next sprint, plan for about 26 points of work. Don’t fill to capacity. Leave a buffer for unexpected items, learning, and the reality that some sprints just go differently than planned.

What Velocity Is Useful For

Velocity has exactly two legitimate uses. Both are about planning, not evaluation.

Sprint Capacity Planning

When your team pulls stories into the next sprint, velocity tells you roughly how many points to commit to. If your average velocity is 26, committing to 40 points of work is setting the team up for failure. Committing to 24 to 28 is realistic.

This is the core purpose of velocity. It replaces gut feeling with data when deciding “how much can we take on?”

Release Forecasting

If your backlog has 130 points of work remaining and your average velocity is 26, you can forecast roughly 5 sprints to completion. That’s useful for communicating timelines to stakeholders. It’s a forecast, not a promise, and it should always be presented with that caveat.

The forecast gets more reliable as you accumulate more velocity data and as the backlog becomes more refined. Early in a project, forecasting is rough. After 8 to 10 sprints of consistent data, it becomes genuinely useful.

What Velocity Is NOT Useful For

Here’s where teams and organisations consistently get it wrong.

Comparing Teams

Team A’s 40 points and Team B’s 25 points are not comparable. Story points are relative to each team’s own calibration. A 5 on Team A might represent the same amount of work as an 8 on Team B. Different teams, different reference stories, different scales. Comparing velocities across teams is like comparing temperatures in Fahrenheit and Celsius without converting.

Measuring Individual Performance

Velocity is a team metric. The moment you divide it by headcount or track individual contributions, you’ve created a toxic incentive. Developers will grab easy stories to boost their personal numbers. They’ll avoid helping teammates because collaboration doesn’t show up in individual velocity. The metric stops reflecting reality and starts reflecting self-preservation.

Performance Reviews

Using velocity in performance reviews is a guaranteed way to destroy its value as a planning tool. Teams that know their velocity will be used to evaluate them will inflate estimates, avoid risky stories, and resist any change to the estimation process. You’ll have beautiful velocity charts that mean absolutely nothing.

Setting Targets

“Your velocity needs to increase by 10% next quarter.” This sounds reasonable to executives but makes no sense in practice. Velocity is an output measure, not an input. You can’t make a team go faster by demanding a higher number. You can only improve the system they work in: clearer requirements, fewer interruptions, better tools, less technical debt.

How Teams Game Velocity

When velocity becomes a target, teams find creative ways to hit the number without increasing actual output. Recognising these patterns helps you spot the problem early.

• Estimate inflation: A task that was a 3 last month becomes a 5 this month. Velocity goes up. Output stays the same.
• Story splitting for points: Teams break stories into unnecessarily small pieces to generate more total points. The overhead of managing tiny stories can actually reduce throughput.
• Cherry-picking easy work: The team avoids complex, high-value stories in favour of simple tasks that are easy to finish and add up quickly.
• Cutting corners on quality: Skipping code review, reducing test coverage, or ignoring edge cases to get stories across the finish line before the sprint ends.

Every one of these behaviours makes the velocity chart look better while making the product worse. If you notice velocity increasing without a corresponding increase in stakeholder satisfaction or delivered features, gaming is probably happening.

When Velocity Becomes Toxic

Velocity turns toxic when the organisation treats it as the primary measure of success. The warning signs are clear:

• Managers ask “why did velocity drop?” before asking “what did we learn?”
• Teams feel pressure to hit a velocity target every sprint
• Velocity appears on dashboards visible to leadership without context
• Teams resist re-estimation or recalibration because it would change the velocity trend
• Sprint reviews focus on points delivered instead of value delivered

If your team exhibits any of these signs, the metric is doing more harm than good. Stop tracking velocity publicly, or at least stop reporting it to anyone outside the team. Keep it as an internal planning tool and find other ways to communicate progress to stakeholders.

Alternative Metrics Worth Considering

Velocity is not the only way to measure progress and plan capacity. Depending on your workflow, these alternatives might serve you better.

Throughput

Throughput is the number of items completed per time period, regardless of size. If your team finishes 12 stories this sprint, your throughput is 12. This works especially well when your team breaks work into consistently small pieces. No estimation required.

Throughput has a major advantage over velocity: it can’t be inflated by changing estimates. A completed item is a completed item. The downside is that it treats all items as equal, so a quick bug fix and a complex feature both count as one.

Cycle Time

Cycle time measures how long a single item takes from the moment work starts to the moment it’s done. If a story enters “In Progress” on Monday and reaches “Done” on Thursday, the cycle time is 4 days.

Cycle time is powerful because it focuses on flow, not output. A team with a short, consistent cycle time is delivering value frequently and predictably. It’s particularly useful for Kanban teams that don’t work in sprints.

Lead Time

Lead time is similar to cycle time but measured from when an item is requested to when it’s delivered. This includes time spent waiting in the backlog, not just active work time. Lead time is the metric your stakeholders care about because it reflects how long they wait for something after asking for it.

Flow Efficiency

Flow efficiency is the ratio of active work time to total lead time. If a story has a lead time of 10 days but was only actively worked on for 2 days, the flow efficiency is 20%. Most teams are shocked at how low their flow efficiency is. Typical numbers are 15% to 40%. The rest is waiting: waiting for review, waiting for testing, waiting for deployment, waiting for clarification.

Improving flow efficiency often delivers more impact than trying to increase velocity, because you’re eliminating waste rather than pushing people to work faster.

Making Velocity Work for Your Team

If you use velocity, protect it from misuse with a few simple rules:

• Keep it internal. Velocity is the team’s planning tool. Share it with the Scrum Master and Product Owner. Don’t put it on executive dashboards.
• Never set velocity targets. Velocity is an observation, not a goal. You observe what the team can do, then plan accordingly.
• Use a range, not a single number. Instead of saying “our velocity is 26,” say “our velocity typically falls between 22 and 30.” The range is more honest and more useful for planning.
• Recalibrate regularly. If the team composition changes, if you adopt new technology, or if estimation practices evolve, historical velocity may not apply. Reset and rebuild.
• Pair it with outcome metrics. Velocity tells you how much was built. Pair it with metrics that tell you whether what was built mattered: customer satisfaction, feature adoption, bug rates, and business outcomes.

Frequently Asked Questions

What is a good velocity for an Agile team?

There’s no universal “good” velocity. It depends entirely on your team’s size, experience, estimation calibration, and the complexity of the work. A velocity of 20 might be great for a team of 4 and terrible for a team of 10. The only meaningful comparison is your own team’s velocity over time. A stable velocity is a healthy velocity.

How many sprints do you need to establish velocity?

Three sprints give you a rough baseline. Five sprints give you a more reliable average. The first sprint is almost always an outlier as the team adjusts to a new process. Don’t put too much weight on early data. Velocity stabilises as the team builds estimation consistency and learns their actual capacity.

Should partially completed stories count toward velocity?

No. Velocity should only count fully completed stories that meet the team’s definition of done. Counting partial work inflates velocity and creates incentives to start many stories rather than finish a few. If a story is 90% done at the end of a sprint, it carries over to the next sprint and gets counted there.

Why does velocity fluctuate between sprints?

Fluctuation is normal. Team members take vacation, get pulled into meetings, deal with production incidents, or encounter unexpected complexity. A velocity that varies by 20% to 30% between sprints is typical. Large swings (50%+) usually indicate a systemic issue: unclear stories, too much unplanned work, or a team member change that hasn’t been accounted for.

Can you compare velocity across different teams?

No. Story points are relative to each team’s own calibration. A 5 on one team might represent entirely different work than a 5 on another team. Comparing velocities across teams is meaningless and usually harmful. If you need to compare team output, use outcome-based metrics like features delivered, customer satisfaction, or business impact.

What is the difference between velocity and throughput?

Velocity measures story points completed per sprint. Throughput measures the number of items completed per time period, regardless of their size. Velocity requires estimation. Throughput doesn’t. Teams that break work into consistently small pieces often find throughput more useful because it’s simpler and harder to game.

What should you do if management uses velocity as a performance metric?

Address it directly. Explain that velocity is a planning tool, not a performance measure, and that using it as a target incentivises gaming rather than genuine productivity. Offer alternative metrics that better reflect performance: customer outcomes, quality metrics, and delivery predictability. If the conversation doesn’t land, consider sharing velocity only within the team.

Is velocity relevant for Kanban teams?

Kanban teams don’t typically use velocity because they don’t work in sprints. The equivalent metrics are throughput (items completed per week) and cycle time (how long each item takes). These metrics serve the same planning purpose as velocity but fit a continuous flow workflow better than a sprint-based measurement.