Should the PO really balance the level of technical debt? I just had this conversation yesterday at Sweden's "big" agile conference, Agila Sverige. There were many interpretations, understandings and strategies around this. I think it mostly boiled down to these two ways of looking at and arguing around it:
- On one hand: what is different about technical health/debt, than say features targeting a key stakeholder's user base? Isn't tech debt/health just one aspect of the product, coming from one stakeholder (Development Team in the tech case), that the PO needs to balance with other aspects?
- On the other hand - the Development Team is accountable to the (technical) quality of the increment (and thus the product), and continual refactoring is something they perform on a daily basis, as needed, to keep the product's tech health in check.
Two Cases, Two Sizes
In the conversation that was had, this more or less boiled down to two cases:
A) the work that needs to be done, is such a big change that it may not be completed in a Sprint and/or will require a major effort from the team. Risk and Cost is "real" and is considered to be on a level where the PO should at least be informed. I.e., this work needs to be challenged by other work and decided upon, at least in part, by the PO when the right time to do this work, is.
B) the work to carry out is not of the size above, and thus is just part of Dev Teams daily work and accountability.
Development Teams not spending enough time doing B type of work, might more often end up with A types of work, requiring them to more often argue/explain/motivate why that work is important to the PO. This is not the only way to end up with A type of technical rework, but not paying enough attention to technical soundness, coupling and cohesion, etc, may very well be a source of this type of work.
I also argued, that If this happens a lot/often, the Scrum Master should perhaps pick this up (that A happens a lot), and help the team assess whether they're spending enough effort on design and implementation strategy.
Tech Debt Inventory List
So what about assembling some of those B-sized things in a list, so we don't loose track of them? Isn't this a violation of the idea the the Product Backlog is the only source of work?
Again, I'd like to argue both ways:
Yes, if this list starts to grow, such that it regularly accumulates into A-sized work, then this may become a problem.
No, this is not a Product Backlog where the value of items needs to be weighed against each other by the PO. This is just a small reminder of things we should fix in the short term as we conduct our regular development of selected PBIs. This is similar to working with a test backlog (as described by Kent Beck in Test-Driven Development) - it's just a way to help the Dev Team stay focused and do their normal work in the Sprint.
Scrum is a small framework. The world is big, and there's no way one size fits all. So - as with everything Scrum, empiricism wins: try one way of doing it, reflect upon it and then keep as is or try something different: inspect and adapt.
In a fairly recent Scrum Pulse, Mark Noneman talks more broadly about Dealing with Technical Debt - what it is, where it comes from and ways to live with and adress it.