Sprint Velocity

Once a team has worked in Sprints for a while, it starts to learn how much it can realistically finish in each one. Sprint velocity captures that knowledge as a number. At the end of each Sprint, the team adds up the estimates, usually in story points, of every item it completed to the Definition of Done. Over several Sprints, the average and range of those numbers become a guide for planning: how much to take into the next Sprint and roughly how many Sprints a set of work might need. Velocity is a planning tool for the team, built from the team's own history. It is most useful once a team has worked together for several Sprints and its estimates have settled.

Velocity has been part of agile practice since Extreme Programming and early Scrum, and it is one of the first metrics agile tools show. It is also one of the most misused. Because it is a simple number that can rise or fall, managers are tempted to compare teams by velocity or set targets to increase it, which encourages teams to inflate estimates rather than deliver more. For Scrum teams, product owners and delivery managers, understanding what velocity measures, and what it does not, is essential to using it well.

Definition of Sprint Velocity

Sprint velocity is the sum of the estimates of all backlog items completed to the Definition of Done in a single Sprint, tracked over time so that a team's average and range of completed work can inform Sprint Planning and release forecasting.

It is usually measured in story points, informs Sprint Planning and is one of several agile metrics, alongside flow measures such as throughput.

How Velocity Is Calculated

At the end of a Sprint, add up the points of all items that meet the Definition of Done. Partly finished items count for nothing until they are done.

Track the result for each Sprint, and look at the average and range over the last three to six Sprints.

Use the range rather than a single number when planning and forecasting, since velocity naturally varies from Sprint to Sprint. New teams usually need three to five Sprints before their velocity is stable enough to rely on.

Velocity vs Capacity and Throughput

Capacity is the time a team has available in a Sprint, accounting for holidays and other commitments. It changes from Sprint to Sprint.

Velocity is what the team actually completed. Teams often adjust expected velocity for known changes in capacity, such as a week of holidays.

Throughput is the count of items completed, regardless of size. Some teams find it forecasts as well as velocity with less estimating effort.

Importance of Sprint Velocity in Delivery and Engineering Operations

Velocity supports realistic planning. Teams that plan based on what they have actually completed are less likely to overcommit.

It enables forecasting. Dividing the remaining backlog by the velocity range gives a range of Sprints needed to finish.

It also signals change. A sudden drop in velocity can point to new problems, such as technical debt, unclear requirements or team changes, worth discussing in a retrospective. A steady velocity range is itself a sign of a healthy team, since it shows the team can plan and deliver consistently.

Sprint Velocity and Financial Management

Combining velocity forecasts with the team's cost per Sprint gives a rough estimate of the cost of finishing a set of work.

Velocity cannot be compared across teams, so it should not be used to judge which team gives better value for money.

Setting velocity targets tends to inflate estimates without increasing delivered value, which makes cost forecasts less reliable.

Forecasts based on velocity ranges help finance plan for a realistic range of outcomes rather than a single date.

Common Challenges

Comparing velocity between teams is meaningless, because each team's points scale is different.

Pushing teams to increase velocity leads to estimate inflation, where the same work is given more points over time.

Counting partly finished work or work that does not meet the Definition of Done makes velocity look better than reality. Changes in team membership reset velocity, since new members bring different skills and the team's estimates shift.