Sprint Velocity — The Misunderstood Metric and How to Actually Use It

At UshaOm, I used sprint velocity as a planning tool for two years. It worked — until it didn't. Our velocity was steadily increasing, which looked great in sprint reviews. Then I realized engineers were inflating story point estimates to make velocity look better. A task that was 3 points six months ago was now 5 points. Our "improving velocity" was an illusion. That experience taught me both the value and the danger of this metric.

Sprint velocity has been the subject of countless arguments in engineering team standups. Is it a useful planning tool or a vanity metric that encourages gaming and burnout? The answer, unsurprisingly, is that it depends—but most teams are using it wrong.

In this guide, we'll cut through the confusion. We'll explore what velocity actually measures, why so many engineering leaders distrust it, and most importantly, how to use it in ways that genuinely improve capacity planning without creating perverse incentives.

What Is Sprint Velocity? Definition, Story Points, and the Basic Calculation

Sprint velocity is a straightforward metric: the sum of story points completed in a single sprint. If your team finishes eight user stories worth 3, 5, 2, 3, 5, 8, 2, and 1 points respectively during a two-week sprint, your velocity for that sprint is 32 points.

On its surface, this seems simple. But the simplicity masks several important nuances.

Story Points vs. Tasks vs. Hours

Most mature Agile teams use story points rather than hours or task counts for estimation. Story points are relative estimates of effort that account for complexity, uncertainty, and dependencies—not just raw coding time.

A 5-point story doesn't mean five hours of work. It means "roughly 2–3 times the effort of a 2-point story, with moderate uncertainty." This abstraction is intentional. It prevents teams from conflating actual hours worked (which vary wildly based on interruptions, meetings, and context-switching) with actual work capacity.

Some teams still estimate in hours or count completed tasks. These approaches tend to produce less stable metrics because they're more sensitive to fluctuations in team composition, unexpected interruptions, and the reality that not all hours are equally productive.

The Calculation

The calculation is elementary:

Velocity = Sum of Story Points for Completed Work in One Sprint

Completed work means work that meets your team's definition of done. Partially finished work doesn't count. This distinction is crucial—it's why velocity is primarily useful for capacity planning rather than progress reporting.

A single sprint's velocity means almost nothing. What matters is the trend. If your team's velocity over the last eight sprints has been: 28, 31, 29, 32, 30, 31, 29, 30—you have highly predictable velocity around 30 points. You can confidently plan sprints assuming you'll complete roughly 30 points of work.

If your velocity over eight sprints has been: 15, 28, 22, 35, 18, 40, 25, 32—you have unpredictable velocity. Something is destabilizing your capacity, and velocity itself won't help you forecast. You need to investigate the root cause.

The Great Velocity Debate: Why Engineering Leaders Distrust the Metric

Ask a hundred engineering managers whether sprint velocity is useful, and you'll get a hundred different answers—with strong opinions on both sides. The skepticism is earned.

Goodhart's Law and the Incentive Problem

Goodhart's Law states: "When a measure becomes a target, it ceases to be a good measure."

Sprint velocity is uniquely vulnerable to this trap. Here's why: leadership sees that Team A completes 40 points per sprint while Team B completes 25 points. The natural inclination is to set targets ("We need Team B to hit 40 points next sprint") or to compare team productivity.

The moment you do this, you've created an incentive structure that distorts the metric. Teams begin gaming the system:

Point inflation: Stories get estimated at higher points to make completion look more impressive. A task that would realistically take 3 story points gets labeled as 5 to create the appearance of higher productivity.
Scope reduction: Teams break stories into smaller pieces or defer dependencies and bugs, claiming they've completed work when the customer value hasn't actually shipped.
Rushed quality: Teams prioritize velocity over code quality, technical debt increases, and velocity becomes artificially high for a sprint or two before crashing.

Over time, the points become meaningless. They no longer represent relative effort or complexity—they represent whatever point value the team decided would look good in the sprint review.

The Performance Trap

Velocity is not a measure of team performance. Yet it's constantly misused as one. This creates organizational pressure and often leads to burnout.

A team that completes 40 points is not twice as productive as a team that completes 20 points. The 40-point team might be on a simpler problem domain. They might have fewer dependencies. They might have been together longer and have lower onboarding overhead. They might have lower quality standards. The metric simply doesn't tell you.

When velocity gets tied to performance reviews, raises, or sprint planning pressure, you've turned a planning tool into a performance measurement—and it's the wrong tool for that job.

