[deejbee]

This sounds like more of an issue with technical debt management. I'm much more of a proponent of Kanban, whenever possible, so in this case if a user story requires a refactor or architectural change then that's just fine. Also regular code reviews to eliminate hacking and sanity checking automated tests shouldn't be made optional, they should be actively encouraged by the team leads and dev manager.

[Noseshine]

    >  if a user story requires a refactor or architectural change then that's just fine

Those clear cases are not the problem since they are... clear. There is a lot of need for refactoring that arises only slowly and not through one feature. It's more like the boiling frog thing (which by the way is a bogus story but I still use it nevertheless because everybody understands the point). So a problem is you can never really justify the refactoring effort using one specific new feature. It's like partial vs. full cost accounting, sometimes you just have things you can't break down but it still needs to be done (paid). Which makes this a real problem for organizations who don't have the accounting set up for this. In my experience especially large firms may have teams that get their budget "per feature", so even the best manager can't solve that problem - the next (management) layer above doesn't care though because your little software team is too small to get them to laboriously change the accounting process and the SAP system.

[specialist]

Kanban is the software development equivalent of the Concentration (Memory Match) card game.

https://en.wikipedia.org/wiki/Concentration_(game)

As though a useful, usable product design (architecture) could be divined thru piecemeal revelation.