The speed of the development team
Velocity is a measure of the speed of a development team. In Scrum, velocity answers the question of 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].
But how is it even possible to realise more story points than planned? There are different views on the interpretation and calculation of 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.
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 speed, a kind of inflation of the story points would loom: a velocity designed to increase speed can be achieved, for example, by increasing the estimated values; this would counteract the sense of 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 diagram. Here the development team – ideally together with the Scrum Master – should consider the reasons for the deviation between the planned and implemented user stories or product backlog items. From the findings, conclusions can be drawn for future planning.
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.
An assessment of the use of velocity in agile projects can be found here »
“The expertise in software architectures, the expertise in software development and the very flexible way of working were ideal for us.“
“I have been reading your blog for a long time with great pleasure. Systematically, to the point and appealing.”