Why is team velocity a forecasting input rather than a productivity metric?
answer
- A forecasting input, not a score
- Only work meeting the Definition of Done
- Read a range across several Sprints
- The scale is local to one team
- Target it and it inflates
basics
~20 sVelocity counts the story points one team brought to its Definition of Done per Sprint, averaged over several Sprints. Its only job is forecasting what that team can take on next. The scale is local, so velocity compares nothing across teams — and it inflates the moment it becomes a target.
solid answer
~50 s**Velocity** is the total story-point size of the items a single team finished to its **Definition of Done** in one Sprint, read across the last three to five Sprints as a range rather than a number. Partially finished work contributes zero; the Sprint boundary is the clock. It answers two forecasting questions — roughly how much to select next Sprint, and roughly how many Sprints a body of sized work needs. It is not productivity for three reasons. The unit is a local scale, so cross-team comparison adds different units. The people measured are the same people who set the sizes, so a velocity target inflates sizes rather than output. And size is indifferent to value: a team can raise velocity by delivering more of what nobody wanted. Treat it as an input the team owns, never a score someone else reads.
go deeper
Be ready to state the definition cleanly: story points completed to the Definition of Done, by one team, in one Sprint. Say that unfinished work counts as zero and that no individual has a velocity.
Explain the mechanics of using it: three to five Sprints read as a range, applied to the coming Sprint's selection and to a rough span of Sprints for a larger body of work.
Show the diagnosis. When a velocity moves sharply, be able to walk through the likely causes in order — scale drift, work counted before it is Done, double-counted carry-over, an expanded Definition of Done — before reaching for any conclusion about the team.
Own the conversation with leadership. Explain why a velocity target corrupts the measure that produced it, and be ready to offer a forecast that survives the scrutiny a comparison dashboard was reaching for.
## What velocity counts, exactly **Velocity** is the total story-point size of the items one Scrum Team brought to its **Definition of Done** inside one Sprint. Three parts of that sentence carry the weight: - **One team.** Velocity belongs to a team, never to a person and never to a department. There is no such thing as an individual's velocity. - **Brought to Done.** An item that is nearly finished contributes nothing at all. The Definition of Done is the test, and the Sprint boundary is the clock. - **In one Sprint.** A single Sprint's figure is noise. What is usable is the last three to five Sprints, and the honest way to quote it is as a range — 'we finish between 27 and 38' — rather than a mean presented as a fact. The measure is deliberately crude. It does not know whether the work was valuable, whether it was hard, or whether the team enjoyed it. It knows how much estimated size crossed the finish line, which is exactly enough for the job it has. ## The two jobs velocity actually has 1. **How much should we select for the coming Sprint?** The range gives a starting bracket, adjusted for the days the team actually has, and then discarded once the Sprint Goal shapes what is genuinely worth selecting. It informs the choice; it does not make it. 2. **Roughly how many Sprints does this body of work need?** Divide the outstanding sized work by the low and the high end of the range and quote the resulting span. Two Sprints of difference between the ends is not a defect in the method — it is the honest width of what the team knows. Neither job requires a single number, and quoting a single number is where most of the misuse begins. ## Why it fails as a productivity metric | What a productivity measure needs | What velocity actually is | |---|---| | A unit comparable across everything measured | A scale each team anchors independently | | Immunity to the measured party setting the unit | Sized by the same Developers whose total is read | | A link to value delivered | A count of estimated size, indifferent to value | | A stable denominator over time | Composition, Definition of Done and work type all move | The second row is the fatal one. When a number becomes a target, it stops measuring what it measured, and here the people being scored are the people holding the ruler. Velocity can be raised without delivering anything more, along three well-worn routes: sizing items more generously than last quarter; counting items that have not truly met the Definition of Done; and letting a carried-over item contribute in more than one Sprint. None of these require dishonesty — a team under pressure drifts into all three without ever deciding to. The fourth row explains why even an honest velocity is fragile as a score. The denominators move constantly, so a fall can mean a departure, a holiday period, a tightened Definition of Done or a Sprint eaten by production support, none of which say anything about how hard anyone worked. ## Reading a velocity honestly 1. **Use three to five Sprints**, and quote the low and high, not the average alone. 2. **Count only what met the Definition of Done**, with no partial credit and no double counting across Sprints. 3. **Recompute after any composition change** rather than carrying the old figure forward. 4. **Investigate step changes instead of celebrating them.** A figure that doubles in two Sprints with the same people is almost always a scale change, not a capability change. 5. **Never divide by headcount**, and never publish it beside another team's. ## What legitimately invalidates a velocity - People joining or leaving, including a long absence, since the history describes a team that no longer exists in that form. - A re-anchored size scale, deliberate or drifted — the old and new numbers are no longer the same currency. - An expanded Definition of Done, which makes every item genuinely bigger than the ones in the history. - A Sprint dominated by unplanned support or a long external dependency, which should be treated as an outlier and named as one rather than quietly averaged in. The useful summary for an interview is this: velocity is a team's own instrument for planning its next Sprint and sketching how far out a body of work sits. The moment it leaves the team and becomes a number someone else compares, it stops being an instrument and starts being a target — and a targeted velocity is the one kind of velocity that can no longer forecast anything.
- How many Sprints of history do you want before you trust a velocity, and what invalidates it?Three to five Sprints gives a usable range rather than a single number, and the range is what you should quote. It stops being usable when what it describes changes: people joining or leaving, a re-anchored size scale, a Definition of Done that expanded, or a Sprint dominated by unplanned support. After any of those, treat the old figure as history and rebuild from the Sprints that follow.
- A team's velocity doubles over two Sprints with no change in the people. What do you look at first?The scale, not the people. Check whether items are being sized more generously than they were, whether work is being counted before it truly meets the Definition of Done, and whether a carried-over item contributed in two Sprints. Genuine step changes do happen when an impediment is removed, but the team can always name the impediment. If nobody can name it, the ruler moved.
saying these in an interview costs you the question
- Reports a velocity for each individual developer
- Sets a velocity target and expects it to climb each Sprint
- Ranks two teams by comparing their velocities
- Counts partially finished items toward the Sprint's velocity
- Treats one Sprint's figure as the team's velocity
- Reads a falling velocity as proof the team is slowing down