Technical Debt Review

Purpose: Surface, prioritize, and budget paydown for technical debt that's slowing the team

How to run this meeting

Technical debt reviews fail when they become a complaints session with no business connection. The antidote is quantification: estimate every debt item in developer-hours of impact (time lost to workarounds per sprint) and in incident risk (has this area caused an outage in the last 12 months?). When you can say "this legacy auth service costs us 6 engineer-hours per sprint in workarounds and has caused 2 incidents this year," it becomes a real prioritization conversation instead of a vague wish list.

Use a severity matrix to force prioritization. A simple 2x2 of "impact on velocity" vs. "cost to fix" is enough to generate a defensible priority order. High impact, low cost to fix items should be immediate targets. High impact, high cost items belong in a roadmap conversation. Low impact items should be logged and revisited quarterly, not acted on now. This prevents the common failure mode of spending weeks on technically interesting but low-leverage refactors.

Connect debt to business outcomes in the language your stakeholders understand. "We can't ship the enterprise SSO feature without refactoring the auth layer first" is a conversation that gets prioritization. "The auth code is messy" is not. Budget a recurring allocation — most teams that successfully pay down debt reserve 10–20% of sprint capacity for it, run it as a dedicated quarterly "debt sprint," or attach debt paydown to features that touch the affected area. Whichever model you choose, make it an explicit commitment, not a "we'll get to it when things slow down" aspiration.

Before the meeting

• Ask engineers to submit debt items 48 hours in advance using a standard template (description, estimated impact in hours/sprint, risk level)
• Pull incident and bug data to identify hotspots — code areas with repeated incidents are debt candidates by definition
• Review previous debt review action items and their status
• Prepare a scoring rubric (velocity impact, incident risk, cost to fix, business dependency) so the meeting can prioritize consistently
• Invite the engineering lead and one product stakeholder — debt decisions benefit from both perspectives

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes
• Review period:

---

Debt Inventory

All known debt items under discussion. Capture a plain-language description of what the debt is and where it lives in the codebase.

---

Impact Assessment

For each item: how much is this costing the team today? Estimate in developer-hours lost per sprint and note any incidents caused by this area.

---

Cost to Fix

Rough estimate of engineer-hours or sprint capacity required to address each item. Note any dependencies or risks in the fix itself.

---

Priority Matrix

Combine impact and cost to generate a priority order. Use this to make explicit tradeoffs rather than gut-feel ordering.

---

Owners and Paydown Plan

Who is responsible for each prioritized item, and when will it be addressed? Define the budget allocation.

---

Action Items

Follow-up

The debt inventory is maintained in the engineering wiki and updated after each review. P1 items are added to the active sprint or the next sprint immediately after this meeting. The debt review is held quarterly (or after any major incident that reveals a systemic gap). Progress on P2/P3 items is checked at the next quarterly review. Share a summary with the product team so debt costs are visible in roadmap conversations.