Team velocity analysis

Team velocity analysis is the study of how much work a team finishes each iteration and what the pattern in that figure reveals about delivery. A single sprint velocity is just a count: a team that completes 32 story points of accepted work in a two-week sprint has a velocity of 32. The analysis is what you do with a run of those counts, using the average to forecast, the variability to gauge predictability, and the decomposition to explain changes.

Velocity is a capacity-and-throughput measure, not a productivity score. It tells you roughly how much a specific team, with its current estimation scale, tends to complete in a sprint. That makes it genuinely useful for forecasting. If a team averages 30 points per sprint and a release contains 120 points of remaining work, four sprints is a reasonable first estimate. It also makes velocity easy to misuse, because points are relative to one team and comparing them between teams is meaningless.

The value of the analysis is in the trend and the stability, not the absolute number. A team holding a steady 28 to 32 points sprint after sprint is more useful to plan around than one that swings between 15 and 45, even if the second team has a higher average. Stable velocity makes commitments credible. Volatile velocity is a signal that something upstream, in scope, dependencies, or interruptions, is out of control. Reading velocity alongside cycle time gives a fuller picture of flow.

The core calculation is an average of completed work across recent sprints, but a useful analysis needs a few more inputs than the headline number. Define what counts as completed, choose a sensible window, and track the spread so you understand how reliable the average is.

1. 1

   Completed work per sprint

   Only work that fully meets the definition of done and is accepted counts. Partially finished items carried into the next sprint should not be credited, otherwise velocity flatters the team and forecasts drift.

2. 2

   Sprint window

   The number of recent sprints you average over, commonly the last three to six. A short window reacts quickly to change but is noisy; a longer window is smoother but slower to reflect a real shift in capacity.

3. 3

   Average velocity

   The headline figure: total completed work across the window divided by the number of sprints. This is the number you use as the starting point for release forecasting.

4. 4

   Velocity range and variability

   The spread between the lowest and highest recent sprint, or the standard deviation. A tight range means forecasts can be confident; a wide range means you should plan with a buffer and investigate the cause.

A worked example shows how the pieces fit. Over the last five sprints a team completes 26, 31, 29, 33, and 28 accepted points. The total is 147, so average velocity is 147 divided by 5, or roughly 29 points. The range is 26 to 33, a spread of just seven points, which means the average is reliable. To forecast a release of 90 remaining points, divide by 29 to get about three sprints, and because the range is tight you can commit to that estimate with reasonable confidence.

A metric tree turns velocity from a number you report into a number you can explain. When velocity drops, the tree shows whether the team had fewer available hours, spent more of those hours on unplanned work, or simply moved less work to done because of blockers and rework.

The first level splits velocity into the inputs that produce it: available capacity, the share of that capacity spent on planned sprint work, and the rate at which started work actually reaches done. Each branch then decomposes into operational drivers a team controls. Available capacity decomposes into team size, leave, and time lost to meetings. Planned-work share decomposes into unplanned interruptions, support load, and bug fixing pulled into the sprint. Completion rate decomposes into blockers, dependencies, and rework from unclear requirements.

This structure makes a velocity dip diagnosable. A team that drops from 30 to 20 points is not necessarily slower; the tree might show that two people were on leave and a production incident consumed a third of the sprint. The decomposition separates a genuine capacity change from a temporary disruption and points each cause at the person who can address it.

There is no universal velocity benchmark, because story points are relative to a single team and its estimation scale. A velocity of 40 says nothing on its own. What can be benchmarked is the stability and maturity of the velocity pattern, which is the same across teams regardless of their point scale. The ranges below describe patterns rather than point totals.

The useful target is predictability, not a rising line. A team whose velocity climbs every sprint is often inflating estimates or burning down a one-off backlog, neither of which forecasts the future well. The healthiest signal is a steady average with a narrow range, because that is what lets you make commitments and keep them.

Improving velocity analysis means making throughput more predictable and removing the friction that wastes capacity, not pushing the point count up. Work the branch of the tree with the biggest recoverable loss, which is usually interruptions or blockers rather than raw capacity.

The metric tree approach starts by isolating which branch is costing the team the most predictable throughput, then handing that branch to the person who can change it. KPI Tree lets you connect each branch to its owner with RACI, so the interruption branch sits with whoever controls the support intake, the dependency branch with the relevant leads, and the estimation branch with the team running refinement. When velocity moves outside its expected range, the change is pushed to the accountable owner, and the verified impact loop confirms whether the process change actually stabilised the number rather than just coinciding with a quiet sprint.

1. 1

   Comparing velocity between teams

   Story points are calibrated to a single team, so one team velocity of 40 and another of 20 says nothing about relative productivity. Comparing them creates pressure to inflate estimates and destroys the metric value as a planning aid.

2. 2

   Setting velocity as a target

   The moment velocity becomes a goal, estimates inflate to meet it and the number rises without any more real work being done. Keep velocity as a forecasting input and judge delivery on working outcomes.

3. 3

   Crediting unfinished work

   Counting partially complete items or work that did not meet the definition of done flatters velocity and corrupts forecasts. Only fully accepted work should count toward the sprint figure.

4. 4

   Ignoring the variability

   Reporting only the average hides whether it can be trusted. A 30-point average from a team swinging between 15 and 45 is far less plannable than a steady 30, and the analysis must show the range, not just the mean.

5. 5

   Tracking velocity without decomposing it

   A bare velocity number cannot tell you why a sprint underdelivered. Without splitting it into capacity, interruptions, and completion, you cannot separate a genuine slowdown from a week of leave and a production incident.