Velocity Is a Result, Not a Target
You’ve been told you’re doing Agile.
But if you listen closely, what you’ll hear isn’t thinking. It’s vocabulary. Frameworks repeated mechanically. Practices copied without understanding why they exist.
That’s how teams end up playing Agile bingo.
We see this constantly. Organisations say they’ve been “doing Agile” for years. Then they come to one of our fundamentals trainings, and almost everyone says the same thing.
“We’re not really doing it. We’re just using the words.”
That gap between language and understanding is where most change efforts stall.
This series exists to expose that gap.
Each post uses a simple litmus test. One question that shows whether someone understands the thinking behind a practice, or is just repeating what they were taught.
We’re starting with one of the most misunderstood concepts of all.
Velocity.
Why We Created This Series
You can’t coach someone out of a fundamental misunderstanding. You have to reset first.
That’s why we design our training the way we do. Not as knowledge transfer. As a reset. A chance to get the fundamentals right, so real agility has a chance to exist.
But training alone isn’t enough.
People need to be able to spot shallow understanding when they see it. They need to recognise when Agile language is being used without Agile thinking behind it.
That’s what this series is for.
How This Works
Each post follows the same pattern.
- A simple question
- A common answer that sounds reasonable but misses the point
- Why that answer is a problem
- What genuine understanding actually looks like
- Why the difference matters
No trick questions. Just clarity.
Litmus Test #1: Velocity. Completed vs Can Complete
The Question
Ask a Scrum Master or Agile lead: “What is velocity?”
Then listen carefully.
If you want to surface the thinking even faster, ask:
“How does velocity help you make decisions about the future?”
The Shallow Understanding Answer
“Velocity is how much work the team can complete in a Sprint.”
Or:
- It shows how fast the team is moving
- It tells us how much the team can deliver
- It’s a productivity measure
- We try to improve it over time
These answers all come from the same place.
A delivery and output driven mindset.
Notice how all of them quietly blur what was completed with what can be expected next.
Why This Misses the Mark
This thinking treats velocity as a delivery or output signal.
That keeps the conversation anchored in a project mindset.
The assumptions underneath are familiar, even if they’re not stated out loud:
- Work is something to push through
- Success is measured by output
- Predictability comes from control
- Value is assumed once enough things are delivered
Velocity was never intended to validate delivery performance or explain output. Used this way, it becomes a crude proxy for past activity.
More importantly, it turns velocity into a target instead of a result.
Once that happens, the consequences are predictable.
- Estimates get inflated to protect the number
- Forecasts harden into expectations
- Teams stop being honest about uncertainty
- Complexity and variability are ignored
- Trust erodes
The Scrum Master drifts into task management. The team optimises for numbers instead of learning. Control replaces curiosity.
That’s not a tooling problem.
That’s a thinking problem.
And it’s exactly how organisations with a delivery and project bias quietly corrupt practices that were meant to support learning, inspection, and adaptation.
The Genuine Understanding Answer
“Velocity is a limited, historical signal that helps us reason about future uncertainty. It is not a measure of delivery performance.”
Someone with real understanding will usually make this explicit:
- Velocity is based on estimate units, not effort or output
- It only applies to one team, in one context
- It is not something to optimise, stabilise, or explain
- We use it to create forecast ranges, not commitments
- Its only value is the conversations it enables
They’ll often add:
- We don’t talk about velocity in isolation from value
- We use it to explore risk, options, and trade offs
- As maturity grows, we rely on it less
- Flow data gives stronger forecasting signals
- Probabilistic forecasting helps reason about outcomes, not promises
At this level, velocity is clearly seen for what it is.
A temporary, imperfect tool to support decision making.
Nothing more.
It is worth knowing that the Scrum Guide does not mention velocity at all. It is an optional practice, not part of Scrum.
Why This Matters
When velocity is treated as a delivery metric, teams optimise output.
When it’s treated as a forecasting aid, teams optimise learning.
The shift is subtle, but critical.
- from “did we deliver enough?”
- to “what does this tell us about our options?”
Velocity stops being something to defend and starts being something to interrogate.
That’s when conversations move away from projects and outputs, and toward value, risk, and outcomes.
Making It Real: The Sat Nav Analogy
Modern sat nav adjusts constantly based on live data. Accidents, traffic, new routes. It gives you a range and says, “This is my forecast based on what I know now.”
You don’t take it as gospel. You treat it as a guide that might shift.
Shallow velocity thinking works differently.
“The team did 40 points last Sprint, so they’ll do 40 points next Sprint.”
Rigid. Ignores complexity. Creates false commitments.
Genuine velocity thinking sounds like this.
“We typically complete 35 to 45 points. That’s based on recent Sprints with normal complexity. This Sprint has more unknowns, so we might see 30 to 50. It’s a forecast based on what we know now, not a commitment.”
One helps you make better decisions. The other gives you a false sense of control.
The Essence
One word shift reveals everything.
“Completed” versus “can complete.”
Completed equals empiricism. What we learned.
And even then, only as input to a wider conversation about uncertainty and value.
Can complete equals prediction. What we hope.
Scrum is built on empiricism. Inspect and adapt. Learn from what actually happened. Use that to make better decisions.
Someone can use all the right Agile language and still miss this.
What to Watch For
Red flags
They don’t understand velocity if they say it’s:
- a target to hit
- a measure of speed or productivity
- something to increase
- a fixed number to commit to
- something used to compare teams
Green flags
They understand it if they talk about velocity as:
- a historical result
- a range, not an average
- a tool for conversation and learning
- crude data that exposes complexity and variability
- something to notice, not something to hit
- a stepping stone toward better forecasting
- respecting team autonomy and self-organisation
Going a step further
If you are still using velocity and want to make it genuinely useful, the question is not how to improve the number.
It is how to use it to support better decisions about risk, options, and outcomes, without turning it into a target.
We have written more about that here, for teams who want to move beyond shallow use and make velocity work as a learning tool rather than a commitment mechanism.
Still Using Velocity? Make It Useful Again
Next in the series: Estimation Is for Deciding, Not Predicting
One Last Thing
If you’ve experienced shallow Agile thinking, whether from a coach, a manager, or a framework copy paste, that’s not a reflection on Agile.
It’s a reflection on the understanding.
Once you know what to look for, you can spot the difference. And you can start a better conversation.