The Technical Debt Game

Technical Debt

Every software project has it. Technical debt in a software project is essentially a backlog of technical stories the development team thinks need to be completed that are not visible to the product owner and don’t directly implement user features. These stories arise from either the inevitable trade-offs made during rapid implementation, or from inadvertent discoveries after implementation that some code should be refactored. By itself, technical debt is not a bad thing. It’s more prudent to “minimally” implement some features to get rapid feedback, and only later more fully flesh-out the implementation after requirements are more clear.

Impact of Technical Debt

Technical debt has a constant impact on the efficiency of the development team. Technical debt makes completing feature stories more difficult than it would otherwise be. Technical debt can make the code base more difficult to understand and can lead to a higher defect rate. Perhaps the most frustrating aspect of Technical Debt is that it is very difficult to quantify its impact. This makes it difficult for the development team to make the case with their Product Owner for reducing tech debt. The development team is usually left using financial (or even food) metaphors to help convey why tech debt stories should be tackled sooner rather than later.

The Tech Debt Game

Technical Debt Game-Agile Velocity


To help demonstrate and better understand the trade-offs and various strategies tech debt can have, my colleagues and I have developed a “Tech Debt Game” which can be used to simulate development iterations with both feature backlogs and technical debt backlogs. Players can try out different strategies of dealing with the tech debt with the goal of completing the most feature story-points. This game can be used as a way to demonstrate the impact of technical debt and help start the conversation with Product Owners and other external stakeholders.

Get the Tech Debt Game

Join the discussion 4 Comments

  • Dennis says:

    Why does the Technical Debt card have an Impact and a Cost?

    In the example, the entire technical debt (from the 5 cards) is absorbed in the 1 st iteration. So for the rest of the game (4 iterations), the team only has to work on the tech debt from the Iteration card?

    Does the team have to do all the technical debt in the 1st Iteration or can the debt be spread across the 5 Iterations?

    How are the 2 extra tabs in the Chart speadsheet to be used?

  • Tung Nguyen says:

    hi David,

    I’m very interested in your topic about Technical Debt, especially the game. But honestly, I haven’t understood how the game running. And having the same question to Dennis. Could you help me to get clearly?

Leave a Reply