Tech-debt backlog

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Replace the hand-rolled date utils with a library

  • refactor
  P25pt

• De-flake the billing integration test suite

  • flaky-test
  P13pt

• Delete the dead feature-flag scaffolding

  P32pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Issue labeled 'flaky-test'

  Then

  Tag the owning team and add to the next debt-paydown slot

• When

  Item sits in 'Logged' for 60 days

  Then

  Surface it in the monthly debt review for a keep-or-cut call

Scheduled is the column that makes this board different from a complaints box. Every engineering organisation can produce a list of things that are wrong with its codebase; almost none of them reserve capacity to fix any of it, which is why those lists are usually just a record of shared frustration. Putting a state between 'we agree this is bad' and 'someone is working on it' forces the only decision that matters — whose cycle does this come out of — to be made explicitly rather than deferred forever.

1. 1.Log the pain, not the fix

   Write what it costs: how often it bites, who it slows down, what broke because of it. 'Refactor the notification module' is a proposal with no argument attached; 'every change to notifications takes two days because the tests are unreliable' is a case. Debt items compete against features for capacity, and features always come with a business argument, so debt needs one too.

2. 2.Scope before you schedule, and be honest about the range

   Scoped means somebody has looked and can estimate. Unscoped debt loses every prioritisation conversation to a scoped feature, not because it matters less but because nobody will commit unknown capacity. If the honest estimate is 'somewhere between three days and three weeks', say that and timebox an investigation first.

3. 3.Reserve a fixed fraction of each cycle and defend it

   Pick a proportion — many teams land somewhere around a fifth — and treat that capacity as booked rather than available. The reason to fix the fraction in advance is that the case for postponing debt work is always locally compelling, and made afresh every cycle it wins every time. A standing allocation converts an argument you would lose repeatedly into a decision made once.

4. 4.Cap Paying down at three so refactors actually land

   Half-finished refactors are worse than the debt they were meant to remove: now the codebase has two patterns and a partially migrated middle. Three concurrent items is generous. If your team routinely has more open than that, the cap is not the problem — the sizing is, and the items need breaking down into independently completable pieces.

5. 5.Let the sixty-day nudge force a keep-or-cut decision

   Something logged two months ago that nobody has scoped is telling you something true: it is not actually painful enough to fix. Deleting it is a legitimate, healthy outcome and it should happen often. A backlog that only grows becomes unreadable, and an unreadable debt backlog gets ignored wholesale, including the items that mattered.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• The debt is one large rewrite. Replacing a system is a project with a plan, a migration strategy and a rollback path — not a backlog item that will be picked up in a spare cycle. Treat it as a project, resource it as one, and be honest that incremental capacity will never finish it.
• Nobody will reserve capacity. Without the Scheduled step actually being used, this board becomes a well-organised record of everything the team is unhappy about and cannot change, which is corrosive rather than neutral. If the answer is genuinely 'never', the honest move is to stop maintaining the list.
• You cannot articulate the cost. Debt that only irritates aesthetically is preference, and preference dressed as debt makes the whole backlog easier to dismiss. Keeping the bar at demonstrated cost is what preserves the board's credibility with whoever approves the capacity.
• The debt is a symptom of a missing practice. If new debt accumulates faster than you pay it down, the leverage is upstream — review standards, test coverage, ownership boundaries — and a paydown backlog is bailing rather than fixing the leak.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Linear

  The common Linear pattern is a label on the main backlog rather than a separate board, so debt competes directly with feature work in one ordered list. That has a real virtue: there is exactly one queue and one prioritisation conversation, and debt cannot be quarantined into a place nobody looks.

  Where Linear is better: A single prioritised backlog is arguably the more honest model, because it forces the trade-off every time rather than hiding it behind a capacity allocation. Teams with strong prioritisation discipline often do not need a separate board at all.

• Jira

  Jira handles this with a debt issue type, custom fields for pain and effort, and JQL filters that can slice the backlog by component or team. With a bit of configuration it will also report on how much capacity actually went to debt per sprint, which is the number this practice lives or dies by.

  Where Jira is better: For measuring the ratio of debt work to feature work over time — the evidence you need to argue for the allocation — Jira's reporting answers it and a board does not.

• SonarQube and Code Climate

  Static analysis tools measure debt rather than collecting opinions about it: duplication, complexity, coverage gaps and rule violations, computed continuously and attributable to specific files. That is a genuinely different and complementary input to a hand-curated backlog.

  Where SonarQube and Code Climate is better: Automated measurement finds debt nobody thought to log, and it tracks the trend without anyone maintaining a list. The best arrangement is usually the analysis tool for detection and a board like this for the items a human decided to act on.