Glossary
Velocity estimates future sprint capacity based on historical story points completed. While useful for measurement, it fails as a commitment mechanism because it ignores work type variance and incentivizes gaming the metric. Reference class forecasting and cycle time tracking are more reliable.
I've shipped hundreds of estimates across three companies. My accuracy improved dramatically when I stopped relying on gut feel and started using historical data from our actual codebase.
Velocity estimation is the practice of predicting how much work a software development team can complete in a fixed period of time (usually a sprint). It's based on: historical velocity data and planned work.
Velocity = average story points (or tasks) completed per sprint.
Example: Team has completed 28, 32, 25, and 30 points in the last 4 sprints. Average velocity = 29 points per sprint. For the next sprint, estimate 29 points of capacity.
Velocity estimation enables roadmap planning. "We have 150 points of work planned for Q3. Our velocity is 30 points per sprint. That's 5 sprints = 10 weeks." Without velocity estimation, "when will we ship?" is a guess.
Velocity estimation also reveals efficiency trends. If velocity is declining (was 35, now 25), something's wrong. Increasing debt? Team changes? External blockers? Velocity trends surface these problems early.
1. Estimate work items. In planning, estimate: story points, tasks, or hours. Story points are relative (this is bigger than that). Hours are absolute.
2. Track completed work. At the end of each sprint, count: how many points/tasks/hours were actually completed?
3. Calculate velocity. Average completed work over 3-6 sprints. That's velocity. Using more sprints gives a better average (smooths outliers).
4. Use for planning. Next sprint, commit to work within expected velocity. "We plan 30 points, expecting to complete 30 based on history."
Points per sprint: Most common. Story points are relative units. "Completed 28 points." Useful for project estimation.
Tasks per sprint: Simpler but less useful. "Completed 15 tasks." Task size varies; hard to predict.
Hours per sprint: Absolute time. "Completed 120 hours of planned work." More precise but requires accurate estimation (hard).
Cycle time: Time from work start to completion. "Features took 3 weeks on average." Useful for understanding efficiency.
Lead time: Time from request to delivery. "Features took 6 weeks on average from request to ship." Useful for external communication.
Team composition: Adding/removing team members changes velocity. New member: velocity drops (ramp time). Departure: velocity drops (loss of capacity). Stability: velocity is more predictable.
Technical debt: Higher technical debt = lower velocity. If you're constantly fighting bugs and architectural problems, you ship less.
Process changes: Improving code review process, CI/CD, or testing frameworks can improve velocity.
External factors: Holidays, conferences, production incidents reduce available capacity.
Estimation changes: If you start over-estimating or under-estimating, velocity numbers change (even if actual work output is the same).
Forecast completion: "We have 200 points of work. Velocity is 30 points per sprint. 200/30 = 6.7 sprints. That's 13-14 weeks."
Identify capacity constraints: "We have 100 points of work this quarter and 30 velocity = 3+ sprints. That's our capacity." Forces prioritization.
Track progress: "We've completed 60 of 100 planned points. We're on track to finish in 3.3 sprints."
Identify risks: "Velocity is declining (was 35, now 28). At this rate, projects will take longer. Investigate why."
"Our velocity is 30, so we can always commit to 30." Velocity varies. Some sprints have holidays. Some have production incidents. Commit conservatively (25-28 of expected 30).
"Increasing velocity by pushing the team harder." Pushing leads to burnout and cutting corners (more bugs, more technical debt). Don't use velocity as a pressure metric.
"Comparing velocity across teams." Team A's 30 points ≠ Team B's 30 points. Velocity is relative to that team's estimation standards. Don't use it to compare teams.
"Velocity is wasted if we don't fully use it." "We planned 30, we completed 25." That's OK. Better to complete 25 high-quality points than force 30 points and reduce quality.
"Estimating in isolation." "This is 5 points based on lines of code." Missing: external dependencies, testing needs, documentation. Estimate in context.
Declining velocity: Usually indicates: increasing technical debt, team disruption, or external blockers. Investigate and address root cause.
Increasing velocity: Usually indicates: team is learning and improving, or estimation is becoming more optimistic (not actual improvement). Verify it's real improvement.
Stable velocity: Ideal. Means capacity is predictable, team is stable, estimation is consistent.
High variance: Some sprints are 40 points, others 20. Indicates: estimation is inconsistent, external factors vary, or work is unpredictable. Reduce variance by: better scoping, fewer surprises, stable team.
Startups: High variance. Priorities shift. Focus on: shipping quickly, learning, adapting. Velocity estimation is useful but less critical.
Established products: More stable. Priorities are clearer. Velocity estimation is important for roadmap planning.
Teams with high turnover: Velocity is unreliable. Focus on processes that reduce dependency on individuals.
Teams with high interruptions: Committed velocity is low. Plan accordingly. Reserve capacity for interruptions.
Unclear stories: If stories aren't well-scoped, estimates vary widely. Fix: improve story clarity before estimation.
Estimation game: If team feels pressured to estimate low (to look faster), estimates become meaningless. Fix: use estimates for planning, not performance evaluation.
No follow-through: If the team doesn't actually try to complete planned work, velocity is fiction. Fix: treat sprint commitments seriously.
Too many interrupts: If work keeps getting interrupted, velocity becomes unreliable. Fix: protect team from interrupts or accept lower committed velocity.
"High velocity is always good." No. High velocity with bugs is bad. High velocity through unsustainable pace is bad. Quality matters more than quantity.
"We should aim for 100% sprint completion." No. 80-90% is healthy. 100% means you're overcommitting (or under-scoping). Leave room for surprises.
"Velocity should always increase." No. Stable velocity is good. Increasing velocity is sometimes a sign you're cutting corners or overestimating.
"Velocity is destiny." No. Velocity is a signal about capacity, not a guarantee. Use it for planning, but don't treat it as absolute.
Q: How many sprints should we track before using velocity for planning?
A: At least 3 sprints to see patterns. 6 sprints is better (gives more reliable average). 12+ sprints shows seasonal trends (Q4 has holidays, etc.).
Q: What if velocity is unpredictable?
A: That's a signal something's wrong. Investigate: estimation issues, external blockers, team instability, unclear priorities. Fix the root cause, not the symptom.
Q: Should we estimate in hours or story points?
A: Either works. Hours are more precise but harder to estimate accurately. Story points are relative and less subject to bias. Recommendation: use story points, then map to hours using velocity ("our velocity is 30 points per week" = "about 4 hours per point").
Q: How do we explain declining velocity to leadership?
A: Be honest. "Velocity declined from 35 to 25 because: (a) we added new team member (ramp time), (b) technical debt in the auth system is slowing development, (c) production incidents took 10% of capacity." Context helps leadership understand and adjust expectations.
Keep reading
Related resources
