Learning Objectives
By the end of this lesson you will be able to:
- Explain what velocity measures and what it doesn't
- Identify the three most common velocity inflation patterns
- Describe what "Done" needs to mean for velocity to be useful
- Apply at least two techniques to keep velocity honest over time
What Velocity Is (And Isn't)
Velocity is the average number of Story Points a team completes per sprint. Simple. But here's the trap: the moment velocity becomes a target, it stops being a measurement and becomes a game.
A team that consistently closes 40 points is not "faster" than a team that closes 20 points. Story Points are team-relative — they mean nothing across teams. Even within a team, velocity is only useful when the definition of "Done" is stable and the team is stable.
Velocity measures throughput — how much work actually crossed the finish line. It does not measure:
- Quality of what was delivered
- Whether the right things were built
- How hard the team worked
- Future capacity (directly)
The Three Inflation Patterns
Pattern 1: Story Point Creep Teams gradually inflate estimates over time — not consciously, but because the pain of under-estimation in past sprints creates risk aversion. An old 5 becomes today's 8. When this happens, velocity rises without the team actually doing more work.
Detection: Track average story size over time. If it's drifting upward without explicit re-calibration, inflation is likely.
Pattern 2: Partial Credit Teams count stories "almost done" as done. A story at 90% completion carries 100% of the risk of a story at 0% completion — there is no such thing as 90% done in Scrum.
Detection: If velocity spikes at the end of a sprint but the sprint goal is consistently missed, partial credit is happening.
Pattern 3: Scope-Slimming Under pressure, teams silently drop acceptance criteria to get a story to "Done" by end of sprint. The ticket closes; the feature doesn't work as intended.
Detection: Count defects found in the sprint after each release. A rising defect rate often signals scope-slimming.
The "Done" Foundation
Velocity means nothing without a shared, stable Definition of Done (DoD). The DoD should be:
- Written and visible — not assumed
- Applied consistently — every story, every sprint
- Owned by the team — not imposed by management
- Versioned — if it changes, old velocity numbers aren't comparable
A good DoD for a typical software team includes: code reviewed, unit tests written, acceptance criteria verified, deployed to staging, no known blocking defects.
Pro Tip: If your team has never written its DoD down, stop here and do it. Twenty minutes in a retrospective can save months of inflation.
Using Velocity Honestly
Use velocity for:
- Forecasting: "At our current rate of 35 points/sprint, we can complete the 175-point backlog in ~5 sprints."
- Trend analysis: Is velocity stable, growing, or declining? Each tells a different story.
- Capacity planning: When team composition changes, expect velocity to reset.
Do NOT use velocity for:
- Comparing teams
- Measuring individual performance
- Setting performance targets ("you must hit 40 points next sprint")
- Justifying overtime
Pro Tip: If management is using your velocity as a productivity target, raise it in the next retrospective. Velocity under pressure always inflates — and then the number loses all meaning.
Summary
Velocity is a useful planning tool only when it measures actual completion against a consistent Definition of Done. The moment it becomes a target, teams find ways to hit it without doing more real work. Your job is to keep the measurement honest — which means protecting the DoD, refusing partial credit, and not inflating estimates to feel safe.