Support as a metric for technical debt in scrum sprints

7 October 2009 by Rod McLaren

Israel Gat has an interesting post on technical debt as a measurable metric in agile software development, and cites a Sonar plugin which gives debt a financial value (how? “the debt is first calculated on the basic axis: Duplication, Violations, Complexity, Coverage and Documentation”). Gat:

Monetizing technical debt can have two far reaching implications, as follows:

• A credit limit on technical debt can be established. For example, when the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team applies itself to aggressive refactoring to reduce the debt to an acceptable level.
• For companies who capitalize software, technical debt could become a line item on the balance sheet. It will simply be listed as a liability.

From a customer perspective, the monetized technical debt on the balance sheet of a software vendor is a proxy for the technical risk involved in licensing software from this vendor.

We don’t track debt in this detail, but we do something else.

Our talented development team both creates the products/services we provide to our customers and supports them. Because time spent working on support can be an opportunity cost and a disruptive interruption to the team and sprint, we track the support work required during sprints.

We track a rolling average of support work across the last few sprints, and use that to set a support “budget” at the start of each sprint. Support calls during the sprint draw against that budget. We then try to hold – or better, reduce – the amount of support work from one sprint to the next, even though the number of customers we support is increasing. Estimating and tracking support work is thus a proxy for measuring technical debt. This is admittedly a pretty indirect way of keeping visible technical debt, but it has the virtue of a low measurement burden.

This supportability principle also makes us wary of pushing features out too quickly or with insufficient quality, and keeps us focused on important business factors – reduced support activity obviously being good for customers’ continuity or service and confidence in the products and our bottom line.

Jira, Greenhopper, Lighthouse: tools vs practice in Scrum BlackBerry cost savings at Bedfordshire and Thames Valley