In the particular case of refactoring, I don't think this is a good idea. I can understand that multi-file system reorganization refactorings shouldn't be done

In the particular case of refactoring, I don't think this is a good idea. I can understand that multi-file system reorganization refactorings shouldn't be done with simple changes, but small enough refactorings can easily happen when working on a piece of code. That is because- - You have the best mental model about a piece of code and its system the best when you are working on it, not when you read a ticket description of what should happen. This leads to overall better efficiency and less context switching. - I think that the principles of "leave things better than you first found them" and "with every not-so-minor change, one should think about how would you architect the system the best way possible at this current time" great principles. - I find that "Refactoring sprints" never really work great. They tend to be inefficient and rarely prioritized tasks by the management. As developers we have responsibility over code and make sure that its in the best state possible as an implicit description of our profession. Even though it pays to be focused, I think there is merit in the exploration of code-base as it helps figure out new ideas and avenues of improvement.