Velocity
Velocity in technical Scrum
In standard Scrum, velocity is the amount of work the team completes in a sprint. A velocity of 80 points indicates that the team completes 80 story points per sprint. It is calculated by adding up the points of all completed stories—those that have met the Definition of Done—at the end of the iteration.
Partially completed stories at the end of the sprint do not count toward velocity: in Scrum, only done work is measured, not work in progress. This rule avoids the illusion of progress created by half-finished work.
Average velocity and planning
After several sprints, the team has a velocity history that can be used as a planning reference. The average velocity of the last few sprints is the best estimate of how much work the team can take on in the next sprint.
The burnup chart uses historical velocity to project when product releases will be completed: with a pessimistic, a realistic, and an optimistic velocity, the Product Owner can communicate a range of delivery dates instead of a single date, which is more honest about the project's true uncertainty.
Velocity and ideal time
When planning a sprint, it is useful to distinguish between elapsed time and ideal time.
- Elapsed time is the actual working day: for a team of four people working eight-hour days, the elapsed time in one week is 160 hours.
- Ideal time is working time under conditions of full concentration, without interruptions or meetings.
Ideal time is always less than elapsed time. A task that takes "two ideal hours" can take up half a working day of elapsed time. Managing this difference helps teams commit to realistic sprints rather than aspirational ones.
Limitations of velocity as a metric
Velocity is a useful tool when used well, but it has drawn justified criticism when misused:
- Story points are relative to the team that estimates them. Comparing velocities across different teams makes no sense: a team that estimated a story at 5 points and another that estimated it at 3 may have invested the same actual effort.
- When velocity is used to compare or evaluate teams, it creates incentives to inflate estimates. Teams may start raising the points on their stories to "maintain their velocity," which erodes the usefulness of the metric.
- Velocity measures the amount of work delivered, not product quality or customer value.
For these reasons, Scrum Manager's Scrum Master v4.0 manual warns that the practice of measuring velocity in story points deserves careful consideration, and points to alternatives such as T-shirt sizing, Goldilocks, or NoEstimates.
Velocity with AI Tools
Adopting code assistance tools (GitHub Copilot, Cursor, and similar) can significantly alter a team's historical velocity. If the team starts using AI and its average velocity increases, projections based on the previous history will no longer be valid.
When the team adopts AI tools, it is advisable to reset the velocity baseline after a few adaptation sprints, rather than averaging it with the previous history. Otherwise, the Product Owner's projections will be off in either direction.
Resources
📄 Scrum Master v.4.0 [in Spanish] — Section: agile measurement and estimationFree download · Scrum Manager
📄 Scrum Master en equipos con IA [Scrum Master in Teams with AI, in Spanish]Free download · Scrum Manager
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.