We love our metrics. They give us a sense of direction, progress, and structure. But sometimes… we’re using the wrong map to track the right journey.
The Comfort of Familiar Metrics
We’ve all done it. We use velocity, lines of code, bug count, number of tests, deployment frequency—trying to measure the health of our teams, our process, and our products.
And it’s not because we’re lazy or unimaginative. We use them because:
- They’re known.
- They’re widely used, making them easy to compare.
- They feel objective and quantifiable.
- And most importantly—they’re already in place.
Just like how we’ve used BMI for decades to assess health—even though we know it doesn’t work for everyone—we cling to these metrics, because they’re all we have in some areas.
But Are They Telling Us the Right Story?
These traditional metrics aren’t bad. Velocity can still help with planning. Deployment frequency can reveal how smoothly code moves into production. But we must recognize their limits.
When we stretch a metric beyond its intended scope—using bug count as a stand-in for product quality or using lines of code to assess productivity—we start creating a different kind of burden:
Process Technical Debt.
This kind of debt creeps in when our tools for measuring progress no longer reflect our real-world goals. And instead of preventing failure, we unintentionally design processes that generate frustration, waste effort, and confuse progress with activity.
What If We Created Our Own Metrics?
Here’s the good news: we don’t need to throw out our entire dashboard. Instead, let’s augment it with metrics that actually reflect the kind of success we’re trying to build.
Scenario Based Development (SBD) helps us tune our metrics to fit our journey. We identify:
- Where we are today
- Where we want to be
- What measurements really help us track that progress
Some examples:
- Scenario Completion over Story Points
Instead of just counting how many points a team delivered, measure how often full, end-to-end user scenarios are implemented. This brings the focus back to business value, not just activity.
- Adaptability
How easily can the team or product adapt to change? You can track this through:
- Retrospective insights
- Number of files touched to implement a small change
- Effort required to integrate new features
- Defect Detection Time
Measure how long it takes to discover and resolve issues that impact real users. Not just any bug—but the ones that matter most.
- Defect Impact
Track not only how many bugs exist, but how painful they are. Do they block key flows? Undermine trust? Cost real money?
Keeping What Works
Let’s be clear: we don’t need to abandon all traditional metrics. Velocity can still be helpful for sprint planning. Deployment time might still matter for CI/CD efficiency.
The key is to stop using these metrics where they don’t apply, and start creating custom indicators for the places they never fit in the first place.
Success Is Personal—So Measure What Matters
When you measure what matters most to your team and your product, you unlock:
- Higher motivation
- Clearer alignment
- Faster feedback loops
- Reduced rework
- Increased stakeholder trust
And ultimately, a product that resonates with users, a team that knows it’s winning for the right reasons, and a business that can scale with confidence.
Let’s stop judging ourselves by someone else’s progress tracker—and start defining success on our own terms.
What would you learn about your team, your product, or your users… if you measured the things that actually matter to you—instead of the things that have always been measured?
