Technical debt is measurable. The teams that manage it well track the right numbers, not to be told how to fix anything, but to know where to look and whether things are getting better or worse. This post covers seven software quality metrics that surface technical debt: what each one measures, benchmarks to target, and how to track it in practice.
For a full breakdown of technical debt types, root causes, and management strategies, see our Technical Debt Guide for Engineering Leaders.
Why Metrics Matter for Technical Debt
Most teams know they have debt. The problem is translating "we have a lot of tech debt" into something a product manager or CFO can act on. Metrics do that translation.
Tracked consistently, quality metrics serve three functions: they make debt visible before it becomes a crisis, they give engineering leaders credibility in trade-off conversations with product teams, and they show whether remediation work is actually moving the needle. Without metrics, debt reduction is an act of faith. With them, it is a managed investment.
The 7 Key Software Quality Metrics
1. Code Complexity (Cyclomatic and Cognitive)
Code complexity measures how many independent paths exist through a function or module. Cyclomatic complexity counts decision points: every if/else, loop, and switch. Cognitive complexity, a measurement from SonarQube, accounts for how hard code is to understand, not just to test.
What high complexity signals: High-complexity code is harder to test, harder to modify safely, and more likely to hide bugs. A function with a cyclomatic complexity score above 10 typically has enough paths that full test coverage becomes impractical.
Benchmark: Cyclomatic complexity below 10 per function is the standard target. Functions exceeding 15 are strong candidates for refactoring.
How to track it: SonarQube and CodeClimate calculate this automatically on every commit. Configure alerts when complexity in a module exceeds your threshold.
2. Tech Debt Ratio (SQALE Rating)
The tech debt ratio, defined by the SQALE methodology, measures the proportion of remediation effort to total development effort. It answers: for every hour spent building, how much time is spent cleaning up?
What it signals: A rising tech debt ratio means the team is borrowing faster than they are paying back. The ratio translates well to non-engineering stakeholders because it frames debt as a financial cost.
Benchmark: SonarQube grades projects A through E. Grade A means a tech debt ratio below 5%. Grade E means above 50%. Most production teams target Grade A or B (below 10%).
How to track it: SonarQube calculates this automatically. Export the trend line quarterly to show leadership whether debt is accumulating or declining.
3. Code Churn Rate
Code churn is the percentage of code that gets rewritten within a short window after being written. High churn on a specific module is a strong signal that requirements were unclear, the design was wrong, or bugs are repeatedly being fixed in the same area.
What it signals: Sustained high churn in a module often indicates architecture debt or requirements-driven process debt, not just sloppy code. It also carries a morale cost: engineers dislike revisiting work they thought was done.
Benchmark: Based on LinearB engineering benchmark data: Elite teams average below 15% code churn. High performers: 15 to 25%. Medium: 25 to 35%. Low: above 35%.
How to track it: Most engineering intelligence platforms track churn at the PR, developer, team, and repository levels. For a deeper look, see Code Churn: What Engineering Leaders Should Know.
4. Test Coverage Percentage
Test coverage measures what percentage of your code is executed by automated tests. It is one of the most widely tracked quality metrics and one of the most frequently misused ones.
What it signals: Low test coverage on high-risk or frequently changed code is a direct debt indicator. But high coverage alone does not mean debt-free. What matters is coverage of the paths most likely to cause production issues.
Benchmark: 70 to 80% coverage on production-critical modules is a reasonable target. Coverage below 50% in actively developed code is a red flag. Track coverage trends as much as absolute numbers. Declining coverage during a high-velocity period signals that the team is taking on code debt faster than test debt is being addressed.
How to track it: Most CI/CD pipelines report coverage natively. Integrate coverage gates that block merges below threshold on your most critical modules.
5. Bug Density
Bug density is the number of defects found, normalized to codebase size (bugs per thousand lines of code, or bugs per sprint). It gives teams a way to compare quality across modules of different sizes and time periods of different velocity.
What it signals: Rising bug density in a specific module often points to concentrated code or architecture debt. If the same files appear repeatedly in post-mortems, that is not coincidence: that is where the debt is concentrated.
Benchmark: The more useful benchmark is your own trend. Three consecutive sprints of rising bug density in a module should trigger a debt-focused review, not just more bug fixes.
How to track it: Pull bug reports from your issue tracker and normalize to sprint velocity or estimated line count. Most teams use Jira or Linear with labels for "defect" or "bug" tagged to the affected component.
6. Static Analysis Issue Count
Static analysis tools scan code automatically for rule violations, code smells, security vulnerabilities, and anti-patterns, without running the code. The issue count from tools like SonarQube or CodeClimate gives you a continuous, objective measure of code health.
What it signals: A growing static analysis issue backlog signals code debt accumulation. A backlog that stays flat while velocity is high suggests the team is not creating new debt as features ship. A declining backlog confirms active remediation.
Benchmark: Absolute numbers matter less than trend direction and issue severity distribution. Track how many issues are Critical vs. Major vs. Minor over time. A high Minor count is manageable. A growing Critical count needs immediate attention.
How to track it: SonarQube and CodeClimate provide trend dashboards. Configure CI/CD to fail builds when new Critical issues are introduced, which stops new code debt at the point of creation.
7. Mean Time to Resolution (MTTR)
MTTR measures how quickly your team resolves a defect or debt item once identified. In the context of technical debt, it captures not just bug response speed but how long quality issues sit in your backlog before being addressed.
What it signals: High MTTR can indicate that issues are complex (architecture or code debt), that the team lacks capacity, or that there is no clear ownership. According to DORA research at dora.dev, Elite performing teams restore service within one hour. For non-incident debt items, MTTR trending upward quarter over quarter is a sign that the backlog is growing faster than the team can address it.
Benchmark (DORA tiers): Elite: less than 1 hour. High: less than 1 day. Medium: 1 to 7 days. Low: more than 6 months.
How to track it: Your issue tracker records creation and resolution timestamps. Calculate average MTTR by component or team on a sprint basis.
Building a Metrics Dashboard That Gets Used
Tracking seven metrics in isolation is less useful than tracking them together. The goal is a dashboard that shows the relationship between them: where complexity is rising alongside bug density and declining test coverage, that is a debt hotspot. Where all three are stable or improving, that module is healthy.
Three practices make metrics dashboards effective:
• Make trends visible, not just snapshots. A single data point tells you nothing. Three months of trend data tells you whether you are managing or accumulating.
• Track by module or component, not just site-wide totals. Site-wide averages mask concentrated debt. The worst 20% of your codebase is typically responsible for 80% of incidents.
• Review metrics in sprint retrospectives. Metrics that get reviewed regularly get acted on. Metrics that sit in a tool nobody opens do not.
The seven metrics above give you a complete picture of technical debt across your codebase. Scrums.com is an engineering intelligence platform that connects to your existing tools (GitHub, Jira, CI/CD) and surfaces all seven in a single dashboard. Code churn, test coverage trends, DORA metrics, and static analysis issue counts are tracked together and visible to engineering leadership without manual data pulls. See how it works.
Frequently Asked Questions
What are the most important software quality metrics for tracking technical debt?
The most useful metrics for surfacing technical debt are code complexity, tech debt ratio (SQALE), code churn rate, test coverage percentage, bug density, static analysis issue count, and mean time to resolution. No single metric tells the full story. Track at least three across different dimensions, one code-level metric, one process metric, and one output metric, and watch the trends rather than point-in-time snapshots.
What is the tech debt ratio and how is it calculated?
The tech debt ratio, defined by the SQALE methodology, is the proportion of remediation effort to total development effort. SonarQube calculates it automatically based on the estimated time to fix all detected code issues relative to the time spent writing the code. A ratio below 5% earns a Grade A. Most production teams target below 10%.
What is a good test coverage percentage?
70 to 80% coverage on production-critical modules is a widely accepted target. More important than the absolute number is the trend: declining test coverage during a period of high feature velocity is a signal that code debt is accumulating faster than it is being managed. Coverage below 50% in actively developed, production-critical code is a red flag worth addressing before adding new features.
How do code churn metrics reveal technical debt?
Code churn measures how much recently written code gets rewritten shortly after. High churn in a specific module typically signals unclear requirements, an architectural problem forcing the same area to be re-opened repeatedly, or bugs concentrated in one area. Based on engineering benchmark data, elite teams average below 15% code churn. Teams above 35% are typically seeing the delivery impact of concentrated debt in their highest-churn areas.
How should engineering teams use these metrics in practice?
Track metrics by component, not just site-wide. Site-wide averages mask concentrated debt. Review metrics in sprint retrospectives so they get acted on rather than just observed. Use trend data over at least three months to identify patterns. Where complexity, bug density, and churn are all rising in the same module, that is a debt hotspot to prioritize. Where metrics are stable or improving, the team is managing debt effectively in that area.
