What is the Velocity, how and why is it calculated?
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.
Impulse to discuss:
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: