[mhomde]

I don't know, when it comes to code quality and things like that I'd rather prefer a methodology that insulates it against bureaucracy rather than involves it. Keep the Dilbertian forces at bay.

Product owners should prioritize feature set, requirements and sometimes bugs, but the less they have to do with the intrinsics of reaching them the better.

[crdoconnor]

I think their involvement should be strictly limited to telling developers what % of their time they're to spend on refactoring/tooling.

This actually avoids dilbertian forces - the PM can't weasel out of responsibility for pressuring you to deliver shit quickly. That % would stick out like a sore thumb if it was permanently under, say, 15%.

[mhomde]

Unfortunately IMO that kind of thinking seldom works. It's very managerial to assign specific time and percentages to things but in practice I've never known development to be managed that way. Also you underestimate their weaselness :)

Refactoring needs to be an integral and constant part of the development, in the long run that will decrease time needed for refactoring, and time required to fix bugs. But that time is variable, and might come in large chunks depending on how much technical debt you've accumulated

[crdoconnor]

Precision isn't the issue. Story pointing isn't supposed to be 100% accurate either. It's supposed to shine a light on an otherwise opaque process. It works at that. This is the same.

I could quite easily spend all of my time refactoring and none on features and vice versa. There is no "right" amount as you seem to think, just a whole bunch of trade offs.

I think you underestimate the power of making something measurable and exposing it to upper management. That often changes behaviour in a quite radical way, especially among weasels.

And, you've never known development to be managed in this way because it's a new idea.