This is a core part of the policy. It states:
'Leave the Code Base with Less Technical Debt that when you started the job'
The reasoning behind it, and some excellent advice can be found here
Don’t ‘Boil the ocean’
Very often when refactoring it is like pulling on a piece of string. Once started it is often hard to stop without changing the whole code base. This is like trying to ‘boil the ocean in one go’.
With practice and training you can acquire the skills to do refactoring one bit at a time. If you have problems ask a colleague for help or request training
Don’t make refactoring stories
Refactoring is a technical matter. Stories are about the capability that is to be delivered, and it is the programmers’ job to decide how to deliver it. The Product Owners do not control this: they get to say what capabilities are to be delivered next, and the programmers decide how best to implement it
It is very rare that it makes sense to do a big refactoring. Usually it is best to do a lot of little refactorings: each one leaving the code in working condition and with a little less technical debt.