Agile guide · Agile practices
Velocity Charts in Agile: How to Read and Use Them
Velocity is the amount of work an Agile team completes in a sprint, usually measured in story points. A velocity chart plots it sprint by sprint. Used well, it is a simple forecasting tool. Used badly, it becomes a misleading performance target.
Key takeaways
- Velocity is completed story points per sprint.
- Use averages and ranges to forecast, never single numbers.
- Never compare or target velocity between teams.
What velocity measures
Velocity is the sum of the story points of all items that met the Definition of Done in a sprint. Partially finished work counts as zero.
Reading a velocity chart
A velocity chart is usually a bar chart with one or two bars per sprint:
- Committed: points planned at Sprint Planning.
- Completed: points actually done.
Look for trends rather than single sprints. A stable velocity means predictable delivery. Big swings suggest items are too large, the team is often interrupted, or estimates are inconsistent.
Using velocity to plan
- Sprint planning: use the average of the last three to five sprints as a guide for how much to take on.
- Release forecasting: divide remaining backlog points by average velocity to estimate how many sprints are left. Use a range (best and worst recent velocity) rather than a single date.
- Spotting problems: a falling velocity can signal technical debt, unclear requirements or team changes.
Velocity, burndown and burnup
| Chart | Shows | Best for |
|---|---|---|
| Velocity chart | Points completed per sprint | Capacity and long-term forecasting |
| Sprint burndown | Work remaining in the current sprint, day by day | Daily progress within a sprint |
| Release burnup | Completed work and total scope over time | Showing progress when scope changes |
Mistakes to avoid
- Comparing velocity across teams; points are relative to each team.
- Setting velocity targets, which encourages inflated estimates.
- Counting unfinished work.
- Treating a forecast as a promise.
Free templates for this topic
Frequently asked questions
What is a good velocity?
There is no good or bad number. A useful velocity is a stable one, because stability makes forecasting reliable.
How many sprints before velocity is reliable?
Usually three to five sprints with a stable team.
What is velocity in Agile?
The total story points of items a team completes to the Definition of Done in a sprint. It is used to plan and forecast.
How do you calculate velocity?
Add up the points of every item that met the Definition of Done in the sprint. Average the last three to five sprints for planning.
What does a velocity chart show?
Usually two bars per sprint: points committed at Sprint Planning and points actually completed. The trend matters more than any single sprint.
Why is our velocity dropping?
Common causes are growing technical debt, unclear requirements, team changes, more interruptions or items that are too large. Discuss it in the retrospective.
Should velocity increase over time?
Not necessarily. A stable velocity is more useful than a rising one, and pressure to increase it often leads to inflated estimates.
How do you use velocity to forecast a release?
Divide the remaining backlog points by average velocity. Use the best and worst recent velocities to give a range rather than a single date.
What is the difference between velocity and capacity?
Capacity is the time a team has available; velocity is how much it has historically completed. See Agile capacity planning.
Does Kanban use velocity?
Not usually. Kanban teams track throughput, the number of items finished per period, and cycle time instead.
Should unfinished stories count towards velocity?
No. Partially finished work counts as zero. Count it in the sprint in which it is actually completed.