What is technical debt? Technical debt falls into a few main categories: coding something quick and dirty often to increase time to market; an outdated design; spaghetti code or bit rot where code has been added to repeatedly often by multiple developers.
In all cases the only solution is to refactor the code to both simplify and modernize it. The problem is refactoring code does not introduce new features and so it can be difficult to convince a product owner or management of the importance of refactoring, as there is no obvious or immediate value. Hence it often is left unaddressed and carried forward as debt, that becomes difficult to “pay off” over time.
It is important for the whole team including the product owner to understand that this debt is owned by the whole team. Like any debt that must be paid, there are really only two ways to accomplish this: either by paying it down in small increments or paying it off all at once. The advantage to paying it off over time in small increments is that it hurts less in any given Sprint or Release. This is much akin to paying down a financial debt, meaning you can make regular payments while still being able to make other purchases (in this case additional features). The alternative is to pay it off all at once, which while hurting for the next Sprint or Release allows the team to immediately reap the benefits, reduce their risks and them frees up future capacity that would have otherwise been focused on paying the debt slowly.
If the technical debt is not addressed, it will become harder and harder to maintain the code, and more overhead will be spent working around poor design. The risk of introducing bugs increases and the likelihood of a bug escaping becomes inevitable. At that point the team will be faced with no other option than to refactor only now they are doing it under stress to fix the issue, and the quantity of refactoring is likely greater than if they had worked on it sooner.
Ultimately it is the product owner’s decision as to when to pay down the technical debt, however the rest of the team should be prepared to explain why carrying the debt forward is actually costing the team more in the long run. Only poor product managers will continue developing products with such a shaky foundation without negating the risks it brings.