glossary · general
Velocity in agile product management
The sum of story points for fully completed user stories at the end of a sprint, averaged over 3-5 sprints to forecast future capacity.
Velocity is a capacity planning tool, not a performance metric. The moment an organization treats it as the latter, Goodhart’s Law kicks in: teams inflate estimates, slice stories thin, and the number rises while value delivered stays flat. If you know one thing about velocity before an interview, know that distinction.
What it is and how to calculate it
Velocity is the sum of story points attached to user stories your team fully completes in a sprint. Partial work counts zero. A story in code review at sprint close is zero. A story that shipped but did not meet the Definition of Done is zero. The rule is strict because a fuzzy rule produces a meaningless number.
To get a usable planning figure, average across 3-5 sprints of stable team composition. A single sprint is noise. Three to five sprints show a pattern, though you should treat the result as a range, not a fixed constant. A team averaging 32 points per sprint is best planned at 28-36, not pinned at 32.
Why it exists and what it is actually good for
Velocity answers two PM questions well:
- Capacity planning: given a backlog of estimated work, roughly how many sprints will this take?
- Stakeholder expectation-setting: “based on current velocity, feature X lands mid-Q3, not end-of-Q2” is a concrete answer that prevents the vague promises that erode trust.
It is also a quiet team health indicator. Consistent velocity (30 points per sprint, sprint after sprint) signals a stable team with good estimation practices. Erratic velocity (20 one sprint, 60 the next) signals estimation debt, unclear Definitions of Done, or scope instability. Neither is good or bad on its own; both are diagnostic prompts, not verdicts.
Where it breaks down
Goodhart’s Law applies directly. Once velocity is a management KPI, teams learn the game. Estimates drift up. Stories get sliced to fit a sprint boundary rather than reflect real user value. The metric rises; the value delivered does not. Allen Holub, a prominent agile consultant, has called velocity-as-KPI “the software version of Taylorism.” The framing resonates in interviews because it names the mechanism, not just the symptom.
Cross-team comparison is meaningless. Each team calibrates their own point scale. Forty points on one team is not forty points on another. Using velocity to compare teams is a category error and a reliable tell that someone does not understand what the number represents.
Individual tracking destroys collaboration. When developers are measured by personal velocity, they stop helping each other. The team number can rise while the team’s actual output and morale decline.
The Scrum Guide does not require it. Story points and velocity are community conventions, not canonical Scrum. Mike Cohn, who popularized story points, has published that he no longer recommends using them for sprint planning and prefers count-based flow instead. That should calibrate how tightly you hold the practice.
The 2026 problem: AI tooling inflates the number without inflating the value
In 2026, teams using AI coding tools (Cursor, GitHub Copilot, and similar workflows) regularly complete two to three times more story points per sprint than they did two years ago. The points go up. The underlying value delivered does not necessarily follow.
AI-assisted code can pass tests and ship fast while introducing hidden technical debt, architectural shortcuts, or features that work in demo conditions but fail at scale. A sprint that completes 90 story points via AI-assisted coding may be shipping more risk than a 35-point sprint did before those tools existed.
This is why pairing velocity with production quality metrics matters. DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recovery) connect throughput to what actually happens in production. A PM who reports velocity without a quality signal in 2026 is presenting half the picture. When you see a velocity spike on an AI-augmented team, the first question is not “great, what do we commit to next quarter?” It is “what quality signals accompany this?”
When velocity is meaningless and what to say
Velocity becomes unreliable in three situations: a new team that has not completed 3-5 sprints, a team that recently added or lost members, and a quarter dominated by major refactoring or AI tooling adoption. In each case, the credible move is to say so rather than present a stale average as a reliable forecast.
When a stakeholder asks “why is velocity down?”, the diagnostic conversation matters more than the number. Walk through the last five sprints: team changes, unplanned interruptions, a major refactor that produced no releasable increment, or an AI tooling transition that required rework. Velocity is a lagging indicator of team stability, not a leading indicator of anything.
“We are in a calibration period; here is our range from last quarter, but I would treat it as directional” is a credible answer to an executive. Presenting a flat number when you know it is unreliable erodes trust when the forecast misses.
What interviewers are testing
Senior interviewers use velocity questions to probe three things: do you know the difference between a planning input and a performance target; do you know what distorts the number (gaming, team instability, AI tooling); and can you name what complements or replaces it when it misleads?
strong
"Velocity is the count of story points your team fully completes in a sprint: nothing partial, nothing in-review. You average it over 3-5 sprints to get a stable planning number, then use that to answer 'how much can we fit in Q3?' It is a capacity planning tool, not a performance target. The moment you make it a target, Goodhart's Law kicks in: teams inflate estimates or slice stories thin, and the number rises while value delivered stays flat. I anchor on three things: velocity predicts capacity, it does not measure quality or value; never compare it across teams because point scales are not portable; and pair it with something that touches production reality, DORA metrics, cycle time, or outcome metrics, because high velocity on the wrong features is just fast failure. In 2026 with AI coding tools, I actively flag when a velocity spike may be a tooling artifact rather than a real capacity change."
weak
"Velocity is how fast your team goes. You want to increase it sprint over sprint." This fails for three reasons: it conflates speed with value, it treats velocity as a goal rather than a planning input, and it would incentivize exactly the behavior (gaming points) that makes velocity useless. A slightly better but still failing answer gives a pure definition with no awareness of limits. Interviewers at senior levels are testing whether you know when a metric misleads, not whether you can define it.
Connecting velocity to outcomes
High velocity on the wrong thing is zero value. With AI coding tools compressing the feasibility gap, teams can ship more story points than ever, but viability (does this earn money or solve a real problem?) and lovability (does it work for users in their actual context?) are untouched by throughput. The PM’s job is to ensure the backlog that velocity is flowing through is shaped by outcome evidence, not just volume of ideas. For the ceremonies that generate velocity data, see sprint. For tracking remaining work within a sprint, see burndown. For the broader delivery context, see agile.