Technical Debt: Pay it now, or pay it later!

The concept of software complexity and deferred refactoring as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ‘92. It has since become an industry wide concept and is a commonly referenced and applied when practicing scrum and agile.
Technical debt is deferred work not directly related to new user story features, but necessary for the overall quality of the system. Examples of technical debt include delaying upgrades to necessary tools and frameworks, delaying the refactoring of overly complex or crude system components, etc. etc.

The problem with technical debt is that it will reduce the velocity of the team, and the quality of the software produced on a greater basis the longer it is ignored and / or deferred (just like only making the minimum payment on a credit card debt).
So now that we have an understanding about technical dept, and the problems caused by it, we can discuss an approach to solving this age old application development and maintenance issue.

Since Scrum teams are supposed to operate in a transparent manner, and the product owner is a full partner with the scrum team, the details of the technical debt that exists and is accruing in a product needs to be visible to and understood by the product owner.
Key technical debt items need to exist in the product backlog. Additionally, the ongoing impact to product quality and scrum team velocity by continuing to defer their resolution needs to be clear to the product owner so that the product owner may rightly prioritize these items in the product backlog.

Additionally some team adopt the notion that in each iteration or predefined number of iterations, a technical debt tax of some number of story points will be included during the sprint planning process. This assures that the most important technical debt items will be addressed when they exist in the backlog, and hopefully the “technical debt balance” will never get to the point where it takes too big of a bite out of a particular iteration or set of iterations.

Also, once the concepts of identifying technical debt and continuing to pay it down on a regular basis are in place, the scrum team becomes very sensitive to these issues, and very cleaver and effective in how it deals with them.

Therefore consistent and thoughtful application of these best practices associated with the management of technical debt will result in better software quality, improved team velocity, a happier and better informed product owner and a less stressed out scrum team! All in all, not a bad deal really.

As always, Paul