Home › Agile answers › What is sprint velocity and how is it calculated?
What is sprint velocity and how is it calculated?
The formula
Velocity equals the sum of story points of DONE stories in the sprint. Half-finished work counts zero, because velocity measures delivery rather than effort. A rolling average over three to five sprints smooths out flu weeks and festival weeks, and that average — not last sprint's raw number — is what you plan against.
Worked example
Sprint 1: the team commits 30 points and finishes stories worth 21, so velocity is 21. Sprint 2 finishes 18. Sprint 3 finishes 24. The average is about 21, so Sprint 4 planning pulls roughly 21 points of backlog even if enthusiasm argues for 30. Over-commitment is the single most common cause of demoralising sprint failure.
What velocity is NOT
Velocity is not a productivity score and must never be compared across teams — points are relative to each team's own estimation scale, so a cross-team comparison measures estimation habits, not output. Inflating estimates to raise velocity simply devalues the unit. Its only legitimate job is forecasting how much this team, estimating this way, ships per sprint.
Tracking velocity without a spreadsheet
Flocci Projects derives velocity automatically: complete a sprint and its Done points become a bar on the velocity trend chart, with the average across completed sprints shown alongside status distribution and per-assignee workload — free on the personal board. ClickUp gates Sprint Points to Business ($12/user/month) and Linear puts Insights on Business ($16/user/month).
Try it on a free Flocci Projects boardRelated questions
How many sprints until velocity is reliable?
Three completed sprints give a usable average; five give a trustworthy one. A brand-new team should plan its first two sprints conservatively and let the number emerge rather than setting a target, because a target turns points into a currency people inflate.
Should unfinished stories count partially toward velocity?
No. Counting partial work inflates the forecast and hides the real problem, which is usually stories that are too big or scope that crept. Roll the story into the next sprint; its points count when it is genuinely done.
Is higher velocity always better?
No — a stable velocity beats a high one. Forecasting needs consistency, so a team shipping 20 points every sprint is more valuable to planning than one oscillating between 10 and 35, even though the second team's peak is higher.
More agile answers
- What are story points in agile estimation?
- How do I estimate story points consistently across a team?
- Kanban vs scrum board — which should my team use?
- How do I run sprint planning for a small team?
- What is a product backlog and how do I groom it?
- What is the difference between backlog refinement and sprint planning?
- What are WIP limits in kanban?
- What is the difference between burndown and burnup charts?
- What is an epic in agile project management?
- What is the difference between an epic, a story and a task?
- What is the definition of done in scrum?
- How do I run a daily standup that is not a status meeting?
- What is a sprint retrospective and how do I run one?
- What happens in a sprint review?
- What are the three scrum roles?
- What is the difference between cycle time and lead time?
- What is planning poker and does it actually work?
- What is MoSCoW prioritisation?
- How do I calculate sprint capacity?
- Which agile metrics actually matter for a small team?
- Agile vs waterfall — which is right for my project?