"There are no shortcuts when it comes to getting out of debt" - Dave Ramsey
Technical debt can be defined as the longer term consequences of poor design decisions. In a sense it’s like any other debt - there ought to be a clear understanding of why it is incurred, and how and when to pay it back. Sometimes it is genuinely thought to be worth it. For example, “poor design decisions” might be made for the sake of expediency. Continuing with an unscalable architecture might facilitate a delivery to a Product Owner which would otherwise be impossible if redesign was to happen now. There will be long-term costs associated with the delay in taking remedial action, because it will become harder to refactor the architecture the longer it is left in place and used. That’s clearly a kind of debt, because we are borrowing time from the product’s future which will have to be repaid with interest. Yet given the advantage to be obtained by making that early delivery, the choice to take on this debt might be considered to be appropriate and worthwhile.
In an earlier post we looked at how a "technical debt register" can help a Development Team make informed decisions about any technical debt they choose to incur. The register will make the debt transparent and allow it to be managed by the team at the appropriate technical level where it can be remedied. There are of course other ways in which a Development Team might control their debt problem. When very little is owed, it might be sufficient for team members to track what needs to be repaid entirely in their heads. In the case of architectural refactoring the necessity of redesign may be obvious enough, since it may be a pain those developers have to deal with every day.
Another possibility may be to record technical debt on the Product Backlog. Obviously the Product Owner would require a high degree of technical insight for this to work. He or she must be able to understand the nature of the debt and its effect on value, and be able to prioritise such entries in relation to other Product Backlog Items. The Product Owner would also have to be willing to take this debt on in the first place.
It’s important to remember that the Product Backlog is not a dumping ground for the Development Team's technical debt. That debt is owed by the Development Team to the Product Owner and the stakeholders the PO represents. They expect and trust the Development Team to do the right thing, always, at a technical level. The Development Team has a right to assume technical debt if they believe that it is indeed the correct thing to do in a given situation. However that debt cannot then be palmed off onto the Product Owner by disguising it as additional "scope" to be prioritised and negotiated.
Some instances of technical debt might indeed be considered by the Product Owner for possible inclusion on the Product Backlog, if doing so allows that debt to be better managed in terms of product value, but other instances may not. In Scrum, a Product Owner is under no obligation to accept a Development Team’s debt. The Scrum roles are expected to collaborate but they also have their own duties and responsibilities. As a responsible partner with particular concerns, the Product Owner may or may not be interested in underwriting instances of technical debt which are incurred by the Development Team.
What however does this mean for the Product Backlog? This artefact is meant to be the "single source of requirements”, and it is described as such in the Scrum Guide. Isn’t it therefore necessary to record technical debt within it? After all, technical debt still represents work to be done.
Well, let’s remember that each Product Backlog Item must have an estimate. This means that the size of the Product Backlog should always reflect the cost of paying off any and all technical debt. Failure to do so will lead to an unrealistic picture of how much more must be invested before a product reaches a certain level of maturity. Like an iceberg, only a small portion of work will be visible, while the need for additional effort lurks hidden and unquantified beneath the surface. Transparency is needed over the amount of work which is genuinely believed to remain. That is a truth which the Product Backlog should always show.
Product Backlog estimates should therefore always take into account the cost of repaying technical debt in a timely manner. However, the Product Backlog will not necessarily describe the nature of the technical debt which is captured in those estimates. A Product Backlog is unlikely to have entries saying "refactor this", or "test that", or "replace method X with Y". Most Product Owners cannot be expected to prioritise such work in relation to other Product Backlog Items, or even perhaps to understand it at all. They may not be willing to assume this debt themselves in order to manage it. This debt is a technical matter which may be more sensibly managed by the Development Team, such as by means of a technical debt register. The estimates on the Product Backlog must however account for the scale of any such debt so recorded, in order to provide transparency over the work which truly remains. The cost of eliminating debt must be reflected in the estimates which are given for implementing any further work which the Product Owner has enumerated. In short, technical debt may not describe product scope, but it always has consequences for it.