Knowledge at a glance: Velocity is a measure of the speed of development, based on realised story points and helps in planning sprints.
Velocity – the speed of the development team
The English word “velocity” stands for speed. In Scrum the velocity or the velocity factor is a unit of measurement for the speed of a team.. It answers the question how many Story Points a Scrum team can complete on average per sprint. The average number of Story Points completed over a period of several sprints is an aid to planning future sprints.
- In Sprint 1 10 story points are realized, in Sprint 2 even 16 story points. In the following Sprint planning, 13 story points are used (if the same number of employees and working days are available).
- In Sprint 3 19 Story Points are realised. The planning for the 4th Sprint is now based on 15 Story Points [((10 + 16 + 19) / 3) = 15].
Interpretations of the Velocity
Is it possible to realise more Story Points than planned? Answering this question leads to two different interpretations and ways to calculate the velocity:
- Some organisations consider the additionally created functionality, which is formulated by user stories and implemented accordingly in the sprints. If 5 stories with a total of 16 story points were planned into a sprint and implemented accordingly, then the velocity of the sprint is 16 story points.
- In addition to originally planned user stories and story points, other organisations also consider tasks that were added in the course of a sprint. Such tasks can become necessary, for example, through bug fixing or refactoring. So it can happen that a team achieves a higher velocity than originally planned.
The velocity in sprint planning
Regardless of the type of calculation, it is important for organisations to reflect the average velocity in sprint planning rather than the maximum or highest speed of recent sprints. One of the principles of the Agile Manifesto is to promote sustainable development through a steady pace that clients, developers and users can maintain over an unlimited period of time. Content is more important than speed.
If the goal were to increase pace, there would be a risk of a kind of inflation of story points: a velocity designed to increase speed can be achieved, for example, by increasing the estimated values; this would counteract the purpose of estimation by means of story points.
Comparing the velocity of individual teams in an organisation based on velocity is also not a good idea. It is a team-internal tool for planning and risk control. Those who try to drive teams in an organisation by comparing them to each other based on planned or realised story points are not doing themselves any favours. This will also lead to an inflation of estimates. Here, both the Scrum Master and the developers are challenged to prevent this undesirable development as early as possible.
The visualisation of the velocity
The speed is visualised with a velocity chart. The so-called velocity offset as the sum of the user stories not realised in a sprint can also be read from the chart. Here the development team – ideally together with the Scrum Master – should consider what the reasons for the deviation between the planned and implemented user stories or product backlog items are. Conclusions for future planning can be drawn from the findings.
Velocity in practice
Here you will find some articles in English and German dealing with velocity in practice:
- The Colossal Danger inherent in Velocity – article by Derek Davidson on scrum.org.
- Velocity is a made-up number – acrticle by Daria Bagina on scrum.org.
- Agile Missverständnisse: Das Ende der Velocity? – article by Björn Schotte at Mayflower.
- Weekly Scrum Interview Question: What Is Velocity? – article by Alex Kudinov on scrum.org.
- Three Approaches to Estimating the Impact of Holidays and Time Off on Velocity – article by Mike Cohn at Mountain Goat Software.
- Velocity und Releaseplanung: Ein Überblick – article by Lars Richter at FlowWork.Rocks.
- Was bedeutet Velocity für Ihr Team? – article by agile academy.
- Warum Velocity besser Complition heißen sollte – article by Lars Richter at FlowWork.Rocks.
We would be happy to add more exciting contributions to the list.
Impulse to discuss:
Does the use of velocity, especially when understood as a target metric, lead to a stronger focus on quantity rather than quality?
If speed is created by quality, shouldn’t it be better to speak of completion instead of velocity? You can find an opinion on this here in German.
“Scrum, The Art of Doing Twice the Work in Half the Time” is a Scrum bestseller. Here you can find an article about the agile speed lie.
Velocity is not mentioned as a term in the Scrum Guide. Also the user story is not mentioned there. Nevertheless, both constructs are often used in projects and developments that use Scrum.
Here you will find additional information from our Smartpedia section: