Velocity Tracking
The measurement of how many story points a team completes per sprint, used for capacity planning and forecasting rather than performance evaluation.
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.
| Sprint | Committed | Completed | Notes |
|---|---|---|---|
| Sprint 12 | 34 | 28 | Production incident consumed 2 days |
| Sprint 13 | 30 | 32 | Smooth sprint; some carry-over tasks were easier than expected |
| Sprint 14 | 35 | 35 | On target; good refinement and stable team |
| Sprint 15 | 36 | 30 | Mid-sprint scope change from stakeholder |
| Sprint 16 | 32 | 31 | One developer on leave; adjusted capacity |
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.
Industry Reality
- Most teams track velocity informally in a spreadsheet or a single Jira board widget rather than a rigorously maintained chart. The discipline to maintain and act on rolling averages is common in certified Scrum environments but rare in hybrid or informal agile shops.
- Velocity inflation is widespread. Under deadline pressure, teams re-point stories upward at the end of the sprint, accept "90% done" stories as complete, or carry stories across sprints and count them twice. Senior practitioners recognise the smell immediately when velocity climbs while quality declines.
- Management misuse is the norm, not the exception. Despite Agile orthodoxy, velocity comparisons across teams appear in quarterly reviews and performance conversations at many NZ organisations. QAs who understand why this is misleading are more influential when they can explain the alternative clearly.
- Mature teams eventually drop story points entirely and switch to throughput metrics — counting completed items per sprint regardless of size. This simplifies tracking and removes the gaming incentive, but requires backlogs of consistently small stories.
- In NZ's consulting and government project environments, velocity data often has to be translated into Gantt-style date commitments for clients and ministers. Skilled practitioners build a conversion bridge: velocity range → epic completion forecast → milestone date range. This dual language fluency is genuinely valued.
Context guide
How the right level of Velocity Tracking effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Benefits NZ, Revenue NZ, or TransitNZ delivery team with fixed-date OIA or legislative commitments | Essential | Public sector commitments to ministers and select committees demand empirical forecasting. Velocity range translated to sprint counts gives stakeholders an honest window rather than a politically convenient single date. |
| Multi-team programme (e.g. HealthNZ HealthNZ platform modernisation) coordinating releases across squads | Essential | Cross-team release planning requires each squad to produce a velocity range so the programme manager can identify which team is the bottleneck and negotiate scope before the integration sprint. |
| Harbour Bank or Pacific Bank feature team operating inside a quarterly planning cycle (SAFe or equivalent) | High | PI planning commitments are built from team velocity. A team without a reliable velocity range will either over-promise and miss PI objectives, or under-promise and waste capacity that programme leadership has already allocated. |
| Small NZ startup (5–12 people) with informal agile and no external stakeholders demanding forecasts | Medium | Useful for internal sprint planning discipline, but full chart maintenance is overhead. A lightweight version — count completed stories, note capacity changes — gives most of the benefit without the estimation ceremony. |
| Pacific Air or TeleNZ platform team that has fully adopted Kanban flow metrics (cycle time, throughput) | Low | When the team has a backlog of consistently small, similarly sized items and uses Monte Carlo forecasting, story-point velocity adds estimation overhead without improving forecast accuracy. Throughput is more reliable here. |
| NZ Police or FamiliesNZ project team using a mix of permanent staff and short-term contractors billing by the hour | Medium | Run velocity for internal sprint planning while keeping time-billing separate for procurement compliance. The two systems coexist — hours for invoices, points for forecasting — but require clear team education to avoid conflation. |
Trade-offs
What you gain and what you give up when you adopt Velocity Tracking.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Gives stakeholders a calibrated forecast range rather than a gut-feel date, which is especially valuable when communicating to NZ government select committees or programme boards. | Accuracy depends entirely on consistent, honest estimation. When teams are under pressure to "hit velocity," point inflation corrupts the signal within two or three sprints, making the metric worse than useless. | The team has adopted story-size slicing discipline and all items are consistently small. Use throughput (items per sprint) instead — it removes the estimation variable entirely. |
| Surfaces capacity problems early. A sustained drop in velocity after a team member departs or after a wave of production incidents is immediately visible, prompting a resourcing conversation before the programme milestone is affected. | Velocity is a lagging indicator. By the time a trend is statistically meaningful (three or more sprints), the underlying problem — technical debt, team friction, unclear requirements — has already been slowing the team for weeks. | You need leading indicators of risk. Combine velocity with sprint predictability (% of committed items completed) and defect escape rate to catch problems earlier. |
| Builds a shared planning language between the team and stakeholders. A product owner who understands velocity range can make informed scope trade-offs at sprint planning rather than demanding arbitrary date commitments. | Velocity is meaningless across team boundaries. NZ organisations that compare velocities between squads — common in SAFe PI planning — create destructive competition and estimation arms races rather than genuine productivity insight. | Management wants cross-team comparison. Redirect to outcome metrics: features shipped per quarter, defects in production, customer satisfaction score. These are comparable across teams in a way velocity never can be. |
| Low tooling cost — a simple spreadsheet or a single Jira board widget is sufficient. Teams do not need expensive forecasting software to get 80% of the value from velocity data. | Story point estimation is itself a significant ceremony overhead. Planning Poker sessions, refinement debates, and re-estimation conversations consume time that could go into delivery — particularly on small NZ teams where everyone wears multiple roles. | Estimation overhead is hurting team morale or sprint rhythm. Try the #NoEstimates approach: track completed item count per sprint and use historical cycle time distribution to forecast delivery dates probabilistically. |
Enterprise reality
How velocity tracking changes at 200–300-developer scale in NZ
- Velocity data collection is automated rather than manually updated — Jira, Azure DevOps, or Atlassian Analytics pull sprint metrics automatically and feed programme-level dashboards. At TeleNZ or CloudBooks scale, no one is maintaining a spreadsheet; the tooling generates rolling averages, variance flags, and release forecasts without human intervention. The discipline shifts from data entry to interpreting what the tooling surfaces and knowing when to override it.
- Revenue NZ and Revenue NZ's Business Transformation programme — one of NZ's largest government technology projects — operates under Privacy Act 2020 and the Tax Administration Act 1994, which require auditable evidence of delivery against approved business cases. Velocity data does not satisfy these governance obligations on its own; it must be translated into milestone burn-up charts, linked to specific epics, and signed off by an assurance function before it counts as progress for a Select Committee update. Knowing how to bridge empirical agile metrics into formal governance artefacts is a senior practitioner skill at this scale.
- Cross-squad coordination across 10+ teams requires a structured aggregation layer — typically a programme board or Release Train Engineer role in SAFe. Individual team velocity ranges are combined into a programme-level capacity model for each Program Increment (PI), and any team whose velocity is below threshold triggers a dependency negotiation, not just a conversation. The teams that cause downstream risk are identified analytically, not by feel, which means velocity data quality directly determines how visible a team is to programme leadership.
- At enterprise scale, velocity gaming is structurally incentivised in ways that small teams rarely encounter — squads compete for funding, headcount, and priority status based on perceived delivery rate. Organisations like Harbour Bank and Coastal Bank that have gone through SAFe implementations report that without active controls (locked estimates, Definition of Done gates, independent QA sign-off), point inflation spreads laterally across squads within a single PI cycle. Mature enterprise programmes counter this by tracking escaped-defect rates, rework volume, and cycle time alongside velocity, and by explicitly separating "velocity for planning" from "velocity for reporting."
◆ What I would do
Professional judgment — when to adopt Velocity Tracking, when to adapt it, and what to watch for.
The bottom line: Velocity is only as honest as your Definition of Done is strict. Every shortcut taken to protect a number — re-pointing, partial acceptance, skipped regression — quietly transfers the cost to the next sprint, and eventually to your users.
Best Practices
- ✓ Express velocity as a range (e.g. 28–35 points) at every sprint planning session, never as a single promise. The range is the honest answer.
- ✓ Use a rolling window of 3–6 sprints and explicitly state which sprints are included, so stakeholders understand the sample size and can spot outliers.
- ✓ Log the reason for every major variance (production incident, team change, unplanned scope) in the velocity chart notes. The annotation history is as valuable as the number itself.
- ✓ Reset the velocity baseline after significant team composition changes — adding or losing a member shifts capacity enough that old data misleads more than it helps.
- ✓ Track committed vs. completed on the same chart to diagnose whether variance comes from planning inaccuracy or mid-sprint interference.
- ✓ Correlate velocity trends with defect escape rates and rework volume. A rising velocity with rising defects is a quality warning, not a success signal.
- ✓ Protect velocity from being used as a cross-team KPI. When asked to compare teams, redirect the conversation to outcome metrics (features shipped, defects in production, customer satisfaction).
- ✓ Account for NZ public holidays and the Christmas–New Year shutdown in advance. Adjust expected capacity for those sprints rather than treating the dip as underperformance.
Common Misconceptions
❌ Myth: A higher velocity means the team is more productive.
Reality: Velocity measures points completed against the team's own historical baseline — it is not an absolute measure of output. A team can inflate velocity by over-estimating stories, skipping quality checks, or carrying incomplete work. Comparing velocity to a previous sprint or another team without controlling for these factors tells you nothing useful about true productivity.
❌ Myth: Velocity should increase sprint over sprint as the team matures.
Reality: A stable velocity is a sign of a healthy, predictable team — not a stagnant one. Sustainable pace means staying within a consistent range. Velocity that climbs continuously often indicates estimate inflation or the accumulation of technical and quality debt that will eventually collapse throughput. Mature teams track whether their velocity range is stable, not whether the number is going up.
❌ Myth: Velocity is a commitment — if the team planned 32 points, they owe 32 points.
Reality: Velocity is a forecast input, not a contract. Sprint Planning uses velocity to select a realistic amount of work, but the sprint goal and the value delivered matter more than hitting a point total. Treating the velocity number as a commitment creates pressure to cut testing, ship incomplete stories, or re-point work after the fact — all of which corrupt the very signal that makes velocity useful.
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.
Why teams fail here
- Treating velocity as a KPI turns the metric into a target — teams inflate estimates or accept "nearly done" stories as complete to protect the number, eroding the very signal the metric is supposed to provide.
- Quoting a single average rather than a range gives stakeholders false precision and sets the team up for overcommitment when the next sprint falls at the low end of their actual capability.
- Ignoring team composition changes — not resetting the velocity baseline after adding or losing a member — makes the rolling average meaningless and leads to sprint planning that is chronically off-target.
- Failing to annotate variance causes means the velocity chart becomes a bare number line with no explanatory power — the next planner can't distinguish a holiday dip from a systemic capacity problem, so history stops teaching.
Key takeaway
Velocity done well is not a number you hit — it is a calibrated range you trust, built from honest data, annotated variances, and the discipline to never re-point a story after planning ends.
How this has changed
The field moved. Here is how Velocity Tracking evolved from its origins to current practice.
Velocity (story points per sprint) emerges as the primary planning metric for XP and Scrum teams. Simple concept: measure what the team actually delivers, use it to predict future delivery.
Mike Cohn formalises velocity-based release forecasting. Rolling average velocity is used to project when a backlog will be completed.
Velocity gaming emerges as a dysfunction — teams inflate estimates to appear more productive. The metric creates incentives that work against good engineering practices.
#NoEstimates research demonstrates that cycle time and throughput predict delivery more accurately than velocity, without story point estimation. The case for abandoning velocity grows.
Flow-based forecasting (Monte Carlo simulation using historical throughput) is gaining adoption as a replacement. Teams in transition run both — velocity for stakeholder communication, flow metrics for actual forecasting.
Self-Check
Click each question to reveal the answer.
Q: Your team's sprint velocity has been stable at 28–34 points for six sprints. Anzac Day falls mid-sprint and one developer is on leave the same week. How should you adjust your capacity commitment for that sprint?
A: Do not rely on the raw rolling average for this sprint. Calculate the available person-days for the sprint, determine what percentage of normal capacity you have, and scale your expected velocity range down proportionally. For example, if the team normally has 50 person-days per sprint but this sprint has 38, your adjusted range might be roughly 21–26 points. Log the reason in the velocity chart notes so the dip is not misread as a performance issue at the next review.
Q: You are a QA on an Benefits NZ benefits platform team. The product owner wants to commit to delivering the new payment-adjustment feature by a fixed date. Your velocity range is 28–35 points and the remaining backlog is 120 points. How do you use velocity to give an honest forecast?
A: Divide the remaining backlog by both ends of your velocity range to get a forecast window: 120 ÷ 35 = 3.4 sprints (optimistic), 120 ÷ 28 = 4.3 sprints (conservative). If your sprint is two weeks, the honest answer is "three to five sprints from now, meaning roughly six to ten weeks." Present the range to the product owner and note any assumptions — no scope changes, stable team, no holiday sprints. This is more reliable than any single-date promise and sets realistic stakeholder expectations on a high-compliance government system where late delivery has real citizen impact.
Q: What is the key difference between velocity tracking and throughput tracking, and when would a mature agile team prefer throughput?
A: Velocity tracks story points completed per sprint, which means the metric depends on consistent, accurate estimation — a practice that varies between teams and degrades over time as gaming pressure builds. Throughput tracks the number of completed items per sprint regardless of size, eliminating the estimation variable entirely. A mature team with a well-refined backlog of consistently small, similarly sized stories often switches to throughput because it removes the incentive to inflate points, is simpler to measure, and correlates more directly with value delivery. Velocity remains more useful when story sizes vary significantly and the team needs to communicate capacity in effort terms to stakeholders.
Q: A senior developer on your team says: "Our velocity has gone from 28 to 42 points over the last four sprints — the team is really improving." What is potentially wrong with this conclusion and how do you respond?
A: A rising velocity is not automatically a positive signal. The increase could reflect genuine improvement, but it could equally indicate estimate inflation (teams re-pointing stories larger to hit targets), acceptance of stories before they fully meet the Definition of Done, reduced testing rigour, or accumulation of technical debt that will slow future sprints. Ask whether defect escape rates, rework volume, and sprint retrospective tone have improved at the same rate as velocity. If velocity is climbing while defect rates or team morale are worsening, the number is misleading rather than encouraging. A stable, predictable velocity range is often a healthier sign than a rising one.
Senior engineer insight
Teams who use velocity well treat it as a diagnostic signal, not a target — they review variance causes every retrospective and carry that context forward into forecasting. The pattern that actually works: annotate every outlier sprint with a one-line reason (production incident, team change, holiday) so the data stays honest and stakeholders trust it over time. Predictability comes from that annotation discipline, not from any specific number.
The most common mistake: using the sprint average as a commitment rather than a range, then spending the last two days of the sprint doing triage to "hit the number" — which is exactly when testing gets cut.
From the field
A Wellington-based scrum team working on an Revenue NZ digital services platform tracked velocity for eight sprints and reported a stable average of 33 points — but the Scrum Master noticed that completed velocity was never below 31 and never above 35. When the team dug in during retrospective, they found that stories were being re-pointed upward at sprint end to avoid the appearance of under-delivery, a habit that had crept in quietly after one difficult sprint. Once the team agreed to lock estimates at planning and track "committed vs. completed" as two separate columns, the real range emerged: 24–38 points. That honest range led to a release forecast that slipped by three sprints from the original date — but the delivery actually happened within the revised window, which rebuilt trust with the product owner after months of missed commitments. The lesson: artificially smooth velocity destroys the forecasting signal it is meant to provide.