What Is Velocity in Agile? How to Calculate It and Use It for Planning
Velocity is a metric used in agile development to measure the amount of work a development team completes in a sprint or iteration. It is calculated as the total number of story points (or other estimation units) accepted as complete at the end of each sprint. Over multiple sprints, velocity data produces an average that teams use to forecast how much work they can complete in future planning periods.
Velocity is primarily a team planning tool — it answers the question “how much can we realistically commit to this sprint?” based on evidence from past sprints, rather than optimistic estimation alone.
How Velocity Is Calculated
Sprint Velocity = Total Story Points Completed in a Sprint
Story points are only counted when a story fully meets the definition of done — complete, tested, reviewed, and accepted. Partially completed work carries zero story points in the velocity calculation.
Average Velocity = Sum of Sprint Velocities ÷ Number of Sprints
Teams typically calculate average velocity over the most recent 3–6 sprints to smooth out outliers and reflect their current capability rather than historical patterns that may no longer apply.
Example: A team’s last five sprints produced velocities of 32, 28, 35, 31, and 29 story points. Average velocity = (32 + 28 + 35 + 31 + 29) ÷ 5 = 31 points per sprint.
How Velocity Is Used in Planning
Sprint Planning
During sprint planning, the team uses their average velocity as a ceiling for their sprint commitment. If the team’s average velocity is 31 points, they should not commit to more than approximately 30–32 story points in the upcoming sprint. This prevents chronic overcommitment and the stress and quality degradation that results from teams consistently failing to meet commitments.
Release Planning
Velocity enables teams to forecast how many sprints will be needed to complete a defined scope of work:
Sprints Needed = Total Estimated Points in Release ÷ Average Velocity
Example: A release backlog contains 180 story points. The team’s average velocity is 30 points/sprint. Estimated sprints needed = 180 ÷ 30 = 6 sprints (approximately 12 weeks in a 2-week sprint cadence).
What Affects Velocity
Team Composition Changes
Adding or removing team members changes the team’s capacity. New team members typically produce below-average velocity for several sprints as they develop context. Velocity normalizes after the team stabilizes.
Holidays and Vacation
Sprint capacity varies when team members are absent. Teams can account for this during sprint planning by adjusting their commitment downward — not by treating velocity as a fixed target.
Technical Debt and Impediments
Accumulated technical debt slows down delivery. Teams working in heavily indebted codebases will have lower velocity than the same team working in clean code.
Story Point Calibration Changes
If the team significantly changes how they calibrate story points, velocity becomes non-comparable to historical data. Any substantial estimation recalibration should be noted.
Common Velocity Misuses
Comparing velocity across teams — Velocity is team-specific. A “5-point story” for one team may be entirely different from a “5-point story” for another. Cross-team velocity comparison produces meaningless numbers and unhealthy competition.
Using velocity as a performance metric — Velocity is a planning tool, not a productivity measure. Teams that are evaluated on velocity will game it — inflating estimates, marking stories complete before they’re truly done, or cutting quality to hit numbers.
Expecting velocity to be constant — Velocity fluctuates naturally. Planning that treats average velocity as a guarantee rather than an estimate leads to commitments the team cannot reliably meet.
Optimizing velocity over quality — A team can increase apparent velocity by reducing testing rigor and accepting technical debt. This is destructive. Velocity should always be sustainable velocity — work that meets the full definition of done.
Key Takeaways
Velocity is one of the most useful planning tools in agile development when used for its intended purpose: helping teams make realistic commitments based on evidence of what they can actually accomplish. Its value is entirely internal to the team — a calibration tool for planning, not a performance benchmark for comparison. Teams that use velocity honestly and consistently make better sprint commitments, produce more accurate release forecasts, and deliver more reliably than teams that commit to aspirational targets divorced from historical data.