☕ 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!
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.
Summary
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.
Resources
More From the Beyond Code Category
Sources
Sprint Velocity in Scrum: How to Measure and Improve Performance // The velocity definition I disagree with.
❤️ If you enjoyed this post, please hit the like button.
💬 What’s your take on speed vs. velocity? How do you measure velocity in your team?
Yes, Speed is not the goal, the target is the goal
Wasting effort running dosent mean you will reach the place you are going
but, the problem with focusing in direction, is that sometimes going on the right direction CAN hurt your speed.
Delaying technical debt or bug fixes because they dont make the team closer to the goal can (actually WILL) hurt your speed, to the point that you may come to a halt, and going back to fix everything will be far worse than it would have been at the time.
I would say we need a third concept, efficiency, or resistance, weight or something like this. This third word is the amount of effort caused by technical debts, the same effort can move a team at 95% speed or 50% speed, depending on how much your teams uses your system/enviroment/database, or fight against it.
If you want to Nerd this out a lot, you can say that this is more akeen to a light path, where the material its traveling dictates the speed, and can even curve the line.
So for any technical manager reading this, remember that the fastest path between 2 points isn't always a straight line