How do you manage Technical Debt?


If you search on the Internet you’ll see plenty written about Technical Debt. It’s something that all software development teams have to come to terms with. Technical Debt is metaphor coined by Ward Cunningham that attempts to describe the effects of delaying software rework/updates in a similar way to accumulating financial debt. The debt needs to be paid back or it will accumulate.

A key aspect to managing Technical Debt is to make it visible, don’t hide it away. It is something that can affect the efficiency of the team and simply ignoring it will have the compound interest effect that will take greater effort to resolve. Some Technical Debt is manageable within a sprint but larger Technical Debt needs to be communicated and planned for in a future sprint or release. To make Technical Debt visible the team should adopt the habit of raising awareness of even small Technical Debt during stand-up and larger items should be regularly discussed during Sprint Reviews. From a Project Management point of view consider Technical Debt similar to Risk – we can have an action plan to mitigate but the proximity and impact needs to be clearly understood.

 I like to think of having three types and three sizes – note that "Planned" and "Unplanned" are our classification, not how the technical debt is managed!


  • Planned – this type of technical debt occurs when the team makes an informed decision to generate some technical debt with the full understanding of the consequences. In the case of planned technical debt, it is important to communicate to all stakeholders the impacts of this decision, any associated risks and the plan to remedy.
  • Unplanned – unavoidable debt occurs due to changes of business priorities and/or updates to technology over time that present better solutions. If we attempted to solve a problem now and at a later time then it’s very likely that our proposed solutions would be different based on available technology (and versions of these) and the business priorities that are driving the requirements. This is a major teaching as to why to adopt Agile rather than waterfall as the latter tends to freeze both technology choice and business priorities for a significant duration. Agile doesn’t eliminate this problem completely so we can expect to create technical debt when new technology choices/versions and/or business priorities make old code obsolete.
  • Entropy – software entropy occurs over time as the software quality slowly deteriorates. Symptoms of entropy could include usability issues, errors and/or problems updating software. Entropy can occur when developers may not understand the intended function and design and add complexity to and/or unintentionally break the original code. The solution to software entropy is refactoring.


  • Small – something that can easily be dealt with within the sprint
  • Medium – something that needs to be planned in a sprint
  • Large – something that needs to be included in the Roadmap

I would hope that any Unplanned/Large technical debt would be spotted as early as possible(!) but hopefully this will give you a framework to discuss technical debt within your teams.


How To-Best Practice
Comment List
Related Discussions