Technical Debt and the Velocity Cliff

One of the harshest critiques of velocity comes from teams that have experienced "the velocity cliff." For several sprints, a team delivers consistently high velocity while also deferring architectural work and cutting corners. Velocity remains stable or even climbs.

Then something breaks. A major refactoring becomes mandatory. Bugs accumulate. Dependencies across the codebase make new features harder to add. Suddenly, velocity drops 50% or more.

The team didn't become less productive. The chickens came home to roost. But leadership is baffled: "Why did your velocity drop so dramatically?"

This is why velocity alone is a dangerous planning metric without context about technical debt, refactoring time, and architectural health.

What Velocity Is Actually Good For: Realistic Capacity Planning

Setting aside the misuses, velocity does have legitimate, high-value applications.

Capacity Planning and Sprint Forecasting

The primary strength of velocity is trend-based capacity planning. If your team consistently delivers 30 points per sprint (with reasonable variance), you can forecast with confidence:

"If we have a 200-point feature request, we need roughly 6–7 sprints to complete it, assuming no major disruptions."
"With two team members on vacation next sprint, we should expect velocity to drop by about 15–20%."
"We can reliably commit to these three features (totaling 28 points) in the next sprint."

This is simple but enormously valuable. It allows you to have honest conversations about capacity and tradeoffs with product leadership.

Without stable velocity data, you're making delivery commitments in the dark. With it, you're making informed estimates based on your team's actual track record.

Identifying Disruptions and Anomalies

A sudden drop in velocity is a red flag that something has changed. It might signal:

Increased dependencies on other teams or systems
Onboarding friction from new team members
Technical problems (infrastructure instability, broken CI/CD, etc.)
Organizational changes (reorganization, priority chaos, excessive meetings)
Quality issues (bugs accumulating, code review bottlenecks)

The metric itself doesn't tell you what's wrong—but the anomaly tells you to investigate. A team that drops from 30 to 18 points has a problem worth understanding.

Stabilizing Team Dynamics

For teams trying to establish sustainable work practices, velocity trends can be motivating in a healthy way. Not "we need to hit 40 points," but rather: "We've been consistently around 28 points for three months, our code quality is high, nobody's working weekends, and we're not accumulating tech debt. That's sustainable and we should be proud of it."

Velocity can reinforce a healthy equilibrium when used as a retrospective observation rather than a prescriptive target.

What Velocity Should Never Be Used For

The flip side is equally important: understanding the metric's limitations.

Never Compare Team Velocities

"Team A averages 40 points per sprint, Team B averages 20 points. Team A is twice as productive."

This logic is flawed. The teams might be working on different problem domains with different complexity profiles. They might have different definition-of-done standards. One team might include QA in their story points; another might not. Their story point scales might have drifted apart.

Cross-team velocity comparisons are almost always misleading.

Never Use Velocity for Individual Performance Evaluation

Story points represent team effort, not individual effort. Using velocity to judge an individual contributor's productivity is both inaccurate and corrosive to team dynamics.

Never Report Velocity to Executive Leadership as a Productivity Metric

Senior leaders often want a single number representing team output. Velocity is not that number. It's a planning input, not a business outcome.

If you need to report team productivity to executives, consider metrics like:

Features shipped per quarter
Customer impact (revenue, retention, satisfaction)
Reduced cycle time for key features
Bug escape rate and post-release defects

Velocity is for internal planning, not external reporting.

Never Use Velocity to Set Stretch Goals or Targets

"Your velocity has been 28 points. Next sprint, we want you to hit 35 points" is a recipe for gaming and burnout.

If you want to improve team capacity, address the underlying constraints: reduce interruptions, cut meetings, stabilize team composition, improve development infrastructure, clarify requirements.

How to Track Velocity Properly: Best Practices

If you're going to use velocity, do it right. These practices maximize its signal and minimize its noise.

Consistent Estimation Practices

Estimate as a team, not individually. Estimation discussion surfaces assumptions and dependencies.
Use reference stories. Define what a 1-point, 3-point, 5-point, and 8-point story looks like. Use these as anchors.
Estimate before the sprint starts. Avoid re-estimating mid-sprint to manipulate velocity.
Keep the scale small. Use Fibonacci-style sequences (1, 2, 3, 5, 8, 13). Stories bigger than 13 points should be broken down.
Estimate based on effort, not time. How much complexity and effort will this require? Not: how many hours will this take?

Stable Team Composition

