Technical Debt Prioritization: A Scoring Rubric for What to Fix First

Technical debt prioritization works best when you turn vague feelings into numbers. Use a simple matrix: multiply each debt item's estimated blast radius by its observed change frequency. The result tells you exactly which piece of code to tackle next.

1. List every debt item you can see

1. Scan the codebase, issue tracker, and recent post-mortems. 2. Write each item on a spreadsheet with columns: description, file/module, last touched date, known bugs. 3. Output: a master list of debt items, e.g., "legacy auth helper" or "hard-coded timeout in payment service".

2. Estimate blast radius for each item

1. Ask: if this code fails, how many users, services, or revenue streams are affected? 2. Score 1 (local impact) to 5 (system-wide impact). 3. Output: a numeric blast radius column. Example: the payment timeout touches checkout, invoicing and analytics → score 4.

3. Measure change frequency

1. Pull git log for the file/module over the past 90 days. 2. Count distinct commits that modify it. 3. Convert to a 1-5 scale (0-1 change =1, 2-3 changes =2, 4-6 =3, 7-10 =4, >10 =5). 4. Output: a frequency column. Example: the auth helper changed 8 times → score 4.

4. Compute the priority score

1. Multiply blast radius by frequency. 2. Sort descending. 3. Output: a priority column and a ranked table. In the example, 4 × 4 = 16, likely the top-ranked item.

5. Turn the top-ranked items into actionable tickets

1. For the highest score, create a ticket that includes: description, current defect, desired state, estimated time, and test plan. 2. Link the ticket to the rubric row for traceability. 3. Output: a ready-to-work ticket, e.g., "Refactor payment timeout to configurable value (estimate 3 h)."

Worked example: triaging a small SaaS codebase

You have three debt items: - Legacy auth helper (blast 4, frequency 4) → score 16. - Inline CSS in admin UI (blast 2, frequency 2) → score 4. - Unused feature flag library (blast 1, frequency 5) → score 5. The rubric ranks the auth helper first. You open a ticket, attach the rubric row, and schedule a two-hour refactor in the next sprint. After the change, you log actual time (2 h) and update the spreadsheet, keeping the model calibrated.

The process took under an hour of planning and produced a clear, data-driven priority list.

What usually goes wrong and how to fix it

1. Ignoring hidden dependencies – run static analysis or dependency graphs before scoring; adjust blast radius if downstream services are discovered. 2. Over-estimating frequency – use a rolling window and exclude trivial formatting commits; otherwise low-impact code inflates its score. 3. Sticking to the score without context – if a high-score item blocks a regulatory release, bump it; if a low-score item is a security hole, override the rubric. 4. Not revisiting the matrix – schedule a quarterly review to refresh scores as the system evolves.

A disciplined review prevents the rubric from becoming a static checklist.