Technical Debt Register
A register that turns technical debt into rows a leadership team can rank and decide on, each with an owner and a review date.
Open to everyone. Nothing is sent when you use it.
What the workbook holds
- Register: one row for each item, with the system, a sentence on why the debt exists and its kind
- Scores for impact on delivery, risk if left and effort to fix, each on a short scale
- A priority score and rank worked out for you, with ties broken by row order
- A decision for every item, with an owner, a status and a review date
- Lists of kinds, from code and architecture to data, documentation and dependencies, plus decisions and statuses, all editable
- Summary: items not yet closed, counted by decision, and the highest-ranked items
Filling it in
- 01
Write the debt as a cause
Say why it is there as well as what it is. Rules copied across modules after a rushed launch can be fixed; a line that calls the code messy cannot.
- 02
Let the right person score each column
The engineer who would do the work scores effort. The product owner or head of delivery scores impact. Whoever answers for an outage scores risk.
- 03
Give every row an owner and a date
A row without an owner is a complaint. The review date is what makes it a decision.
What the score cannot see
The score is impact times risk, divided by effort, so cheap fixes rise and a severe item with a large fix can sit below a trivial one. The register holds only debt someone has noticed. To find what nobody has named, start with the Technology and Architecture Risk Assessment. It is a working aid and not an audit.
On this page
What each decision commits you to
Every row ends in a decision. Each decision carries an obligation, and the register is only useful if the row shows it.
| Decision | Choose it when | What the row must then show |
|---|---|---|
| Fix now | The risk is live and the fix is within reach of the people already on the work | An owner, and the work in the current plan |
| Schedule | The debt slows delivery but nothing fails without warning | A slot in a named release, and the person who protects it from being traded away |
| Monitor | The cost is real but the trigger has not been reached | The signal that would move it up, and who watches for it |
| Accept | Fixing it costs more than living with it | A written reason and a review date, so acceptance is a decision and not neglect |
What do people ask before using the technical debt register?
Who should score each item in the technical debt register?
Let the person best placed to know score each column. The engineer who would do the work scores effort, the product owner or head of delivery scores impact, and whoever answers for an outage scores risk. Each score then comes from someone who can defend it.
How does the register rank technical debt?
The priority score is impact times risk, divided by effort, and the rank puts the highest score first. That means cheap fixes rise, and a severe item with a large fix can sit below a trivial one. Read the highest-risk rows on their own before you plan.
How should I describe an item of technical debt?
Say why the debt is there as well as what it is. Rules copied across modules after a rushed launch can be fixed, while a line that calls the code messy cannot. Name the system, state the cause and pick the kind of debt, such as code, architecture or data.
What should happen to an item once it is ranked?
Give it a decision, an owner and a review date. A row without an owner is a complaint, and the review date is what makes it a decision. Fix now, schedule, monitor and accept each carry an obligation, and accepting needs a written reason.
Facing debt that keeps growing?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.