Speed vs. Velocity: The Difference Between Moving Fast and Moving Forward

4 hours ago 1

☕ Welcome to The Coder Cafe! Today, we discuss the difference between speed and velocity in team productivity, illustrating that tracking speed alone can be misleading. Get cozy, grab a coffee, and let’s begin!

On paper, the team delivered 10 story points. That is only speed, though, not velocity. If we care about direction as well, the team only delivered a single feature.

We often celebrate teams for moving fast. But speed alone can be a trap. A rush of fast changes that barely move the product toward the real goal shouldn’t count as a win. When we talk about team productivity, we should understand that speed ≠ velocity:

Speed is how quickly a team ship changes.
Velocity is speed with direction, the movement toward a defined goal.

Let’s look at three teams to illustrate these definitions.

Team A has ideal velocity. Each iteration is represented by an arrow: its length shows speed, and its angle shows direction. Every iteration moves the team consistently closer to the goal.
Team A shows ideal velocity: steady speed and consistent direction.
Team B has a speed problem. Each iteration is well-aligned (correct angle), but the team delivers too slowly (small length), resulting in a lower velocity. They finish only halfway to the goal.
Team B has the right direction but low speed, so they only reach halfway to the goal.
Team C ships as rapidly as team A (same arrow length). However, various factors such as frequent bug fixes and changing targets make their direction inconsistent. Despite high speed, their velocity is low, and they end only halfway to the goal, just like team B.
Team C moves fast but changes direction often, so velocity stays low and progress stops halfway.

As we can see, velocity requires both speed and direction. A team moving too slowly or in inconsistent directions will make little progress, even if they’re busy. Only when speed is high and direction is aligned do teams reach their goals efficiently.

Measuring team speed isn’t useless, though. We can track speed by considering various metrics such as deployment frequency, average time in code review, or mean time to recovery (MTTR) following a production bug. These metrics are interesting to track and provide a certain perspective to understand a team's productivity. Yet, speed shouldn’t be the sole dimension to track.

The danger of tracking speed only is that a team might become organized in a way to optimize short-term delivery. The team might focus on delivering many changes that, together, do not move the product in a meaningful way. Instead, teams should track speed and velocity.

As we said, velocity is speed with direction. We already discussed metrics to track speed; what is missing is monitoring direction.

Setting clear and factual objectives that align with the business strategy helps us track direction. For example:

Payment success rate above 99 percent.
Signup to activation above 50 percent within 7 days.
Retention after week 4 is above 40 percent.

The easier a metric is to measure, the easier it is to track the direction over time.

One caveat is how to report progress. In a past team, we used to set OKRs (Objectives and Key Results) every semester. Some objectives were difficult to measure, so we tracked progress differently. Say we created 50 tickets and closed 45. In that case, we reported that we reached 90% of the OKR. That number said nothing about real progress toward the objective. Key results should be outcomes, not ticket counts.

Something else to mention, I read here and there that we should track velocity by counting the number of story points delivered within a timeframe (e.g., during a sprint). I strongly disagree with this. Let me give an example:

A team ships a first change ← 3 story points
The team finds a bug and ships a fix ← 2 story points
Later, the team learns the initial approach is not the best, so it ships another change ← 5 story points

On paper, the team delivered 10 story points. That is only speed, though, not velocity. If we care about direction as well, the team only delivered a single feature. Story points measure effort; they don’t measure progress toward the objective.

Speed is how fast we ship. Velocity is speed with direction toward a goal.
The goal of a team shouldn’t be to reach high speed; it should be to reach high velocity, where rapid iterations translate into real system-level improvements.
Tracking story points, for example, is a measure of speed, not velocity.
Objectives tracking should use outcomes, not ticket counts. Reporting 90 percent of tickets done is not a good measure of progress toward the objective.