Sprint velocity

Sprint velocity is the sum of the estimation units (usually story points) for all work items that a team completes to its definition of done within a single sprint. If a team completes stories estimated at 3, 5, 8, and 5 story points during a two-week sprint, the velocity for that sprint is 21 points.

Velocity is fundamentally a team-level planning metric. It answers the question "given our historical rate of completion, how much work should we commit to in the next sprint?" A team that has averaged 25 points over the last 6 sprints has a reasonable basis for committing to approximately 25 points in the next sprint, adjusted for known factors like holidays, team changes, or technical debt work.

The metric is deliberately simple. It does not account for the complexity of individual items, the quality of the work, or whether the completed work delivered value to users. It is a throughput measure: how many units of estimated work flow through the team per sprint. This simplicity is both its strength and its limitation.

Velocity stabilises over time as a team develops a consistent understanding of how it estimates work. New teams or teams that have recently changed composition will see significant sprint-to-sprint variation. After 6 to 8 sprints, most teams develop a stable average velocity that makes planning more reliable.

1. 1

   Count only completed work

   Only include work items that fully meet the team's definition of done at sprint end. Partially completed stories are not counted toward velocity. This prevents teams from inflating velocity by claiming credit for work that still needs finishing.

2. 2

   Use a rolling average

   Use the average velocity over the last 3 to 6 sprints rather than a single sprint's number. This smooths out natural variation from holidays, sick days, and sprint-to-sprint complexity differences. Some teams also track a range (lowest to highest recent velocity) for planning conversations.

3. 3

   Keep estimation scales consistent

   Velocity is only useful if estimation is consistent over time. If the team recalibrates its estimation scale (for example, deciding that what used to be a 5 is now a 3), historical velocity becomes unreliable. When recalibration happens, reset the rolling average.

4. 4

   Plan with velocity, not to velocity

   Use velocity as a guide for sprint planning, not a target. If the team's average velocity is 25, committing to 25 points gives a roughly 50% chance of completing everything. For higher confidence, commit to slightly less. For stretch goals, commit to slightly more.

Many teams find it useful to track both average velocity and the standard deviation of velocity over time. A team that averages 25 points with a standard deviation of 2 is much more predictable than a team that averages 25 with a standard deviation of 10. Reducing velocity variance is often more valuable than increasing average velocity, because it makes commitments more reliable.

Sprint velocity is the output of the team's capacity, focus, and process effectiveness. A metric tree breaks it down into the factors that determine how much work the team can complete.

This decomposition reveals why velocity changes sprint to sprint. A team member on holiday reduces available capacity. A production incident that consumes two days of the sprint reduces focus. A slow code review process creates blocked items that prevent stories from reaching done.

The tree also highlights the difference between capacity-driven and process-driven velocity changes. If velocity drops because team members are absent, the response is different from a velocity drop caused by increased rework. Capacity-driven changes are expected and temporary. Process-driven changes suggest systemic issues that need attention.

Tracking the contributing factors alongside velocity helps the team distinguish between "we committed to too much" and "something prevented us from completing what we committed to." This distinction is crucial for effective retrospectives and continuous improvement.

Sprint velocity has a complicated relationship with business outcomes. On its own, velocity says nothing about whether the right things are being built or whether completed work delivers value. A team with increasing velocity that builds features nobody uses is not helping the business.

Velocity is most valuable as an input to two business-critical activities: release planning and capacity allocation. For release planning, a stable velocity enables reliable forecasting of when a set of features will be delivered. Product managers can use the team's velocity and the estimated backlog to project delivery dates with reasonable confidence.

For capacity allocation, velocity trends signal whether a team has the capacity for additional commitments or is already at its sustainable limit. A declining velocity trend might indicate that technical debt is accumulating and the team needs time for remediation before taking on new features.

To connect velocity to business outcomes, pair it with metrics that measure value delivery: feature adoption rate, customer satisfaction score, and revenue impact of shipped features. This combination reveals whether the team is both productive (high velocity) and effective (high value delivery).

KPI Tree lets you model sprint velocity as a node within a broader team performance tree that connects capacity, focus, and process factors to the final velocity number. Each contributing factor becomes a child node with its own trend data, making it clear why velocity changes from sprint to sprint.

The tree can show the relationship between velocity and value delivery by connecting sprint velocity to downstream metrics like feature adoption, customer satisfaction, and defect rates. This prevents the common failure mode of optimising for velocity in isolation without checking whether the work delivers business value.

Ownership assignment ensures that each factor influencing velocity has a responsible party. When velocity drops unexpectedly, the tree shows whether the cause is a capacity reduction, a focus problem, or a process bottleneck, enabling targeted action rather than a blanket "work harder" response.