My point was really that in many situations it is very hard to educate the POs in the actual cost and implications of technical debt. Since the PO is not responsible for *every* business decision, a general agreement can be made that technical debt should be repaid at some rate. If this is the case, the day to day decisions *within* this agreement can be the responsibility of the design/solution team since they should be the ones with the correct knowledge. And requiring a PO to make these decisions can be seen as wasteful.

There are always different ways to skin a cat, so definitely YMMV, primarily depending on the size of the organisation, complexity of the product and the technical knowledge of the PO.

But also the type of a proposed change is a major factor. The example you gave, replacing a home-grown framework, is in my mind not necessarily a technical debt. And of course I can see how this would have to go on the backlog.

I am certain that we would agree that the decision to add some unit tests around existing legacy code when you swoop by it, is *not* a decision that need to be taken by the PO. And still it is repaying technical debt. Strengthening your done criteria from “not adding to technical debt” to “lowering the technical debt” is hardly a controversial issue.

I suppose my line of thinking goes in the direction of “all inclusive”. Meaning that the cost for new features must include all costs and activities to sustain the development, and the organisation, for the future.

Sometimes repaying a particular part of the technical debt can have a faster ROI than adding the next feature in the product backlog. That’s adding business value to the product.

For example, replacing a home-grown persistance layer with a standardized framework may require some learning and coding but can also provide a better design base from where new features can be added to the product faster. It may also reduce code complexity and therefore be beneficial when new team members are introduced.

Then there is the interesting question wether the technical debt is a part the product or not.

If it is, that means that the product owner, like it or not, is the one in debt. In that case the decision to repay or not should be made by the PO, not the team. The team is, however, responsible for not adding to debt. This approach requires the PO to really consider the whole lifecycle of the product, but also “softer” things like team spirit, confidence and productivity, when choosing the work that adds most business value to the product.

If the technical debt is not seen a part of the product, then someone else than the PO is in debt. This may then be delt with in the way you describe, where x % of the team capacity is set aside for “non-value adding work”. Non-value adding for the product that is. The work must, however, be considered good for the organization as a whole, otherwise nobody would fund the x %. So it’s adding value to the organization, but not to the product. But adding business value it is.

If the technical debt is not seen as a part of the product, product value is not the only source of business value. Therefore repaying technical debt still adds business value.

As long as we focus on “optimizing the whole”, it does not matter who owes the technical debt.

What’s important is that teams stop adding to the technical debt, and that we make any debt reduction decisions based on business value for the whole organization.

Only measuring the velocity a team can add business value to a product is a source of suboptimization.