What is Developer Velocity?

Developer Velocity – the speed of a single developer

The word “velocity” means speed or rapidity. In agile frameworks such as Scrum, velocity is an internal measure of the speed of development in a team. It is often based on realised story points and helps in planning sprints. Developer Velocity is an individual measure that focuses on the pace of an individual team member.¹

The Scrum Guide and Developer Velocity

Planning sprints using velocity is common in many organisations. However, in the Scrum Guide, which describes Scrum and its rules, neither velocity nor developer velocity appears as a term. Accountability, on the other hand, is explained in detail in the guide.² There are no hierarchies between the accountabilities (Scrum Master, Product Owner and Developer) or between the developers themselves. This essentially pursues two goals:

• Decisions should be made on the basis of technical criteria.
• And the responsibility lies in the team and not with individual team members.

If the Scrum Guide explicitly emphasises the accountability of the team, why should it be right to consider developer velocity as an individual speed measure in sprint planning? Ideally, team members have different skills and knowledge, and the team’s performance depends largely on the combination of these skills. If, for example, a team member does not have the required skills, the team as a whole is required to support him or her in the task and to expand his or her skills.³

Dealing with challenging development tasks

Time and again in organisations it can be observed that the speed and also the performance of individual developers are compared with each other. Often experienced developers are faster than less experienced colleagues. This can lead to challenging development tasks being regularly assigned to the best and most experienced developers.

• A deeper understanding of the code base and system architecture,
• as well as more experience in solving complex problems,
• implementing key requirements and
• working with the technology stack

are valid reasons for such an approach. Often, it is even the team itself that assigns the challenging tasks to a specific team member, as this allows them to use relevant expertise to quickly develop high-quality solutions.

However, there are also potential disadvantages if the demanding tasks are always assigned to individual developers:

• Knowledge silos are created where only a few developers have a deep understanding of certain parts of the code base or system. This can make it difficult for the team to collaborate effectively, share knowledge and develop a common understanding of the system as a whole.
• Dependencies arise, which become apparent at the latest when several demanding tasks are pending at the same time, but there are not enough knowledge carriers in the team at that point, e.g. due to holidays, illness or lack of capacity.
• If difficult tasks are always assigned to the same developer, the risk of burnout could also increase.
• Last but not least, such an approach limits the professional development opportunities of the other team members, which can also lead to discontent and demotivation.

Ultimately, the best approach depends on the specific context and goals of the team and the organisation. In some cases, it may make sense to assign the most demanding tasks to the best and most experienced developers, while in others it may be more effective to distribute the work more evenly and give all team members the opportunity to develop their skills and expertise.

If frameworks such as Scrum are anything to go by, then the equal distribution of tasks is often desirable, especially since velocity is considered 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. Sooner or later, this leads to an inflation of estimates. The same applies to developer velocity.

Velocity is a result, not a goal!

Notes:

[1] In some publications, developer velocity and velocity are used synonymously. Although this is possible in principle, it does not make much sense, as it contributes to confusion rather than clarity. If we were talking about the speed of the team, it would probably also have to be called Developers Velocity.
[2] Scrum Accountability
[3] In the course of Sprint Planning 2, the developers discuss “how” the agreed requirements are to be implemented. Here it can be useful for the Scrum Master to give hints if the team repeatedly leaves the most important tasks to the best developer.

Here you can find an empirical analysis on productivity of software developers.