Having run a couple of development teams on tight schedules, this is also what I arrived at, and I found it to work great for bigger teams in larger organisatio

Having run a couple of development teams on tight schedules, this is also what I arrived at, and I found it to work great for bigger teams in larger organisations too. With some caveats: 1) Be upfront about it, the PM or whoever is making the business decisions should at least be aware that the ticket is not being addressed in the quickest way possible. Sometimes that's a real problem and that conversation is worth having. Mostly it's not an issue, at least in my experience. 2) Pretty much never done while fixing a bug that occurred in production. 3) Done in separate commits / PRs. Preparatory work for the actual change, basically. This makes understanding the changes, as well as later regression testing _so_ much easier. I may also be doing it wrong, but this is what seems to have worked best for me and my teams.