Tech Debt Tracker

Sixty items is exactly the number where gut-feel prioritization breaks down. Here's a structured scoring model that takes politics out of the decision and gives you an output you can defend to both engineering and product.

The Prioritization Matrix

Score each item on three dimensions, each 1–3:

Priority score = (Velocity Impact × Risk) ÷ Fix Cost

This formula naturally surfaces items that have high impact AND high risk but are cheap to fix — the "quick wins" that build momentum. It also prevents the team from spending a quarter on a heroic refactor that touches one obscure system.

Example: Scoring 60 Items Into Tiers

Item                              Velocity  Risk  Fix Cost  Score  Tier
──────────────────────────────────────────────────────────────────────
Auth token refresh — no retry        3       3       1       9.0   P1
God class: OrderService (2400 LOC)   3       2       3       2.0   P2
Missing indexes on reports table     3       3       1       9.0   P1
No error boundary in checkout UI     2       3       1       6.0   P1
Hardcoded staging URLs in 14 files   1       2       1       2.0   P3
Duplicated validation logic (6x)     2       1       2       1.0   P3
Zero tests on billing module         3       3       2       4.5   P1
Webpack build > 8 minutes            2       1       2       1.0   P3
Manual DB migrations (no rollback)   2       3       2       3.0   P2
Legacy React class components        1       1       3       0.3   P4

Tier Definitions

With 60 items, you'll typically find 8–12 P1s, 15–20 P2s, and the rest in P3/P4. That P1/P2 list is your working debt backlog.

Handling the Business vs. Engineering Tension

Product prioritizes debt that has visible user impact. Engineering prioritizes debt that blocks them. Both are valid — but they're solving different problems.

The framing that works: debt items are velocity tax. A P1 debt item costs you roughly 0.5–1 story point per sprint indefinitely until it's fixed. Paying it off is a one-time cost to recover ongoing capacity.

Translate your top P1s into product language:

• "Zero tests on billing module" → "Every billing change requires manual QA, adding 2 days to every payment feature. The next billing feature is already in the roadmap — let's fix this before we build it."
• "Missing indexes on reports table" → "Reports are timing out for customers with > 10K records. We have 3 enterprise customers in that range today, 12 in the pipeline."

Embedding Debt Paydown Into the Sprint Cadence

The 20% rule: Reserve 20% of sprint capacity for debt. On a two-week sprint with 8 engineers, that's roughly 6.4 engineer-days. Enough to clear one P1 item per sprint.

Operationally: create a recurring "Debt Sprint" story worth 20% of your total points. The team fills it from the top of the P1/P2 backlog. It's non-negotiable — not a buffer for scope creep.

Track debt paydown as a metric in your sprint retrospective. If P1 count is going down over time, you're winning. If it's flat or growing, the 20% allocation isn't enough and you need a bigger conversation with product.

The key insight: a structured score prevents debt from being assigned to whoever shouts loudest in the sprint planning meeting. When an item is P1 with a score of 8.5, that's the answer — not a negotiation.

Product deprioritizes debt cleanup because it gets framed as an engineering preference, not a business problem. The way to win this argument is to stop talking about code and start talking about money, risk, and speed.

Reframe the Problem

Product hears "tech debt quarter" as: engineering wants to stop shipping features. That's the wrong frame.

The right frame: technical debt is a tax on every feature we ship. A quarter of debt cleanup isn't 0 features — it's investing to ship the next 4 quarters faster and with fewer incidents.

Calculate the Cost of Debt

This is the most powerful slide in the business case. Make it concrete:

Step 1: Measure rework time Survey the engineering team (or pull from sprint retrospectives): what percentage of each sprint goes to rework, debugging issues caused by fragile code, or working around bad architecture?

Industry average is 20–30%. If your team says 25%, that's real.

Step 2: Translate to dollars

Team size: 8 engineers
Average fully-loaded engineer cost: $180,000/year
                                  = $3,462/week per engineer

Sprint capacity: 8 engineers × 2 weeks = 16 engineer-weeks per sprint
Debt rework rate: 25% of capacity

Cost of debt per sprint:
  16 weeks × 25% × $3,462 = $13,848/sprint

Cost of debt per year (26 sprints):
  26 × $13,848 = $360,000/year

You're spending $360K per year on work that produces no value. A quarter of cleanup investment (roughly $120K in engineering time) that cuts rework from 25% to 12% pays for itself in 8 months and returns $180K/year thereafter.

Step 3: Incident cost Pull the last 6 months of production incidents from your incident tracker. For each one, calculate: hours to resolve × engineers involved × hourly rate. Add customer impact (churn, SLA credits, sales deals delayed). Most teams find that 2–3 major incidents per quarter trace directly to debt-related fragility.

Before/After Projection

These are projections — be transparent about that. But they're grounded in your actual rework rate, not made up. That credibility matters.

The "What Do We Ship Instead?" Answer

Product will ask what customers miss out on during a debt quarter. Have an answer ready.

The honest answer: customers don't miss a quarter of features — they miss 6–8 weeks of features, because the team still ships. A quarter of 20% debt allocation means roughly 4 months of reduced (not zero) feature output, not a hard stop.

More importantly: list 2–3 features currently blocked or significantly slowed by the debt. "The new reporting dashboard we've been promising enterprise customers for two quarters is slow to build partly because our data layer has no clear ownership. That's a debt problem, not a roadmap problem."

The 1-Page Business Case Structure

HEADER: Engineering Velocity Investment — Q3 2025

THE PROBLEM
• Engineering is operating at ~75% effective capacity
• ~$360K/year in engineering time spent on rework (not new value)
• 3 major incidents in Q2 traced to fragile, untested code
• New engineers take 4 days to make their first contribution

THE INVESTMENT
• One quarter with 40% of capacity on debt reduction (vs. 20% ongoing)
• Approximate cost: ~$90K in diverted engineering time
• Targeted items: [list your top 5 P1 debt items with plain-English descriptions]

THE RETURN (12-month projection)
• +13% engineering throughput → ~3 additional features/quarter
• Estimated incident reduction: 60% fewer P1 incidents
• Onboarding improvement: new engineers productive in <2 days
• Payback period: ~8 months

WHAT PRODUCT GETS
• [Feature A] — currently blocked by OrderService refactor — unblocked in Q4
• [Feature B] — requires database index work — ships 6 weeks earlier
• Fewer rollbacks and hotfixes disrupting roadmap execution

The key is that product needs to see something in it for them — not just an abstract engineering health improvement. Show them which roadmap items ship faster or get unblocked. That's the conversation that changes the outcome.