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
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.
