Why can't I compare velocity between teams?

Because story points are calibrated locally. One team's 'medium' story might be another team's 'large.' The numbers are unit-less from a cross-team perspective. Compare flow metrics like cycle time or throughput if you must compare, not velocity.

What's a 'good' velocity?

There isn't one. A good velocity is stable, used honestly for forecasting, and not inflating over time. Whether the absolute number is 20 or 80 says nothing about productivity.

How many sprints of history do I need?

At least three to start a meaningful rolling average; six is comfortable. Less than three is a guess; more than six gives stale data too much weight.

Should we count partial completion?

No. Stories that don't meet Definition of Done at sprint end count zero. Partial credit corrupts the signal because teams learn to chase points rather than completions.

What if velocity drops suddenly?

Investigate. Common causes: technical debt requiring slow refactors, key team member leaving, organisational disruption, sprint goal misalignment. The drop is information; suppress it and you lose the signal.

Should velocity ever rise sharply?

Beware. A sudden rise often means estimates are inflating (point inflation) rather than productivity improving. Real productivity improvements are usually gradual. Audit a few completed stories' point values when velocity jumps.

How do I forecast a release with velocity?

Divide remaining backlog by recent average velocity, then express it as a range: best 10–20% above average, worst 10–20% below. For higher-rigour forecasts, run a Monte-Carlo over the last 6–10 sprints of velocity to produce a confidence curve.

Is velocity the same as throughput?

No. Throughput counts completed work items (regardless of size); velocity counts story points (size-weighted). Throughput is simpler and harder to game; many mature teams report both, or have moved to throughput-only.

Which calculators on PMMilestone.org apply to Velocity?

For Velocity, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.

What is a common misconception about Velocity?

That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.

Which related encyclopedia entries should I read alongside Velocity?

Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.

How does Dr. Hassan Eliwa's research treat Velocity?

Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Velocity is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.

How is Velocity defined on PMMilestone Research & Insights?

An agile team's empirical measure of how much work it completes per sprint — used to forecast capacity for upcoming sprints, not to compare or judge teams. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

Agile · Letter V

Velocity

An agile team's empirical measure of how much work it completes per sprint — used to forecast capacity for upcoming sprints, not to compare or judge teams.

By Dr. Hassan Eliwa, PhD · Founder of PMMilestone.org and PMMilestone.com · Updated 2026-06-23

Definition

Velocity is an agile team's empirical measure of how much work it completes in a sprint, usually counted in story points (or, in some teams, in completed items or ideal days). Its purpose is straightforward and limited: to forecast how much the same team is likely to complete in the next few sprints, given recent history. Despite that narrow purpose, velocity is one of the most misunderstood and misused metrics in agile.

How It Works

At the end of each sprint, the team sums the story points of stories that meet the Definition of Done. The team's velocity for that sprint is that sum. Over time the team takes a rolling average — typically the last 3 to 6 sprints — and uses it to forecast: "we typically deliver about 38 points per sprint, so we can plausibly plan around that for the next sprint." That is all velocity is. It is not a productivity score, a contract, or a target.

Real-World IT / Agile Example

A platform team I coached had stable velocity around 42 points per sprint. Mid-year, a director compared their velocity to another team's (29) and asked why one was "more productive." Both teams used story points, but they were calibrated independently — the 42-point team rated a typical story at twice what the 29-point team did. Once the director understood that, the comparison stopped. The team's velocity continued to do its real job: making the team's own forecasts more honest.

Real-World Construction Example

Construction doesn't use velocity by name, but it uses the concept constantly. Productivity rates (m³ of concrete per crew-day, m² of formwork per labour-hour) are construction's velocity — empirical, team-specific, used to forecast the next phase, not to compare crews across projects. The mistakes are the same too: when an executive compares productivity between sites with different conditions, the metric stops being useful and starts being damaging.

What Velocity Is Good For

Sprint planning: "We average 38; let's not commit to 52."
Release forecasting: "300 points of backlog ÷ 38 per sprint ≈ 8 sprints to release."
Detecting trend changes: a sustained drop usually signals technical debt, attrition, or a process problem.
Internal honesty: the team's own benchmark for what's realistic.

What Velocity Is Not Good For

Comparing teams. Story points are calibrated locally; cross-team comparison is meaningless.
Performance management. When velocity becomes a target, points inflate, the metric loses meaning, and the team loses trust.
Contract commitments. Velocity forecasts, doesn't promise.
Measuring value. A team can have great velocity delivering low-value work.

