Velocity

Velocity is the English word for speed. In software development, the word denotes a metric. Many development teams work in fixed time periods, usually two weeks. At the beginning of such a period, they take on a list of tasks. At the end, they add up how much of it has actually been completed. This exact sum is the team’s velocity. So it doesn’t measure how fast individual people type, but how much work actually comes out finished at the end.

Why teams measure their own pace

Software projects are notoriously estimated too optimistically. If you ask a team how long something will take, wishful numbers often come out. Velocity replaces these wishful numbers with empirical values. If a team has managed 30 points on average over the last six periods, it will hardly manage 60 in the next one. That is uncomfortable but useful information.

For planning, this is valuable. A product lead can roughly estimate when a feature will be finished. Instead of a promise, there’s a range: sometime between the end of March and mid-April. Investors and executives also like to hear such numbers, because they make software work somewhat tangible.

It becomes dangerous when velocity turns into a performance target. A metric that gets rewarded can be manipulated. A team can simply award its points more generously and then looks twice as productive without actually delivering more. That’s why in practice it holds that: velocity is a planning tool for the team itself, not a report card from outside.

Story points and the average over several sprints

To count work, you need a unit. Hours work poorly, because nobody can reliably predict hours. Instead, teams mostly use so-called story points. These are estimation points that express the relative effort of a task. A task with 8 points is roughly twice as much effort as one with 4 points.

At the end of each time period – called a sprint in jargon – only fully completed tasks are counted. Half-finished work earns zero points. That sounds harsh, but it prevents self-deception. The point totals of several sprints are then averaged, often over the last three to five. Individual sprints fluctuate too much, for example due to illness or holidays.

An important distinction: velocity figures from different teams cannot be compared. Each team sets its own point scale. 40 points for team A can mean less work than 20 points for team B. The number is only meaningful within a team and over time, similar to a personal best time in running.

From Jira charts to AI coding assistants

Anyone dealing with software in a company almost inevitably encounters velocity. Project tools like Jira or Azure DevOps calculate it automatically and draw bar charts per sprint. In meetings, these charts then hang on the wall and get discussed.

In recent years, the term has also appeared in the AI debate. Providers of coding assistants that suggest code advertise that they increase teams' velocity. Studies on this are mixed: code is produced faster, but more bugs and more rework also occur. Whether the finished work actually increases is disputed.

Outside the software world, the word has other meanings as well. In economics, the velocity of money describes how often a euro changes hands per year. And in the context of big data, velocity is one of several V-characteristics and describes how fast new data streams in. So when reading the news, it’s worth briefly paying attention to the context.