Bean Counters or Baristas? Why velocity is one of the most misunderstood metrics in agile

Imagine running a café where the success of your baristas is measured by one thing only: how many coffee beans they grind per hour.

Every week, management proudly presents the numbers in a meeting:

“Barista A processed 5 kilograms of beans this week. Incredible performance.”

Meanwhile, customers are standing in line for twenty minutes, half the drinks arrive cold, and nobody actually enjoys the coffee. Sounds absurd, right?

And yet this is surprisingly close to what happens in many agile organisations when Velocity becomes a performance metric instead of what it was originally meant to be: a simple planning tool.

Somewhere along the way, many companies started treating Story Points as if they were a universal productivity currency. Suddenly teams are compared against each other:

• Team A delivers 50 Story Points
• Team B only delivers 30
• therefore Team B must be slower, less productive or somehow “worse”

But this completely misunderstands what Velocity actually represents. Velocity is not a speedometer. It does not measure customer value, quality, impact or business outcomes. It simply describes how much work a specific team can realistically handle within its own context and estimation system. Using Velocity to compare teams is a bit like comparing cafés based purely on how many coffee beans they grind, without looking at whether customers actually enjoyed the drink.

And the moment Velocity becomes a KPI, human behaviour starts adapting to the metric itself. Story estimations slowly inflate, tasks become artificially larger, teams optimise for looking productive instead of creating value. On paper, the numbers improve beautifully — but customers do not experience any meaningful difference.

This is the software equivalent of adding more and more hot water to the coffee just so the café can claim it served fifty cups instead of twenty. Yes, technically more cups were delivered. But the actual coffee experience became weaker with every additional dilution.

Looking at the system instead of the bean counter

The problem is not metrics themselves. Metrics can be incredibly valuable. The real problem starts when organisations optimise isolated numbers without understanding the system behind them. Because software delivery is not only about output. It is about flow, quality and customer value working together.

And this is where more meaningful metrics become far more interesting.

Process Metrics: Is the System Actually Flowing?

One of the most important questions is not “How much work did we complete?” but:

“How smoothly can value move through the system?”

1. Take Lead Time, for example. This measures the time between a customer request and the moment the customer actually receives value. In café language: the time between ordering the cappuccino and finally holding the cup in your hand. And honestly, this is the only time customers truly care about. Nobody walks into a café wondering how many beans were processed internally. They simply want their coffee without unnecessary waiting, confusion or frustration.
2. Then there is Cycle Time — the time the team is actively working on something once the work actually starts. This distinction becomes incredibly useful because it reveals where delays really come from. If Cycle Time is short but Lead Time is enormous, the issue is probably not technical capability. The problem is usually organisational friction:

• waiting for approvals,
• dependencies between teams,
• unclear responsibilities,
• overloaded systems,
• or constant interruptions.

In other words: the coffee machine itself may work perfectly — but the organisation around it creates traffic jams.

3. Another critical metric is WIP (Work in Progress).

Or in café terms:

How many half-finished cups are standing around simultaneously?

Because the more things people try to handle at once, the slower everything tends to become. Focus almost always beats multitasking.

Quality metrics: Can we trust the craftsmanship?

Speed without quality creates expensive chaos.

This is why quality metrics matter — not as punishment mechanisms, but as signals about the health of the system. One example is escaped defects: issues customers discover before the team does. In café terms, this is the moment the customer notices the coffee is cold, the milk is sour or the order is wrong before the barista even realises it.

Another powerful indicator is MTTR — Mean Time to Recover.

When the coffee machine suddenly breaks down, how quickly can the team recover without creating panic, blame or operational paralysis? Healthy systems are not systems without problems. Healthy systems are systems that recover quickly.

The hardest metric: Real customer value

And then we arrive at the most uncomfortable category of all: Did any of this actually matter to the customer? Because ultimately, the real success metric is not output. It is whether people truly received value.

One of the most honest indicators is simple usage: Do people actually use the feature? Do they come back? Does it improve anything meaningful in their daily experience? Or is it just another decorative feature quietly collecting dust somewhere in the interface?

This is where organisations often discover a painful truth: positive feedback in meetings does not necessarily translate into real engagement.

In reviews, stakeholders politely say:

“Looks good.”

But usage data quietly says:

“Nobody touched it.”

And this is why observation matters just as much as surveys.

Sometimes customers will never directly tell you something feels frustrating. But you can still see it in hesitation, confusion, abandonment behaviour or lack of return usage. Just like you can often see from someone’s first sip whether the coffee actually tastes good — even before they say a word.

What Agile should really optimise for

At the end of the day, Agile should not optimise for busyness, output volume or prettier reporting dashboards. It should optimise for:

• faster learning,
• smoother flow,
• better focus,
• healthier systems,
• and meaningful customer outcomes.

Because customers do not care how many Story Points your team completed last sprint. They care whether the experience solved their problem. Just like café guests do not care how many beans passed through the grinder. They care whether they would come back tomorrow for another cup.

Ciao! ☕️