Ron Jeffries says: In Agile, the design must simply start simple and GROW up. The way to do this is refactoring.

Refactoring refers to changing the structure but not the behavior of the code. For Example: Suppose in the code base we have TWO methods and each has 3 identical statements. These statements can be extracted from this code and put it into some new method and both these methods can call the new method. This refactoring slightly improves the readability and maintainability of the program as the DUPLICATED code is moved to a new place. There are so many tools available with which you can run in your code base and it will help you in finding out the duplicity of code. In this way, the structure of the code is changed but not the behavior.

Refactoring is not only CRUCIAL to TDD but it also helps prevent code rot. Code rot is the typical syndrome in which a product is released its code is allowed to decay after a few years then an entire rewrite is required. By constantly refactoring and fixing small problems before they become big problems, we can keep our applications rot free.

When a refactoring opportunity is identified have a conversation with product owners and scrum master and get that added as part of a product backlog. At the end of 2-3-hour long programming session spend at least 20-30 minutes in cleaning up something you noticed as you were touching or looking at EXISTING code.

Always discuss refactoring in your next retrospection inkling your product owner.

My suggestion is to include them as part of your sprint planning and all team members should collectively work on that.