Technical Debt Assessment for Engineering Teams

Rate where tech debt slows your team down and whether you're paying it off.

Try this health check live

What does a technical debt assessment measure?

Ward Cunningham coined the technical debt metaphor in his 1992 OOPSLA experience report, writing that "shipping first time code is like going into debt." A little debt can speed you up. The trouble starts when it isn't repaid, and every hour spent working around not-quite-right code becomes interest. Code scanners measure the code. This assessment measures what the team lives with: whether you can see the debt, how much it slows delivery, how healthy the code and systems feel, and whether you're paying it down. Everyone rates each statement privately, then you take the lowest scores into a retrospective and agree on what to fix first.

Dimensions

Visibility

Whether the team knows where its debt is and treats it as real work.

  • Known hotspots

    We know which parts of our system carry the most debt.

  • Tracked with other work

    Debt is tracked in the same backlog as features and bugs.

  • Known cost

    We can explain what our biggest debts cost us in time or risk.

Impact on delivery

How much debt slows down the work the team is trying to ship.

  • Feature speed

    Debt rarely slows down the features we're building.

  • Safe changes

    Changing one part of our system rarely breaks an unrelated part.

  • Fast, reliable builds

    Our builds and tests are fast and reliable.

Code and system health

How easy the code, systems and dependencies are to work with today.

  • Easy to change

    Most of our code is easy to understand and change.

  • Current dependencies

    Our dependencies and platforms are reasonably up to date.

  • Tests support refactoring

    Our tests give us the confidence to refactor.

Paying it down

Whether the team makes steady, agreed progress on reducing debt.

  • Time set aside

    We set aside regular time to pay down debt.

  • Deliberate debt recorded

    When we take on debt on purpose, we record it with a plan to repay it.

  • Shared priorities

    Product and engineering agree on how to split time between features and debt.

When to use this health check

  • When features take longer than they should and the team keeps pointing at the codebase.
  • Before quarterly or roadmap planning, to agree how much time goes to paying down debt.
  • After a big push or a hard deadline, to record the shortcuts you took before they're forgotten.

Tips & tricks

  • Read the lowest group first. Low visibility means you need a debt list before anything else. High visibility with low paydown points to a planning problem, not a code problem.
  • Bring your product manager into the discussion, even if only engineers rate. How to split time between features and debt is a shared decision.
  • Pair the scores with data you already have, such as build times, flaky test counts or incident causes. The assessment shows where it hurts; the data shows how much.
  • Run it next to the DORA Metrics Self-Assessment, the DevOps Maturity Assessment or the Engineering Excellence Maturity Model to see how debt connects to delivery and engineering practice.
  • Repeat it each quarter. A rising score on the paying it down statements is the earliest sign your plan is working.

Frequently asked questions

How do you measure technical debt?
There's no single number. Teams combine code metrics such as complexity, churn and test coverage with delivery signals like build times, failed changes and how long features take. A team assessment like this one adds what tools miss: where the debt actually slows people down. Track the same measures over time rather than chasing a perfect figure.
What are the four types of technical debt?
The best-known split is Martin Fowler's technical debt quadrant. It sorts debt by two questions: was it taken on deliberately or inadvertently, and was the choice prudent or reckless? Prudent, deliberate debt is a known tradeoff with a plan to repay it, while reckless debt tends to pile up unnoticed.
How much time should we spend on technical debt?
There's no standard answer. Some teams reserve a fixed share of every sprint, some schedule regular cleanup work, and some fix debt in the code they're already changing. Pick an amount, make it visible in planning, and run this assessment each quarter to check whether it's enough.
How do you explain technical debt to product managers?
Talk about the interest, not the code. Show how debt slows specific features, causes incidents or makes estimates less reliable, and what fixing it would free up. Running this assessment with product in the room helps, because both sides see the same scores and can agree on what to fix first.
What is an example of technical debt?
A team copies a module to hit a deadline and plans to merge the copies later. Months on, every fix has to be made twice and the copies have drifted apart. Other common examples are outdated dependencies, missing tests around critical code and a slow build everyone works around.
Who coined the term technical debt?
Ward Cunningham introduced the metaphor in 1992, in an OOPSLA experience report on the WyCash portfolio management system. He wrote that "shipping first time code is like going into debt" and that the danger comes when the debt is not repaid. TeamRetro isn't affiliated with Ward Cunningham.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Related health checks