Velocity stabilizes with stable teams. Constantly rotating people in and out makes the metric meaningless.

If turnover is inevitable, account for it explicitly. A team that lost 30% of its people might reasonably see velocity drop by 20–30% until onboarding stabilizes. That's not failure—it's reality.

Exclude Carryover Work

If a story started in Sprint 12 and finished in Sprint 13, count it in Sprint 13 (when it was actually completed), not both sprints.

This can lower velocity when you have significant carryover, but it gives you an accurate picture of what a sprint actually produces.

Handle Bugs and Maintenance Separately (Or Be Consistent)

Some teams include bug fixes in velocity. Others track bugs separately. Either approach is fine—but be consistent.

A team that's been including bugs in velocity for three years and then suddenly stops will see an artificial velocity boost. Consistency matters more than the specific choice.

Track Planned vs. Unplanned Work

Some interruptions are inevitable (production incidents, urgent requests). If you're tracking velocity, separately log unplanned work.

If a sprint was supposed to be 30 points but 8 points were unplanned interruptions, your actual capacity was 22 points that sprint. Distinguishing these helps with future planning.

Alternatives and Complements to Velocity: Throughput and Cycle Time

Sprint velocity isn't the only way to measure team capacity. For many teams, alternative or complementary metrics provide better insight.

Throughput: Items Completed Per Sprint

Instead of summing story points, simply count the number of items (user stories, features, bugs) completed per sprint.

Advantage: No estimation required. The metric is objective and harder to game. Disadvantage: Doesn't account for work complexity. A 1-point bug fix and a 13-point feature count equally.

Throughput works well for teams doing very similar work repeatedly (e.g., a support team processing tickets) or as a complement to velocity.

Cycle Time: How Long From Start to Done?

Cycle time measures the elapsed time between when work starts and when it's complete. Unlike velocity, cycle time doesn't require estimation.

If your team's average cycle time is 5 days and you have 20 stories in the backlog, you can forecast: "These will take roughly 100 days of elapsed time (about 3 sprints, accounting for parallel work)."

Cycle time is increasingly popular because it's:

