What is developer velocity?

As part of a larger organisations, software development teams need to be able to plan their work. In addition, they are often asked to justify budget requests and provide some sort of key performance indicators (KPIs) that allow people outside the engineering department to understand how it contributes to the success of the company as a whole. This has led to many and much-discussed efforts to measure different aspects of the software development process.

In this article, I will focus on one of the less contested metrics: Developer velocity. I will explain what it is, how it is commonly measured, and what it can sensibly be used for.

What is developer velocity?

Developer velocity is a metric that tries to capture how much work a developer gets done in a specific time period. I say “tries to capture” because measuring developer velocity is tricky.

The challenges of measuring developer velocity

Measuring developer velocity is difficult mainly because software development is a complex activity. It often involves working on difficult problems that require ingenuity and creativity to solve. Often, how a specific task will be achieved is not clearly known when a developer starts working on a task. As a consequence, it is fiendishly difficult to estimate the time it will take a specific task to complete.

Nevertheless, there are established ways to measure velocity that are used in the industry which work around the challenge of estimating individual tasks or measuring individual developers’ productivity by aggregating estimates across people and tasks.

How to measure developer velocity

The most common method for measuring developer velocity is through story points. Story points are an artificial metric which are on purpose not related to specific amounts of time. Instead, story points are supposed to capture the relative difficulty of a task in comparison to other tasks.

Story points are most commonly used within scrum or scrum-related methods of organising development work. This means that software development is done in sprints, which have a fixed length, typically 1-4 weeks.

In each sprint, developers work on tasks. Story points are estimated for each task. Developers estimate story points together, as a team. Each team member can propose a story point number for a task and this is discussed within the team until a consensus is reached. This often also serves to get a common understanding of the complexities involved in a task, which are discussed when assigning story points.

However not any random number of story points can be assigned to a task. Instead, only numbers that are present in the Fibonacci series can be chosen: 0, 1, 2, 3, 5, 8, 13, 21, 34, … This is done for two reasons: (a) to avoid unrealistic illusions of accuracy and (b) to capture the increasing imprecision of estimation for more complex tasks.

Generally, it is said that any task that has a story point estimate of 13 or above is too big as a single task and should be broken down into smaller subtasks. This again relates to the fact that large or complex tasks are fiendishly difficult to estimate. Breaking tasks down into smaller, more tangible subtasks improves the quality of estimates.

This means that most tasks in a sprint will have story point estimates of 1, 2, 3, 5 or 8. Comparing the tasks with each other, the team will decide which tasks are more complex, which get a higher story point estimate, and which are simpler, which get a lower story point estimate.

Another common method is to use t-shirt sizes for estimates, giving tasks a simple S, M or L. This has the big advantage of being even less relatable to units of time than numbers.

Developer velocity is then aggregated for the entire team and entire sprints. For example, in a two-week sprint, a team might be able to complete on average 50-60 story points. This is then called the team velocity.

For teams that have worked together for a few sprints, team velocity tends to stabilise across sprints. In contrast, the velocity of individual developers tends to vary a lot more than the overall team velocity.

Measuring team velocity using story points has become an industry standard and has established itself as the most reliable and most widely used method for measuring developer velocity. It gets around the many challenges of measuring velocity by

Not estimating time to complete a task but task complexity, which is easier to grasp,
Not estimating absolute complexity but estimating complexity of tasks relative to each other,
Not measuring individual developer’s speed, but team velocity,
Not measuring individual tasks but aggregating measurements across an entire sprint.

A lot of the imprecision of estimation averages out across developers and tasks, leading to a fairly stable metric.

Why measure developer velocity?

Team velocity is commonly used in order to enable planning: knowing how many tasks a team can expect to complete within a sprint. This is what story point estimation has been built for, and can support well.

Team velocity is also a very interesting metric to keep an eye on over time. A slowdown can indicate issues in the development process, while an increase can indicate that blockers have been removed. However, changes in team velocity tend to take several sprints to become clear and can also be influenced by many factors.

One thing team velocity cannot do is inform executives of the effectiveness of their development team. Team velocity is not a standardised metric. It is not possible to use it to compare teams to each other, since each team estimates differently, or to compare individual developers with each other, or calculate a return on investment for an engineering team or department.

It does, however, allow planning, and to get an idea of how a development team’s velocity develops over time.

If you want to learn more about the big picture of increasing productivity and satisfaction in the development team, read our article about developer experience.

Pitfalls

There are two common pitfalls that beset developer velocity in a similar way to many other metrics: First, developer velocity is often mistaken for an absolute metric of developer productivity or team effectiveness, and second, measuring developer velocity provides an incentive to maximise this metric, which can lead to unexpected side-effects.

Developer velocity is not a standardised metric and not suitable as a KPI

Even when using the same method of measuring developer velocity, two teams will estimate differently, leading to different velocities. Team velocity is therefore not suitable for comparing teams with each other, since it is not a standardised metric. A team’s velocity as a number doesn’t contain much information in itself. It is only valuable when looked at over time, and as a tool to determine how many tasks can be accomplished within a sprint.

As such, it is also not suitable as a KPI, since it does not say anything about the quality of work that is accomplished, or about the efficiency of resource use, or whether or not the work that is being done is aligned with company goals.

Like any metric, velocity can be gamed

Setting developer velocity as a KPI can also have the undesired effect of developers trying to maximise velocity in ways that do not actually reflect a real increase in speed. For example, teams start increasing their estimates and simply assign more story points to individual tasks, if they are rewarded for completing many story points. As with all metrics that focus on one aspect of work only, it can also lead to developers closing tickets as quickly as possible and compromising on code quality, testing and documentation. When using Fibonacci numbers for story points estimates, which are not related to time units, it is also commonly the case that it is possible to close five 1-story-point tickets in much less time than it takes to close one 5-story-points ticket. Incentivising velocity can then lead to developers preferring to work on small tasks.

Preventing such distortions is best achieved by not using developer velocity as a KPI, for which it is poorly suited anyway, and instead treat it as a tool for the team itself to scope a sprint.

Take the productivity of your IT team to the next level. With Remote Development Environments

In this whitepaper you will learn how RDEs can improve your team’s productivity and the quality of software development in your organisation.

Download now

Conclusion

Developer velocity is a metric that captures how much a software development team can accomplish in a certain amount of time.

Measuring developer velocity is difficult, because software development is a complex activity. Software development tasks often only become clear in scope while they are being worked on, which makes them very hard to estimate.

Nevertheless, there is a commonly used method for measuring developer velocity: Measuring story points completed in a sprint for an entire team, resulting in a metric for team velocity. This method gets around the inherent challenges of measuring developer velocity by estimating small individual tasks, doing estimation in a team, and aggregating velocity across people and tasks.

Team velocity is useful for planning the scope of a sprint, and can be used as an indicator for problems or improvements in development tooling and processes when observed over time. It is, however, not suitable as a KPI, since team velocity is not a standardised metric and doesn’t say anything about a team’s quality or effectiveness.