If you don't refactor, as you program new features the code will rot. The best time to refactor is when you add a new feature the codebase didn't anticipate -

If you don't refactor, as you program new features the code will rot. The best time to refactor is when you add a new feature the codebase didn't anticipate - this is how we do it at my job. Do you not consider this refactoring? Or do you just bolt on things as you go? Or do you consider refactoring something like "OK, we have 2 weeks to refactor the codebase" - because IMHO that's not a great way to do it. Instead, at work we follow the scout rule: make the code a little better each time you touch it. This is still refactoring. And we don't do sprints either. We just have a priority list and however long the next thing takes is however long it takes. We do rough estimates but don't hold people's feet to the fire. Rarely we have deadlines and things DO need to be done by a certain time for that, but that is due to external marketing/etc. This usually only happens a couple times per year.