The expression “technical debt” was first used by Ward Cunningham. He drew this analogy to monetary debt, like when we borrow money from the bank, and it accumulates interest and makes the debt grow. However, at some point, we need to make a plan to repay it.
If you’ve never heard this expression before, Martin Fowler wrote this post about it in 2003.
All debt generates interest, and there are different ways to deal with debt. I’ll list some of them here.
Parking lot
Set aside an area on the physical board with a limited number of slots. Each new debt must be recorded on a sticky note and placed in one of those slots. When there’s no space left, the team can’t incur any more debt, so the team must resolve some of the items before creating new debt.
Debt lane
Create a new lane on the team’s physical board. Only sticky notes with technical debt are allowed to move through this lane. Encourage the team to always have at last one item moving through that lane.
This approach makes it easy to visually follow up on how the team is working on its technical debt.
This strategy helps prevent debt from accumulating. However, the team might end up working on debt that isn’t really valuable.
Hardening sprint
A hardening sprint is a sprint in which no new feature is developed. The team works only on software improvements, such as refactoring, automated tests, and performance enhancements. Scrum Alliance’s post “Do We Need a Hardening Sprint?” talks briefly about this.
I would say that a hardening sprint is like using your year-end bonus to pay off your debt. So, you know the debt is there, but you keep waiting for an opportunity. Then, you spend a lot of money to clear it.
Credit limit
Imagine that the team has a credit card with a certain limit. Each new technical debt is like a new purchase made with this card. At every opportunity, when “there’s some money left”, the team can repay part of the debt, as if paying off part of the credit card balance. If the team exceeds the credit card limit, no new purchases are allowed. In this case, the team needs to pay the minimum amount due to be able to use the credit card again.
But paying only that minimum amount will force the team to keep paying interest forever. That is, for each new feature, several adjustments will be required which will cause delays.
Just like a credit card needs to be paid on a monthly basis, the team can set a period to clear the debt.
Working with monetary values helps to keep this analogy clear. The team should set a monetary amount for each purchase, a credit card limit, and the percentage of that limit that will be the minimum amount due.
It gives the team some flexibility to choose to pay off some of the debt right away using its available capacity while keeping it constantly aware that there’s a limit that can’t be exceeded. In this way, the debts don’t keep accumulating.
Conclusion
Incurring debt can be an option for reaching a goal, but it’s important to keep your finances healthy. Paying back the debt often means less interest. On the other hand, not keeping up with your technical debt can mean paying a lot in interest, or the death of your software.
