Velocity
veh-LOSS-ih-tee
The amount of work a team completes per sprint, measured in story points or similar units.
Velocity is the measure of how much work a team completes per sprint, typically measured in story points. If a team completes 40 story points in a two-week sprint, their velocity is 40. Over time, velocity stabilizes and becomes a useful planning tool.
Velocity is for planning, not performance evaluation. A team with velocity 40 is not "better" than a team with velocity 25. Story points are relative estimates, and each team calibrates differently. Comparing velocity across teams is meaningless. Using velocity to pressure a team to "go faster" is counterproductive.
Stable velocity is the goal. A team that delivers 38-42 points per sprint for three months is predictable. A team that swings between 20 and 60 is not. Predictability lets product managers make realistic commitments about when features will ship.
Examples
A product manager forecasts a delivery date.
The feature requires an estimated 120 story points of work. The team's average velocity is 40 points per sprint (2-week sprints). The PM estimates 3 sprints (6 weeks) for completion, plus a 20% buffer for unknowns. They commit to 7-8 weeks.
Velocity drops after a team change.
A senior engineer leaves the team. Velocity drops from 45 to 30 for two sprints as the remaining team members absorb the departed engineer's domain knowledge. Velocity gradually recovers to 38 over the next three sprints. This is normal and expected.
A manager misuses velocity.
A VP asks why Team A's velocity is 50 while Team B's is 35. The engineering manager explains that Team A estimates aggressively (a task that Team B calls 3 points, Team A calls 5). The absolute numbers are meaningless. What matters is each team's trend relative to their own baseline.
In practice
Read more on the blog
Frequently asked questions
How long does it take for velocity to stabilize?
Typically 3-5 sprints after a team forms or changes composition. During this period, velocity fluctuates as the team calibrates their estimation and finds their rhythm. Do not make delivery commitments based on velocity until it has stabilized.
Should velocity always increase over time?
No. Stable velocity is the goal, not increasing velocity. A team that delivers consistently is more valuable than one that is pressured to accelerate. Velocity may decrease temporarily when taking on tech debt, onboarding new members, or working in unfamiliar parts of the codebase.
Related terms
A fixed time period (usually 1-2 weeks) in which a team commits to completing specific work.
A unit of measure for estimating the relative effort required to complete a work item in agile development.
The prioritized list of all planned work that a team has not yet started.
A software development methodology that delivers work in short iterations with continuous feedback and adaptation.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.