How do scrum teams manage technical debt?
Technical debt is a metaphor that leans on the idea of financial debt. As financial debt increases, the ability to repay the debt is reduced. Once the debt exceeds the ability to repay, bankruptcy occurs. So, how do scrum teams manage technical debt?
Over time decisions are made either by the product owner or by the development team to build a part of (or whole) the system in a less than optimal way, or the team may have sacrificed quality by design or by ignorance. These decisions remain in the system and the effects accumulate over time.
As technical debt accumulates, the ability to maintain and change the system is reduced and the cost of adding new features increased. This culminates when the system can no longer be maintained at reasonable cost or speed, to meet the business needs and expensive re-platforming or re-writes are required.
Examples of technical debt
Cut and pasted or duplicate code
Untested code
Unreadable code
Out of date documentation
Dead code (code that never runs)
What to do about existing debt
Unless you’re yet to break ground on a new product idea the chances are you already have a certain amount of technical debt. Some debt will be well understood already and can easily be identified. Other debt will take a little analysis. There are a number of tools available that can help specifically with this.
The important thing to do is to add items to the product backlog to enable technical debt to be prioritised by the product owner and to be addressed in future sprints.
Technical debt does not need to be written as a user story but should have sufficient information to enable someone to return to the product backlog item (PBI) in the future and still understand what the issue is and the value of fixing it.
How to stop creating debt
The key mechanism in Scrum to drive higher quality standards is the definition of done. The definition of done should be reviewed frequently during sprint retrospectives and added to. Typically, as teams look to eliminate technical debt, they’ll add some of the following to their definition of done:
Automated acceptance test
Automated unit tests
Refactored code
Use of patterns
Clean code
Clean architecture
Successful build
Integrated