Velocity Measurement

Velocity Measurement is the practice of tracking how much work, typically expressed in a relative sizing unit such as story points, a team completes within each iteration, building a historical record used primarily to inform how much work the team can realistically plan to take on in future iterations. It is one of the most widely used delivery metrics in agile teams that practice iterative, fixed-length sprints, and its value depends heavily on being interpreted as a planning aid grounded in relative estimation rather than as an absolute, comparable measure of output or performance.

What Velocity Actually Measures

A Team-Specific, Relative Quantity

Velocity is calculated from the team's own sizing estimates, most commonly story points, which are themselves relative units reflecting a team's shared, internal sense of relative effort or complexity rather than a standardized, externally comparable unit like hours or currency, meaning a velocity of a given number carries meaning only within the context of the specific team that produced it.

An Aggregate of Completed Work Within a Fixed Period

Velocity is calculated by summing the size estimates of all work items a team fully completed within a single iteration, and only fully completed work counts toward the total, distinguishing velocity clearly from a measure of effort expended on work still in progress.

The Primary Purpose of Tracking Velocity

Informing Iteration Planning

The most direct and reliable use of velocity is helping a team decide how much work to commit to in an upcoming iteration, using recent historical velocity as a guide to what has actually proven achievable in similar recent periods, rather than relying on optimistic guesses about capacity.

Supporting Longer-Term Forecasting

Aggregated across multiple iterations, velocity also feeds into longer-range projections about when a larger body of work might be completed, an application explored further under forecasting-focused practices, though this application requires the same caution about uncertainty that governs any forecast built from historical data.

Calculating and Tracking Velocity

Using a Rolling Average Rather Than a Single Iteration

Because any single iteration's velocity can be affected by unusual circumstances, teams typically calculate velocity as an average across several recent iterations rather than relying on the most recent iteration alone, smoothing out short-term noise to produce a more stable planning reference.

Accounting for Variability, Not Just the Average

Beyond the average, tracking the spread or range of velocity across recent iterations gives the team a sense of how consistent its delivery pace actually is, information that a single average figure alone does not convey and that matters for understanding the reliability of any plan built on top of it.

Why Velocity Should Not Be Compared Across Teams

Estimation Units Are Not Standardized Between Teams

Because relative sizing units are calibrated internally by each team's own shared understanding, a story point in one team carries no fixed equivalence to a story point in another team, making direct comparison of velocity numbers between different teams fundamentally misleading despite the apparent similarity of the unit's name.

Comparison Incentivizes Distorted Estimation

When velocity is used to compare or rank teams against one another, teams face pressure to inflate their size estimates in order to report a higher velocity number, a distortion that undermines the very estimation discipline velocity depends on and renders the resulting figures meaningless for their intended planning purpose.

A Velocity History Chart

The dashed average line, rather than any single bar, is the value most useful for planning purposes, since it reflects the team's demonstrated sustainable pace rather than the outcome of any one particular iteration that may have been unusually favorable or unfavorable.

Common Pitfalls

Setting Velocity as a Fixed Target to Hit

Treating velocity as a performance target the team must reach each iteration, rather than as a descriptive output of the team's actual historical pace, inverts its intended purpose and creates pressure to distort estimates or cut corners in order to report a number that meets an externally imposed expectation.

Applying Velocity From One Team's Context to Another

Using a departing or newly formed team's borrowed velocity figures from a different team's history as a planning baseline overlooks that velocity reflects a specific team's own calibration and historical pace, neither of which reliably transfers to a different group of people.

Ignoring Variability When Planning

Committing to work equal to the average velocity without accounting for the demonstrated spread across recent iterations risks planning as though every iteration will perform at exactly the historical average, when in practice the team's actual pace fluctuates around that average from one iteration to the next.