Hard to game (it's objective fact)
Relevant to customer value (shorter cycles mean faster value delivery)
Actionable (constraints in cycle time often reveal bottlenecks)

Flow Efficiency: The Percentage of Time Work Is Actually Being Worked On

If a story takes 5 days of elapsed time but only 1 day of actual work, the flow efficiency is 20%. The other 80% is waiting in queues, handoffs, reviews, or blockers.

High-performing teams often focus on improving flow efficiency—reducing handoffs, unblocking dependencies, shortening review cycles—rather than trying to push more story points through.

Making Velocity Meaningful with AI: Correlating Changes with Actual Causes

This is where modern tools like Glue change the game.

Human analysis of velocity trends is limited. You can see that velocity dropped, but understanding why requires manual investigation. Did team composition change? Did the backlog become more complex? Are there more external dependencies? Did the codebase become harder to work with?

Modern AI-driven platforms can correlate velocity changes with actual signals in your engineering infrastructure:

Git activity and code complexity: Rising complexity in recent commits correlates with lower velocity.
Deployment frequency: More frequent deployments often correlate with lower velocity in that sprint (because some capacity goes to CI/CD work).
Incident response: Production incidents consume unplanned capacity. AI can automatically account for this.
PR cycle time: Long review cycles or large PRs might indicate bottlenecks that are dragging down velocity.
Test suite duration: If your test suite has slowed down, it's consuming capacity that isn't visible in velocity numbers.

By connecting velocity trends to these signals, engineering leaders gain causal understanding. You're not just observing that velocity dropped—you understand whether it's a problem to fix or an expected result of legitimate tradeoffs.

Glue integrates directly with your development infrastructure (GitHub, GitLab, CI/CD systems, issue trackers) to provide this context automatically. When you see a velocity anomaly, you immediately see the correlating factors: "Velocity dropped 25% this sprint. Test suite execution time increased 40%. That's why."

This transforms velocity from a baffling number into a useful signal grounded in engineering reality.

Conclusion: Using Velocity Wisely

Sprint velocity is neither the silver bullet some believe it to be nor the useless vanity metric its critics claim. It's a valuable planning tool when used appropriately and a source of organizational dysfunction when misused.

The key is understanding what it actually measures: consistent team capacity under stable conditions. It's useful for forecasting and identifying anomalies. It's useless for comparing teams, evaluating individuals, or setting performance targets.

Modern engineering teams should track velocity as part of a broader toolkit. Complement it with throughput, cycle time, and flow metrics. Give it context by understanding the factors that drive changes. And most importantly, never let the metric drive behavior—always keep actual team health and sustainable productivity as your north star.

About Glue: Glue is an Agentic Product OS built for engineering teams to solve the problems that velocity and traditional metrics leave unanswered. By connecting to your entire development infrastructure, Glue helps engineering managers, scrum masters, and product leaders understand not just what metrics are changing, but why—and what to do about it. Instead of staring at a number and guessing, you get correlated signals from your git history, CI/CD systems, incident logs, and code quality tools. This means you can make data-driven decisions about where to invest engineering effort, how to unblock teams, and how to maintain sustainable velocity without burning people out. If you're tired of velocity metrics that don't tell you what's actually happening in your engineering organization, Glue brings clarity to the signals that matter.

Glue transforms velocity from a baffling number into actionable insight by automatically correlating sprint metrics with the underlying causes—deployment patterns, code complexity changes, incident response load, and team composition shifts. With Glue, engineering teams finally have a tool that helps them use metrics intelligently rather than becoming slaves to them.

Sprint Velocity — The Misunderstood Metric and How to Actually Use It

What Is Sprint Velocity? Definition, Story Points, and the Basic Calculation

On its surface, this seems simple. But the simplicity masks several important nuances.

Story Points vs. Tasks vs. Hours

The Calculation

The calculation is elementary:

Velocity = Sum of Story Points for Completed Work in One Sprint

The Great Velocity Debate: Why Engineering Leaders Distrust the Metric

Ask a hundred engineering managers whether sprint velocity is useful, and you'll get a hundred different answers—with strong opinions on both sides. The skepticism is earned.

Goodhart's Law and the Incentive Problem

Goodhart's Law states: "When a measure becomes a target, it ceases to be a good measure."

The moment you do this, you've created an incentive structure that distorts the metric. Teams begin gaming the system:

Point inflation: Stories get estimated at higher points to make completion look more impressive. A task that would realistically take 3 story points gets labeled as 5 to create the appearance of higher productivity.
Scope reduction: Teams break stories into smaller pieces or defer dependencies and bugs, claiming they've completed work when the customer value hasn't actually shipped.
Rushed quality: Teams prioritize velocity over code quality, technical debt increases, and velocity becomes artificially high for a sprint or two before crashing.

Over time, the points become meaningless. They no longer represent relative effort or complexity—they represent whatever point value the team decided would look good in the sprint review.

The Performance Trap

Velocity is not a measure of team performance. Yet it's constantly misused as one. This creates organizational pressure and often leads to burnout.

When velocity gets tied to performance reviews, raises, or sprint planning pressure, you've turned a planning tool into a performance measurement—and it's the wrong tool for that job.

Technical Debt and the Velocity Cliff

Then something breaks. A major refactoring becomes mandatory. Bugs accumulate. Dependencies across the codebase make new features harder to add. Suddenly, velocity drops 50% or more.

The team didn't become less productive. The chickens came home to roost. But leadership is baffled: "Why did your velocity drop so dramatically?"

This is why velocity alone is a dangerous planning metric without context about technical debt, refactoring time, and architectural health.

What Velocity Is Actually Good For: Realistic Capacity Planning

Setting aside the misuses, velocity does have legitimate, high-value applications.

Capacity Planning and Sprint Forecasting

The primary strength of velocity is trend-based capacity planning. If your team consistently delivers 30 points per sprint (with reasonable variance), you can forecast with confidence:

"If we have a 200-point feature request, we need roughly 6–7 sprints to complete it, assuming no major disruptions."
"With two team members on vacation next sprint, we should expect velocity to drop by about 15–20%."
"We can reliably commit to these three features (totaling 28 points) in the next sprint."

This is simple but enormously valuable. It allows you to have honest conversations about capacity and tradeoffs with product leadership.

Without stable velocity data, you're making delivery commitments in the dark. With it, you're making informed estimates based on your team's actual track record.

Identifying Disruptions and Anomalies

A sudden drop in velocity is a red flag that something has changed. It might signal:

Increased dependencies on other teams or systems
Onboarding friction from new team members
Technical problems (infrastructure instability, broken CI/CD, etc.)
Organizational changes (reorganization, priority chaos, excessive meetings)
Quality issues (bugs accumulating, code review bottlenecks)

The metric itself doesn't tell you what's wrong—but the anomaly tells you to investigate. A team that drops from 30 to 18 points has a problem worth understanding.

Stabilizing Team Dynamics

Velocity can reinforce a healthy equilibrium when used as a retrospective observation rather than a prescriptive target.

What Velocity Should Never Be Used For

The flip side is equally important: understanding the metric's limitations.

Never Compare Team Velocities

"Team A averages 40 points per sprint, Team B averages 20 points. Team A is twice as productive."

Cross-team velocity comparisons are almost always misleading.

Never Use Velocity for Individual Performance Evaluation

Story points represent team effort, not individual effort. Using velocity to judge an individual contributor's productivity is both inaccurate and corrosive to team dynamics.

Never Report Velocity to Executive Leadership as a Productivity Metric

Senior leaders often want a single number representing team output. Velocity is not that number. It's a planning input, not a business outcome.

If you need to report team productivity to executives, consider metrics like:

Features shipped per quarter
Customer impact (revenue, retention, satisfaction)
Reduced cycle time for key features
Bug escape rate and post-release defects

Velocity is for internal planning, not external reporting.

Never Use Velocity to Set Stretch Goals or Targets

"Your velocity has been 28 points. Next sprint, we want you to hit 35 points" is a recipe for gaming and burnout.

If you want to improve team capacity, address the underlying constraints: reduce interruptions, cut meetings, stabilize team composition, improve development infrastructure, clarify requirements.

How to Track Velocity Properly: Best Practices

If you're going to use velocity, do it right. These practices maximize its signal and minimize its noise.

Consistent Estimation Practices

Estimate as a team, not individually. Estimation discussion surfaces assumptions and dependencies.
Use reference stories. Define what a 1-point, 3-point, 5-point, and 8-point story looks like. Use these as anchors.
Estimate before the sprint starts. Avoid re-estimating mid-sprint to manipulate velocity.
Keep the scale small. Use Fibonacci-style sequences (1, 2, 3, 5, 8, 13). Stories bigger than 13 points should be broken down.
Estimate based on effort, not time. How much complexity and effort will this require? Not: how many hours will this take?

Stable Team Composition

Velocity stabilizes with stable teams. Constantly rotating people in and out makes the metric meaningless.

If turnover is inevitable, account for it explicitly. A team that lost 30% of its people might reasonably see velocity drop by 20–30% until onboarding stabilizes. That's not failure—it's reality.

Exclude Carryover Work

If a story started in Sprint 12 and finished in Sprint 13, count it in Sprint 13 (when it was actually completed), not both sprints.

This can lower velocity when you have significant carryover, but it gives you an accurate picture of what a sprint actually produces.

Handle Bugs and Maintenance Separately (Or Be Consistent)

Some teams include bug fixes in velocity. Others track bugs separately. Either approach is fine—but be consistent.

A team that's been including bugs in velocity for three years and then suddenly stops will see an artificial velocity boost. Consistency matters more than the specific choice.

Track Planned vs. Unplanned Work

Some interruptions are inevitable (production incidents, urgent requests). If you're tracking velocity, separately log unplanned work.

If a sprint was supposed to be 30 points but 8 points were unplanned interruptions, your actual capacity was 22 points that sprint. Distinguishing these helps with future planning.

Alternatives and Complements to Velocity: Throughput and Cycle Time

Sprint velocity isn't the only way to measure team capacity. For many teams, alternative or complementary metrics provide better insight.

Throughput: Items Completed Per Sprint

Instead of summing story points, simply count the number of items (user stories, features, bugs) completed per sprint.

Advantage: No estimation required. The metric is objective and harder to game. Disadvantage: Doesn't account for work complexity. A 1-point bug fix and a 13-point feature count equally.

Throughput works well for teams doing very similar work repeatedly (e.g., a support team processing tickets) or as a complement to velocity.

Cycle Time: How Long From Start to Done?

Cycle time measures the elapsed time between when work starts and when it's complete. Unlike velocity, cycle time doesn't require estimation.

Cycle time is increasingly popular because it's:

Hard to game (it's objective fact)
Relevant to customer value (shorter cycles mean faster value delivery)
Actionable (constraints in cycle time often reveal bottlenecks)

Flow Efficiency: The Percentage of Time Work Is Actually Being Worked On

If a story takes 5 days of elapsed time but only 1 day of actual work, the flow efficiency is 20%. The other 80% is waiting in queues, handoffs, reviews, or blockers.

High-performing teams often focus on improving flow efficiency—reducing handoffs, unblocking dependencies, shortening review cycles—rather than trying to push more story points through.

Making Velocity Meaningful with AI: Correlating Changes with Actual Causes

This is where modern tools like Glue change the game.

Modern AI-driven platforms can correlate velocity changes with actual signals in your engineering infrastructure:

Git activity and code complexity: Rising complexity in recent commits correlates with lower velocity.
Deployment frequency: More frequent deployments often correlate with lower velocity in that sprint (because some capacity goes to CI/CD work).
Incident response: Production incidents consume unplanned capacity. AI can automatically account for this.
PR cycle time: Long review cycles or large PRs might indicate bottlenecks that are dragging down velocity.
Test suite duration: If your test suite has slowed down, it's consuming capacity that isn't visible in velocity numbers.

This transforms velocity from a baffling number into a useful signal grounded in engineering reality.

Sprint Velocity — The Misunderstood Metric and How to Actually Use It

Sprint Velocity — The Misunderstood Metric and How to Actually Use It

What Is Sprint Velocity? Definition, Story Points, and the Basic Calculation

Story Points vs. Tasks vs. Hours

The Calculation

Historical Data and Trending

The Great Velocity Debate: Why Engineering Leaders Distrust the Metric

Goodhart's Law and the Incentive Problem

The Performance Trap

Technical Debt and the Velocity Cliff

What Velocity Is Actually Good For: Realistic Capacity Planning

Capacity Planning and Sprint Forecasting

Identifying Disruptions and Anomalies

Stabilizing Team Dynamics

What Velocity Should Never Be Used For

Never Compare Team Velocities

Never Use Velocity for Individual Performance Evaluation

Never Report Velocity to Executive Leadership as a Productivity Metric

Never Use Velocity to Set Stretch Goals or Targets

How to Track Velocity Properly: Best Practices

Consistent Estimation Practices

Stable Team Composition

Exclude Carryover Work

Handle Bugs and Maintenance Separately (Or Be Consistent)

Track Planned vs. Unplanned Work

Alternatives and Complements to Velocity: Throughput and Cycle Time

Throughput: Items Completed Per Sprint

Cycle Time: How Long From Start to Done?

Flow Efficiency: The Percentage of Time Work Is Actually Being Worked On

Making Velocity Meaningful with AI: Correlating Changes with Actual Causes

Conclusion: Using Velocity Wisely

Related Reading

More articles

Engineering Copilot vs Agent: Why Autocomplete Isn't Enough

Product OS: Why Every Engineering Team Needs an Operating System for Their Product

Devin AI Alternatives: Why You Need Agents That Monitor, Not Just Code

Stop stitching. Start shipping.

Sprint Velocity — The Misunderstood Metric and How to Actually Use It

Sprint Velocity — The Misunderstood Metric and How to Actually Use It

What Is Sprint Velocity? Definition, Story Points, and the Basic Calculation

Story Points vs. Tasks vs. Hours

The Calculation

Historical Data and Trending

The Great Velocity Debate: Why Engineering Leaders Distrust the Metric

Goodhart's Law and the Incentive Problem

The Performance Trap

Technical Debt and the Velocity Cliff

What Velocity Is Actually Good For: Realistic Capacity Planning

Capacity Planning and Sprint Forecasting

Identifying Disruptions and Anomalies

Stabilizing Team Dynamics

What Velocity Should Never Be Used For

Never Compare Team Velocities

Never Use Velocity for Individual Performance Evaluation

Never Report Velocity to Executive Leadership as a Productivity Metric

Never Use Velocity to Set Stretch Goals or Targets

How to Track Velocity Properly: Best Practices

Consistent Estimation Practices

Stable Team Composition

Exclude Carryover Work

Handle Bugs and Maintenance Separately (Or Be Consistent)

Track Planned vs. Unplanned Work

Alternatives and Complements to Velocity: Throughput and Cycle Time

Throughput: Items Completed Per Sprint

Cycle Time: How Long From Start to Done?

Flow Efficiency: The Percentage of Time Work Is Actually Being Worked On

Making Velocity Meaningful with AI: Correlating Changes with Actual Causes

Conclusion: Using Velocity Wisely

Related Reading

More articles

Engineering Copilot vs Agent: Why Autocomplete Isn't Enough

Product OS: Why Every Engineering Team Needs an Operating System for Their Product

Devin AI Alternatives: Why You Need Agents That Monitor, Not Just Code

Stop stitching. Start shipping.