Velocity
The average amount of work (in story points) a Scrum team completes per sprint, used to forecast how much can be delivered in future sprints.
What is Velocity?
Velocity is a Scrum metric that measures how many story points a team completes per sprint, averaged over the last 3–5 sprints. It's a forecasting tool — not a measure of team performance.
How to calculate velocity
`
Sprint 1: 34 points completed
Sprint 2: 28 points completed
Sprint 3: 31 points completed
Average velocity = (34 + 28 + 31) / 3 = 31 points/sprint
`
Using velocity for forecasting
If your backlog has 150 story points of work and your average velocity is 30 points/sprint, you can forecast ~5 sprints to complete it. This is useful for release planning — not for guaranteeing dates.
What velocity is not
- Not a productivity metric — comparing velocity across teams is meaningless (different estimation scales)
- Not a target — teams that optimise for velocity inflate estimates
- Not stable — velocity drops with new team members, tech debt paydown, and after holidays
Velocity vs. throughput
Some teams prefer throughput (number of items completed per sprint) over story points, especially when story sizes are roughly uniform. It's simpler and avoids estimation debates.
Free templates for Velocity
Frequently asked questions
Should velocity be shared with stakeholders?
Share what it means for delivery forecasts, not the raw number. 'Based on our current pace we expect to complete the Q2 roadmap by end of June' is useful. 'Our velocity is 31 points' is meaningless to non-Scrum practitioners.
Why does velocity fluctuate so much?
Team composition changes, varying sprint goals, accumulated debt, holidays, and estimation drift all cause fluctuation. Use a rolling 4-sprint average and treat it as a range (±20%) rather than a precise figure.
Apply Velocity to your real product data
PMRead ingests customer feedback, interviews, and Slack threads — and generates PRDs grounded in real evidence.
Related terms
Scrum
An Agile framework that organises work into fixed-length sprints (1–4 weeks) with defined roles, ceremonies, and artifacts to deliver working software iteratively.
Product Backlog
A prioritised list of all work — features, bugs, improvements, and technical debt — that a product team intends to build, ordered by value and urgency.
Sprint
A fixed-length iteration (usually 1–2 weeks) in Scrum during which a team completes a set amount of work from the backlog and delivers a potentially shippable increment.