Scrum Exposes Technical Debt Through Forecasts & Estimates
As a general rule, technical debt increases the cost of future work on the product. So, even if you don't explicitly keep track of the debt, it will typically show as a drag on metrics such as the team's velocity over time.
Technical debt will probably also impact your team's estimates of Product Backlog Items (PBIs) during Sprint Planning, as crufty code (and debt-ridden products in general) are intuitively higher-effort.
Making Technical Debt Explicit
Even though Scrum implicitly exposes technical debt through velocity, and also reflects it within PBI estimations, it's often better to track the debt explicitly on the Product Backlog. Some reasons to do this include:
- Clarifying what work needs to be done within the project to pay down the debt.
- Enabling the Product Owner to make trade-offs in prioritization between technical debt and new features.
- Providing stakeholders transparency into the hidden costs of the product's development.
- Keeping the project honest by treating work as work. Technical debt is just another kind of work that remains to be done.
- Honoring CodeGnome's Law of Transparency: "No invisible work, ever!"
If you treat technical debt simply as work to be prioritized, as opposed to some special kind of non-work work, then the Product Backlog it certainly the right place for it.
How to Write PBIs for Technical Debt
Create PBIs for the technical debt the same way you would for any other type of work. The PBIs should be written at whatever level of granularity would be appropriate for the work's level of prioritization within the backlog.
For example, you might keep some valuable but non-essential refactorings as an epic for "someday." In contrast, essential patches or rework should be written as individual user stories when the team is ready to decompose the work during Sprint Planning, or during Backlog Refinement when the work is likely to be in scope for an upcoming Sprint.