# Technical Debt Assessment

> Identify, classify, and prioritize technical debt for strategic remediation.

## When to Use
- Sprint planning (how much debt to pay down)
- Major refactoring decisions
- "How much tech debt do we have?"

## Debt Categories
- **Deliberate/Prudent:** "We know this is a shortcut, ship now, fix next sprint"
- **Deliberate/Reckless:** "We don't have time for design" (highest risk)
- **Inadvertent/Prudent:** "Now we know what the design should have been"
- **Inadvertent/Reckless:** "What's layering?" (requires education, not just refactoring)

## Assessment Approach
1. **Inventory** — list all known debt items (code, infrastructure, documentation, tests)
2. **Classify** — by category and component
3. **Estimate interest** — how much ongoing cost does each item create? (bugs, slow development, onboarding friction)
4. **Estimate remediation cost** — how long to fix properly?
5. **Prioritize by ROI** — fix items where (interest saved / fix cost) is highest

## Debt Inventory Template
| Item | Category | Component | Interest (hrs/sprint) | Fix Cost (hrs) | ROI | Priority |
|------|----------|-----------|----------------------|----------------|-----|----------|
| No test suite | Testing | Backend | 8 | 40 | 0.2/sprint | High |
| Hardcoded config | Config | Deployment | 2 | 4 | 0.5/sprint | Quick win |
