Technical Debt Tracker Template

Start with 15-20% of your average [velocity](/glossary/velocity). For a team with 30 story points per sprint, that is 5-6 points for tech debt. Adjust based on the severity of your debt. Teams with critical reliability issues may need 30% temporarily. Teams with a clean codebase can drop to 10%.

Three practices help: enforce code review standards (catch new debt before it merges), include tech debt impact in sprint retrospectives (awareness), and track the paydown trend quarterly (accountability). If the inventory is growing despite consistent allocation, the team is accumulating new debt faster than expected. Tighten the [Definition of Done](/templates/definition-of-done-template) to prevent low-quality code from merging.

Engineers own the inventory (they know where the debt is and how severe it is). The PM owns the prioritization conversation (balancing debt against feature work). In practice, the tech lead maintains the tracker and the PM ensures sprint capacity is allocated. Both review it together during [backlog grooming](/templates/backlog-grooming-template).

Use the same prioritization framework for both. Score tech debt items on impact and effort, just like features. A tech debt item that causes weekly production incidents (impact 5, effort 3) should rank above a nice-to-have feature request. The [RICE calculator](/tools/rice-calculator) works for both.

Bugs are incorrect behavior visible to users. Tech debt is internal code quality that makes future development harder or riskier. A payment calculation error is a bug. Using a deprecated payment library that still works but will lose support next year is tech debt. Track them separately because they require different prioritization criteria and different sprint allocation.