Velocity Tracking

What it is

Velocity is the sum of story points completed (to the team's Definition of Done) during a single sprint. It is the simplest and most widely used forecasting signal in agile, but it only becomes meaningful when tracked over multiple sprints. A single sprint's velocity is noise; three to six sprints of velocity begin to reveal a stable trend.

Velocity is a planning tool, not a performance metric. It tells the team how much work they can realistically take into the next sprint. It does not tell management which team is "better," which developer is "faster," or whether the team is "improving" in any absolute sense. Treating velocity as a Key Performance Indicator (KPI) destroys its usefulness because teams will game the number rather than improve the work.

Comparing velocities between teams is meaningless. Team A's 40 points and Team B's 25 points say nothing about relative productivity. Each team uses its own baseline stories, its own definition of done, and its own estimation culture. Velocity is a local currency, not a universal exchange rate.

For reliable forecasting, teams should use a rolling average over the last 3–6 sprints and express capacity as a range rather than a single number. If the last five sprints produced 32, 28, 35, 30, and 31 points, the team's capacity for the next sprint is roughly 28–35 points. Promising exactly 31 is pretending the future is more predictable than it is.

When to use it

Velocity should be reviewed every sprint, at minimum during the following events:

• Sprint Planning: The team uses recent velocity to decide how many stories to pull into the Sprint Backlog. This is the primary use case.
• Sprint Retrospective: The team examines whether the sprint's velocity was inside or outside the expected range, and discusses what caused variance.
• Release Planning: Stakeholders use the velocity range to forecast when a set of features will be ready, or how much scope can fit a fixed date.
• Backlog Refinement: If velocity is trending downward, the team may need to investigate whether estimates are inflating or capacity is shrinking.

Key concepts

Sprint Velocity

The raw number of story points completed in one sprint. Calculated by summing the point values of all Product Backlog items that met the Definition of Done before sprint end. Partially completed items count as zero. This strict rule prevents the illusion of progress.

Average Velocity

The arithmetic mean of completed points over a defined window, typically the last three to six sprints. More sprints smooth out outliers but may include old data that no longer reflects the team's current reality. Fewer sprints are more responsive but noisier.

Velocity Range

Instead of communicating a single average, express capacity as a range from the lowest to the highest recent velocity. If the last five sprints were 28, 32, 35, 30, and 31, the range is 28–35. This is the most honest way to communicate capacity to stakeholders who want certainty.

Committed vs Completed

Committed points are what the team planned to do. Completed points are what actually got done. Tracking both on the same chart reveals the team's forecasting accuracy. A consistent gap between committed and completed suggests overcommitment or interference during the sprint.

Capacity Adjustment

Velocity is adjusted for known changes in team capacity. If two developers are on leave next sprint, the team may reduce their expected velocity proportionally. This adjustment is separate from the baseline velocity trend; it is a situational correction.

Rolling average (Sprints 12–16): 31.2 points.
Velocity range: 28–35 points.
Forecast for Sprint 17: "We expect to complete between 28 and 35 points, trending around 31."

Common pitfalls

• Using velocity as a KPI: When management ranks teams by velocity or sets velocity targets, teams inflate estimates, split stories unnecessarily, or claim "done" before quality is met. Velocity becomes a fiction.
• Changing points after the sprint: Re-estimating a story because it took longer than expected corrupts the velocity signal. The original estimate reflects the team's understanding at planning time; the variance is data, not an error.
• Ignoring the range: Stakeholders and even Scrum Masters often quote the average as if it were a guarantee. "Our velocity is 31" is less useful than "our velocity range is 28–35." The range protects against overcommitment.
• Not accounting for team changes: When a team gains or loses members, velocity will shift. Comparing pre-change and post-change velocity as if they were the same metric is misleading. Reset the baseline after significant team changes.
• Letting velocity drive behaviour: Teams under pressure to "hit velocity" will cut testing, skip refactoring, or push incomplete work to the next sprint. Velocity goes up; quality and sustainability go down.

NZ context

New Zealand clients — whether in government, enterprise, or startup sectors — frequently ask the question: "When will it be done?" Velocity provides an empirical, transparent forecasting mechanism that answers this without resorting to fictitious deadline promises.

In NZ's often flat, trust-based organisational cultures, velocity charts shared openly with stakeholders build confidence. In more traditional environments where time-tracking and billing are tightly coupled, velocity can be harder to introduce. The key is educating stakeholders that velocity gives them more reliable forecasting than hourly estimates, not less.

NZ teams often include a mix of permanent staff and contractors, with contractors sometimes billing by time. In these cases, velocity is still useful for internal planning even if external billing uses hours. The two systems can coexist: hours for invoices, points for forecasting.

Public holidays (Waitangi Day, Anzac Day, regional anniversary days, and the Christmas–New Year shutdown) create predictable dips in NZ velocity. Teams should normalise their velocity ranges around these known events rather than treating them as performance failures.

Career level guidance

Junior

• Understand that your team's velocity is a planning aid, not a scoreboard. Don't feel pressured to "help velocity" by cutting corners on testing or documentation.
• Track your own completion rate informally: how many of your committed tasks finish within the sprint? This helps you calibrate your own capacity over time.
• Ask questions if the team consistently overcommits or undercommits. New eyes often spot patterns the team has normalised.
• Learn the difference between "story done" and "sprint done." Your work contributes to the team's velocity only when it meets the Definition of Done.

Senior

• Own the velocity data. Maintain the chart, calculate the rolling average, and present the range at sprint planning. Don't leave this to the Scrum Master by default.
• Protect the team from velocity-as-KPI pressure. When stakeholders ask for comparisons, explain why Team A's 40 and Team B's 25 are not comparable.
• Investigate velocity outliers. A sudden spike or drop is a signal, not a number. Dig into causes: team changes, scope pressure, technical debt, or external dependencies.
• Use velocity trends to advocate for sustainable pace. If velocity is climbing but defect rates are too, make the connection visible to stakeholders.

Test Lead

• Ensure testing work is reflected in velocity, not hidden. If the team consistently completes stories but testing spills over, velocity is overstating real throughput.
• Track "escaped defects per sprint" alongside velocity. A high velocity with rising defects is a warning sign that quality is being sacrificed for speed.
• Advocate for including test automation, regression suites, and exploratory testing in story points. If these are excluded, velocity will drift upward while quality coverage erodes.
• Use the velocity range to forecast when quality debt is accumulating. If the team is completing fewer points because they are fixing old bugs, that should be visible in the trend.