Technical debt tracking across its full lifecycle requires four phases: detection (automated codebase analysis measuring cyclomatic complexity, dependency counts, test coverage, and code churn), prioritization (scoring debt by business impact — incident correlation, development velocity drag, and blast radius), remediation (allocating 15–25% of roadmap capacity to debt work with clear verification targets), and verification (re-running the same metrics 30 days post-remediation to confirm signals improved). Most teams only track debt as Jira tickets, missing the detection and verification phases entirely.
At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
By Glue Team
Most teams track technical debt as a list of tickets in Jira. They add items when someone notices something's broken. They move them to "In Progress" when someone gets bandwidth. They move them to "Done" when the ticket's closed, usually without checking whether the underlying problem actually improved.
This approach captures debt that someone has already noticed and decided to document. It misses accumulating debt (complexity that's slowly rising in systems nobody reviews). It misses debt in areas nobody has looked at lately. It misses debt that quietly resolves itself when things get refactored for completely unrelated reasons.
The ticket-based model is incomplete. What you need is a full lifecycle: continuous detection, triage, prioritization, remediation, and verification.
The Five-Stage Lifecycle
Stage 1: Continuous Detection
Technical debt doesn't announce itself. It accumulates. A method grows from 20 lines to 50 to 120. A module's dependency graph gets more complex. Test coverage drops. Code churn in a system spikes. These are signals of accumulating debt.
Detection has to be automated. Not because humans are bad at noticing, but because humans notice only in code they're actively working on. Meanwhile, debt in code that nobody touches for six months keeps accumulating.
Continuous detection means running metrics regularly (ideally weekly or even daily) on your codebase. You're tracking:
- Complexity metrics (cyclomatic complexity, cognitive complexity)
- Coupling (how many other modules depend on this? How many does this depend on?)
- Coverage (test coverage trending up or down?)
- Change frequency (how often is this code being modified? Is it stable or volatile?)
- Size (are modules growing? Are they growing faster than they're being refactored?)
The goal isn't to find the worst code. It's to find code where debt is accumulating, regardless of where the code starts. A module at 90 complexity might be fine if it's been stable for three years. A module that went from 20 to 50 complexity in the last six months is a signal: something is getting harder to maintain.
Stage 2: Triage
Not all technical debt matters equally. A complex utility function that nobody touches? Probably not urgent. A complex service that's growing in responsibility and running on unstable infrastructure? That's different.
Triage means classifying debt by business impact, not just technical severity.
Ask: Does this debt slow us down in code that matters to the business right now? Is this in a critical path? Does fixing it directly unblock a roadmap item?
This is where PM input matters. Engineering can surface the technical signals. But the business context - which systems are critical to product velocity, which are foundational but stable - that comes from product leadership.
Debt gets triage labels: "Critical" (blocks roadmap items or causes frequent incidents), "High" (in systems we actively develop), "Medium" (in systems we touch occasionally), "Low" (isolated, rarely-touched, stable).
Stage 3: Prioritization
This is where ticket tracking usually stops. Debt gets prioritized by severity, and then it waits in the backlog for bandwidth that never comes.
A better model: prioritize debt by impact and opportunity cost.
Impact is straightforward: does this debt cause pain? Does it slow down development? Does it cause incidents?
Opportunity cost is more subtle: if we fix this debt, what becomes faster or cheaper? If we have a 30-person engineering team and fixing this would save two hours per week per developer, that's 60 engineering-hours per week recovered. That's massive.
Pair this with strategic timing: certain debt items are "pair with feature work" opportunities. If you're already refactoring a module for a roadmap item, the marginal cost of fixing technical debt in that same module is lower. Prioritization should account for this.
Stage 4: Remediation
This is where implementation happens. The key: clear scope and completion criteria.
Ticket-based tracking often creates ambiguity here. A ticket says "reduce complexity in payment module." But what does done actually look like? Complexity below X? Coverage above Y? Zero incidents in three months?
Remediation work needs explicit criteria. Examples:
- "Reduce cyclomatic complexity from 45 to below 30" (specific, measurable, clear whether it's done)
- "Increase test coverage from 62% to 80%" (same)
- "Reduce average response time for customer queries from 800ms to below 500ms" (ties to business impact)
- "Break this 3500-line module into three separate, independently-testable modules" (structural, clear)
These create a contract: when these criteria are met, the work is done. It removes the ambiguity that usually plagues technical debt work.
Stage 5: Verification
Here's where most technical debt work falls apart. A ticket moves to "Done." Everyone moves on. Three months later, you're hitting the same problems.
Verification means checking whether the underlying signal actually improved. You don't just verify that the code changed. You verify that the metric that triggered the debt signal now shows improvement.
If you flagged debt because complexity was too high, you check: did complexity decrease? And not just decrease - did it decrease to the threshold you set as "done"?
If you flagged debt because coverage was too low, you verify coverage is now in range.
If you flagged debt because incident rate was high, you verify that incidents in this system actually decreased after the fix.
This is critical. Sometimes code changes don't actually fix the underlying problem. You refactor complexity but the real issue was missing tests. You add coverage but the underlying architectural pattern that causes incidents is still there. Verification catches this.
How This Differs from Ticket Tracking
The ticket-based model:
- Someone notices something's wrong
- Ticket gets created
- Eventually, someone works on it
- Ticket moves to Done
- Done means done, usually
The lifecycle model:
- Automated signals continuously detect emerging debt
- Triage classifies it by business impact
- Prioritization considers impact, opportunity cost, and strategic timing
- Remediation work happens with explicit scope and completion criteria
- Verification confirms the underlying signal improved
- If verification fails, the work isn't done (it stays in the loop)
The difference: the lifecycle model is feedback-driven. It doesn't assume that closing a ticket means the problem is solved. It verifies it.
Implementation: What This Looks Like in Practice
You don't need to overhaul everything at once. Start with one system or one team.
- Pick a module or service with known debt. Generate metrics (complexity, coverage, change frequency, dependency count).
- Set a target state: "Reduce complexity to X, coverage to Y."
- Run detection weekly. Surface signals to the team.
- Triage once a month: "Of the signals we're seeing, which ones matter for our business?"
- Prioritize: "Which items should we tackle next quarter?"
- Remediate: Clear scope, explicit criteria.
- Verify: Run the same metrics 30 days after remediation. Check that signals improved.
After one cycle, you'll see impact. Debt that gets addressed actually stays addressed. Emerging debt gets caught before it becomes a crisis. And teams understand that technical debt work has outcomes, not just effort.
Frequently Asked Questions
Q: How do we measure technical debt quantitatively?
Common metrics: cyclomatic complexity, cognitive complexity, test coverage, lines of code per method, dependency counts. Tools like SonarQube, CodeClimate, or codebase intelligence platforms provide these. The key: pick metrics that correlate with actual pain (slow development, high change failure rate) rather than metrics that sound important but don't matter.
Q: What if we can never find time to remediate debt?
That's a process problem, not a time problem. If you never fix debt, either (1) you're not tying it to business impact (you're not seeing how it slows feature work), or (2) you're treating it as an optional nice-to-have rather than strategic. Debt remediation should be 15 - 25% of your roadmap. If it's not, you're kicking the can.
Q: Should technical debt work be tracked in the same backlog as features?
Yes. It's work. It has impact. It should be prioritized alongside features, not separately. The risk of separate tracking: debt backlog gets deprioritized indefinitely. Mixing them forces prioritization decisions: "Which matters more - this feature or this debt work?" That's the right conversation.
Q: How do we prevent debt from accumulating in the first place?
Three mechanisms: (1) code review standards (don't let complexity grow without pushback), (2) architectural guardrails informed by dependency mapping (this is where this type of code should live; if it doesn't, that's a signal), (3) refactoring as part of feature work (when you touch code, improve it). Detection helps with awareness. Prevention requires discipline and standards.
Related Reading
- Technical Debt: The Complete Guide for Engineering Leaders
- Code Refactoring: The Complete Guide to Improving Your Codebase
- DORA Metrics: The Complete Guide for Engineering Leaders
- Software Productivity: What It Really Means and How to Measure It
- Code Quality Metrics: What Actually Matters
- Cycle Time: Definition, Formula, and Why It Matters