Project velocity

Project velocity is the amount of completed work a team delivers in a single iteration, averaged across recent iterations to smooth out variation. If a team finishes 30 story points in one sprint, 26 in the next, and 34 in the third, its average velocity is 30 points per sprint. The unit can be story points, completed tickets, or any consistent measure of done work, as long as the team applies it the same way every iteration.

Velocity matters because it converts a backlog into a forecast. If 200 points of work remain and the team averages 30 points per sprint, you can expect roughly seven sprints of delivery. It also exposes drift. When velocity falls steadily over several iterations, something underneath has changed: scope is growing, the team is shrinking, or work is getting stuck before it reaches done.

Velocity is a planning and diagnostic tool, not a performance score. It is specific to one team and one estimation scale, so comparing velocity across teams is meaningless. What matters is the trend within a team and the reasons behind any change. A high velocity built on inflated estimates or unfinished work that gets counted anyway is worse than a lower velocity that is honest and stable.

The base calculation divides total completed work by the number of iterations measured. Most teams average the last three to five iterations rather than relying on a single sprint, because one sprint is too noisy to plan against. The real value comes from breaking velocity into the inputs that produce it, which is where the trend becomes explainable.

1. 1

   Completed work units

   The total story points or items that reached done and were accepted during the period. This is the numerator, and the definition of done must be consistent across every iteration for the number to mean anything.

2. 2

   Number of iterations

   How many sprints or cycles the completed work is spread across. Averaging across several iterations removes the distortion of one unusually fast or slow sprint.

3. 3

   Committed capacity

   The work the team planned to take on, expressed in the same unit. Comparing committed capacity to completed work shows whether the team is over-committing, which is a common cause of carry-over and falling velocity.

4. 4

   Team availability

   The effective working time available after holidays, on-call duty, support rotations, and meetings. A drop in availability lowers velocity without any change in how the team works, so it must be tracked alongside the headline number.

Reading these inputs together prevents misdiagnosis. A velocity drop caused by two engineers on holiday is a capacity event that will reverse on its own. A velocity drop while capacity is unchanged points to a process problem: work is getting blocked, estimates are drifting, or rework is consuming the iteration. The number is the same in both cases, but the response is completely different. Velocity is closely related to sprint velocity and to cycle time, which measures how long individual items take to flow through.

A metric tree decomposes velocity into the factors that determine how much finished work a team can produce in an iteration. This turns velocity from a single number on a chart into a map of where delivery is being gained or lost.

The first level splits velocity into capacity, flow efficiency, and estimation accuracy. Capacity is how much effective time the team has. Flow efficiency is how much of that time turns into completed work rather than waiting, blocked, or rework. Estimation accuracy governs whether the points completed reflect real effort or drift in how the team sizes work. Each branch decomposes further into operational levers a specific owner can act on.

The tree makes diagnosis precise. If velocity is falling, the tree shows whether the cause is shrinking capacity, work stuck in review, rising rework, or estimates inflating over time. Each of those leads to a different intervention owned by a different part of the team.

There is no universal velocity benchmark, because the unit and estimation scale differ between teams. The useful benchmarks are about stability and predictability rather than the absolute number. A team whose velocity stays within a tight band is far more valuable for planning than one with a higher but erratic average.

A practical benchmark is the ratio of completed work to committed work. A team that consistently finishes 90 to 110 percent of what it commits has a realistic plan. A team finishing well under 80 percent is over-committing, which produces carry-over and the illusion of falling velocity. Pairing velocity with deployment frequency gives a fuller picture, since high point completion that never reaches production is not real delivery.

Improving velocity sustainably means removing the things that stop finished work from being counted, not pushing the team to estimate more aggressively. The fastest gains usually come from flow, not from raw effort.

The metric tree approach starts by finding the branch with the largest gap between current and achievable performance. If review wait time dominates, fixing the review queue will move velocity more than any change to estimation. If rework is the drain, tightening acceptance criteria matters most.

KPI Tree lets you model velocity this way by connecting each branch to the part of the team that owns it. The delivery lead owns capacity and work-in-progress limits. Reviewers own queue turnaround. Engineering owns rework and definition of done. With RACI ownership on every node, a falling velocity points to a named owner rather than a vague team-wide concern, and the accountable owner is notified when the number moves so the response starts before the next planning session.

1. 1

   Comparing velocity across teams

   Velocity is tied to one team and one estimation scale. Ranking teams by velocity rewards point inflation and punishes honest sizing. Compare each team only against its own history.

2. 2

   Treating velocity as a productivity target

   The moment velocity becomes a goal to maximise, estimates inflate to hit it. Velocity is a forecasting input, and turning it into a performance score destroys the honesty that makes it useful.

3. 3

   Counting unfinished work

   Items still in review or carried over are not done. Counting them props up the number for one iteration and then collapses it the next, making the trend unreadable.

4. 4

   Ignoring capacity changes

   A velocity drop during a holiday week is not a process problem. Tracking velocity without tracking availability leads teams to chase fixes for changes that will reverse on their own.

5. 5

   Planning on a single sprint

   One iteration is too noisy to forecast against. Use a rolling average of recent iterations so a single fast or slow sprint does not distort the plan.