Sprint Velocity Explained: What It Measures and How to Use It

Sprint velocity sounds like a productivity score, but it measures something narrower and more useful than that.

Velocity: story points completed per sprint, nothing more

Velocity is simply the sum of story points for items a team actually finished within a sprint -- not points started, not points planned, only points meeting the team's definition of done. It is a measurement of a specific team's specific past, not a universal productivity metric.

A rolling average smooths out normal sprint-to-sprint noise

Any single sprint's velocity can swing due to holidays, unplanned work, or a team member being out, so forecasting off one sprint is unreliable. Averaging the last 3-6 sprints gives a steadier number that better reflects the team's typical pace.

Using velocity to forecast remaining work

Dividing the total story points remaining in a backlog by the average velocity gives a rough estimate of how many more sprints are needed to complete it -- useful for a general timeline conversation, not a precise delivery date commitment.

Velocity cannot be compared across different teams

Story point sizing is relative and specific to each team's own internal calibration -- one team's "5-point story" has no defined relationship to another team's "5-point story." A higher velocity number on one team says nothing about that team being faster or more productive than another.

Why treating velocity as a target backfires

Using velocity as a performance target -- rewarding higher numbers -- gives teams an incentive to inflate point estimates over time without doing more actual work, which quietly destroys the number's usefulness as a planning tool. Velocity works as a description of the past, not a target to hit.

Why velocity resets to near-zero for a new team

A newly formed team, or a team with a significantly changed roster, has no meaningful velocity history yet, since the number is specific to how that particular group of people estimates and executes together. Expect several sprints of noisy, unreliable velocity data before it stabilizes into something forecastable.

The difference between velocity and capacity

Velocity is a historical output measure (points completed), while capacity is a forward-looking input measure (available person-hours for an upcoming sprint, accounting for holidays, planned time off, and meetings). A sound sprint plan considers both, since a team's historical velocity assumes roughly typical capacity, which a specific upcoming sprint might not have.

Frequently Asked Questions

Is a higher velocity always better?

Not by itself. A rising velocity number can reflect genuinely improving efficiency, or it can reflect point inflation from a team padding estimates, and the two look identical on a chart. Velocity should be interpreted alongside actual delivered outcomes, not read as a standalone success metric.

How many sprints of data do I need before velocity is trustworthy?

Most teams need at least 3-5 completed sprints of relatively stable team composition and work type before an average velocity becomes a reasonably reliable forecasting input, since fewer data points are too easily skewed by one unusual sprint.