Project Controls Perspective

Controls teams that report on agile programmes treat velocity as a planning input, not a status output. We report forecast confidence (Monte-Carlo over recent velocities) and flow metrics (cycle time, throughput) for status; velocity feeds the forecast. Reporting velocity to executives as a productivity metric is one of the fastest ways to corrupt an otherwise healthy agile team — guard against it.

Common Mistakes

Velocity as target. "Get velocity to 60." Story points inflate within two sprints; the metric dies.
Cross-team comparison. "Team A delivers 50, Team B only 30." Story points aren't a standard unit.
Counting partial credit. Stories not Done at sprint end count zero, not half. Partial credit corrupts the signal.
Re-baselining after every reorg. Velocity is per-team; major team changes reset the rolling average — accept the reset rather than hiding it.
Reporting it to clients as a commitment. "We deliver 40 points per sprint" sounds confident and means nothing to a client.
Ignoring trend changes. A persistent 20% drop usually signals tech debt or burnout, not laziness. Investigate.

Expert Tips

Use the last 3–6 sprints, not all history. Team composition and codebase health change; old data lies.
Forecast a range, not a number. "8–11 sprints" is more honest than "9 sprints."
Re-estimate when work surprises. The point of estimates is to learn; don't anchor on early-team estimates forever.
Report flow metrics for status. Cycle time and throughput are richer than velocity for executive reporting.
Defend the team's calibration. Push back firmly when stakeholders try to weaponise velocity as a productivity score.

Key Takeaways

Velocity forecasts the same team's next sprints — nothing more.
It is not a productivity score, a target, or a cross-team comparable.
Forecast a range; report flow metrics for status.
The construction analogue (productivity rates) suffers from identical misuse.
Velocity-as-target is the single fastest way to ruin an agile team's signal.

Related Encyclopedia Entries

Agile Project Management — companion entry on a directly related concept.
Burn-Down Chart — companion entry on a directly related concept.
Kanban — companion entry on a directly related concept.
WIP Limits — companion entry on a directly related concept.
Sprint Retrospective — companion entry on a directly related concept.
Daily Stand-up — companion entry on a directly related concept.

Frequently Asked Questions

Why can't I compare velocity between teams?
Because story points are calibrated locally. One team's 'medium' story might be another team's 'large.' The numbers are unit-less from a cross-team perspective. Compare flow metrics like cycle time or throughput if you must compare, not velocity.
What's a 'good' velocity?
There isn't one. A good velocity is stable, used honestly for forecasting, and not inflating over time. Whether the absolute number is 20 or 80 says nothing about productivity.
How many sprints of history do I need?
At least three to start a meaningful rolling average; six is comfortable. Less than three is a guess; more than six gives stale data too much weight.
Should we count partial completion?
No. Stories that don't meet Definition of Done at sprint end count zero. Partial credit corrupts the signal because teams learn to chase points rather than completions.
What if velocity drops suddenly?
Investigate. Common causes: technical debt requiring slow refactors, key team member leaving, organisational disruption, sprint goal misalignment. The drop is information; suppress it and you lose the signal.
Should velocity ever rise sharply?
Beware. A sudden rise often means estimates are inflating (point inflation) rather than productivity improving. Real productivity improvements are usually gradual. Audit a few completed stories' point values when velocity jumps.
How do I forecast a release with velocity?
Divide remaining backlog by recent average velocity, then express it as a range: best 10–20% above average, worst 10–20% below. For higher-rigour forecasts, run a Monte-Carlo over the last 6–10 sprints of velocity to produce a confidence curve.
Is velocity the same as throughput?
No. Throughput counts completed work items (regardless of size); velocity counts story points (size-weighted). Throughput is simpler and harder to game; many mature teams report both, or have moved to throughput-only.
Which calculators on PMMilestone.org apply to Velocity?
For Velocity, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.
What is a common misconception about Velocity?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.
Which related encyclopedia entries should I read alongside Velocity?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.
How does Dr. Hassan Eliwa's research treat Velocity?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Velocity is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.
How is Velocity defined on PMMilestone Research & Insights?
An agile team's empirical measure of how much work it completes per sprint — used to forecast capacity for upcoming sprints, not to compare or judge teams. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

View the full FAQ page for Velocity →