by Gary Worthington, More Than Monkeys

At some point, every engineering leader runs into the metrics conversation. Maybe it’s a stakeholder asking, “Are we getting faster?” Or a senior leader wanting to see “velocity trends over time.” Or worse, someone outside tech has started calculating throughput per engineer. 🤮

It’s always well-intentioned. The business needs to understand whether it’s getting value from its investment in engineering. The problem is, velocity, ie. the number of story points completed per sprint, isn’t the answer.

Velocity was never meant to be a KPI. It’s a planning heuristic and an in-spring information radiator. That’s it.

When you start using it to report progress, you end up with all the usual anti-patterns: gaming the numbers, inflating estimates, prioritising easy tickets, and turning delivery into a performative ritual rather than a meaningful process. Velocity tells you nothing about the quality of your outcomes or the health of your teams. Yet it refuses to die, because it’s easy to graph in Jira.

Remember, no customer ever asked for 35 points in your next release. They asked for something meaningful, something useful to them.

So what can we do instead?

Here’s how I’ve approached this problem across startups and enterprise teams. No vanity charts. Just useful signals, aligned with how real progress happens.

1. Reframe the Question

Before we talk metrics, get clarity on what the business actually wants to know. “Are we making progress?” is usually shorthand for something else:

• Are we delivering the right things?
• Are we getting value for money?
• Can I trust this team to hit the roadmap?
• Why does everything take so long?

Until you unpack the underlying concern, you’ll keep reaching for shallow metrics that don’t address the real issue.

I’ve found it helpful to sit down with stakeholders and ask,

What would make you feel confident that we’re on the right track?

That unlocks far better conversations than waving a burndown chart around.

2. Tell the Story, Not the Score

Progress isn’t a number. It’s a narrative.

Instead of weekly updates like “we delivered 35 story points,” write a short update that explains:

• What you aimed to achieve this sprint
• What you actually achieved
• What you learned, and how that changes the plan
• What you need from leadership (decisions, unblockers, and so on)

It doesn’t have to be long, one page is usually enough. The key is to anchor it in outcomes. Business stakeholders understand progress when you talk in terms of features shipped, user problems solved, or operational issues addressed.

You’re not reporting on the team’s speed. You’re showing how you’re learning and adapting to deliver value.

3. Use Outcome Metrics, Not Output Metrics

Velocity is an output metric. It tells you how much you’re delivering, not whether it’s useful. Shift your focus to outcomes like:

Adoption

• Are users engaging with the thing we shipped?
• Has usage increased in target segments?

Time to Impact

• How long does it take from starting an idea to seeing real-world value?

Learning Throughput

• How many assumptions have we tested?
• Are we validating ideas earlier?

Reduction in Support Burden

• Are we reducing escalations?
• Are we removing manual processes?

None of these need to be real-time dashboards. A well-structured monthly review or a tight demo to stakeholders is far more effective than a colourful velocity chart.

4. Visualise Flow, Not Points

If you want something visual to show progress, use a cycle time or lead time chart. This shows how long work takes to flow from start to finish.

Flow-based metrics reveal:

• Where work is getting stuck
• How predictable your delivery process is
• Whether you’re building too much at once

They’re hard to game because they don’t care about how big the story was; they care about how long it sat in the system. You can even go further and calculate flow efficiency: the percentage of time work is actively being worked on compared to how much time it spent waiting.

It changes the conversation from “Why did this take 13 days?” to “Only 2 days were spent coding, so what happened in the other 11?”

5. Introduce DORA Metrics

If you need to standardise how you measure delivery health across squads, the DORA metrics are a solid baseline:

• Deployment Frequency
• Lead Time for Changes
• Mean Time to Restore
• Change Failure Rate

They don’t require story points. They’re actionable. And they’ve been validated through research across thousands of teams.

Remember though, don’t treat them as performance targets. They work best as signals for improvement, not as tools for comparison or blame.

6. Run Better Sprint Reviews

Too many sprint reviews are internal demos with a few observers from the business. Flip that dynamic.

Use reviews to:

• Show working software
• Talk about customer feedback
• Share what didn’t work and what’s changing
• Highlight blockers or scope questions early

A good sprint review should give the business confidence that:

• You’re making tangible progress
• You’re listening to users
• You’re learning and adapting

If your review is just a dev reading Jira tickets out loud, you’re wasting everyone’s time.

7. Report Risks, Not Just Progress

Part of building trust is being transparent about what’s not working.

Don’t sugar-coat delays or dress up failed experiments. The business doesn’t want perfection. They want predictability so dhare risks early. Be honest about what you don’t know. Invite them into the problem-solving process.

I’ve never lost credibility for saying, “This will take longer than we thought, and here’s why.” I have lost credibility when I pretended everything was fine and then quietly missed a deadline.

In Summary

If you want to show the business you’re making progress, stop obsessing over velocity. It’s a proxy that leads to the wrong conversations.

Instead:

• Frame updates around outcomes, not activity
• Use flow metrics and DORA to understand system health
• Build a narrative that shows learning, delivery, and adaptation
• Be honest about risks and changes in direction

Velocity can stay where it belongs, as an internal planning tool. You don’t need to weaponise it to prove your team is valuable.

Good delivery speaks for itself. You just need to translate it into language the business understands.