How we track technical debt
Our approach
At GoodFit, we take a pragmatic approach to tracking technical debt — "tech debt" from here on. We only track tech debt that has a meaningful impact on our ability to deliver product value effectively. This means we focus on debt that:
- Slows us down in development or deployment
- Decreases system stability or maintainability
- Introduces a potential security risk
- Increases infrastructure costs to an unacceptable amount
We do not track tech debt purely in the name of perfection — tidying that has no material effect on performance, security, or velocity.
Where we track tech debt
All tracked tech debt items are recorded on the Tech Debt Radar — our Product and Engineering Backlog board in Jira (PEB).
The radar is the single place we look to answer "what debt do we know about, and what hurts most right now?". Anything not on the radar is not being tracked, so raise it there rather than keeping a private list.
What each item should include
Each tech debt entry should contain the following:
-
Problem Description Clearly explain what the issue is and where it exists in the system.
-
Risk of Inaction Outline what could happen if we leave this unaddressed — e.g., slower delivery, instability, or potential security exposure.
-
Suggested Approach Describe possible paths to remediation, including high-level ideas, refactors, or tooling improvements.
-
RICE Score The numbers behind the item's priority, plus a one-line justification for each (see below).
Scoring with RICE
Every item on the radar is scored using RICE, so we can compare debt items against each other with something better than gut feel:
RICE = (Reach × Impact × Confidence) / Effort
| Factor | What we mean | How we score it |
|---|---|---|
| Reach | How many people or things are affected per quarter — engineers, customers, pipelines, services | A count (e.g. 8 engineers, 200 daily pipeline runs) |
| Impact | How badly each of those is affected when it bites | 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal |
| Confidence | How sure we are of the reach, impact and effort estimates | 100% high, 80% medium, 50% low |
| Effort | Total work to remediate | Person-weeks |
Scores are estimates, not measurements. The point is a consistent, comparable ordering — not precision.
Worked example
Flaky integration test suite blocks merges
The integration suite fails intermittently, forcing re-runs before anything can merge.
| Factor | Value | Justification |
|---|---|---|
| Reach | 8 | All 8 engineers hit it multiple times a quarter |
| Impact | 2 (high) | Blocks merges and erodes trust in CI, but there is a workaround (re-run) |
| Confidence | 80% | We know the symptom well; less sure the fix lands in one go |
| Effort | 2 | Roughly two person-weeks to isolate and stabilise the flaky cases |
RICE = (8 × 2 × 0.8) / 2 = 6.4
That 6.4 sits next to every other scored item on the radar, so we can see at a glance where it ranks.
Review and prioritisation
We realign the radar every quarter. In that review we:
- Re-score existing items — reach, impact and effort all drift as the system and team change
- Add debt discovered during the quarter
- Drop items that are no longer relevant, or that have been resolved as a side effect of other work
Each team then allocates a portion of its capacity per quarter to picking up tech debt, and works down the radar in RICE order. Having the allocation agreed up front means debt is planned work rather than something we hope to squeeze in.
Outside of that allocation:
- Items that become high-impact, or that align naturally with ongoing feature work, are pulled into the delivery backlog as normal
- Small "quick wins" can be picked up by developers when they have gaps in other work streams
Throughout, we stay pragmatic — the radar and the RICE scores exist to help us make good calls, not to be followed mechanically.