One widely used idea when dealing with legacy systems is the Boy Scout Rule. It offers good incremental strategy for improving your codebase. I find it to be very valuable guideline which is much more practical than creating separate refactoring stories/backlogs.
However, I think that if we strictly follow this rule then often it is not enough to stop entropy from increasing. If we don't think about the general picture while making something look better locally then we may improve something on one place but at whole system level situation may not improve much or may even get worse.
For example, lets say that our data access details are exposed to our business logic (e.g using Spring JdbcTemplates inside business services or HQL queries inside Entities) and then we change this in one place by introducing a Repository. Yes we have improved that particular place because now we can test business logic with mocked data access but at the same time we have now introduced an exception in the design of our system. If we are not adamant in following this new approach then system will still corrode and perhaps even faster as there are now multiple ways of solving the same problem.
But how to make sure that when we introduce some small increment towards new (better) direction we will keep adding to it over time? Should we perhaps write it down to some refactoring backlog :)? I think if we have good team then this is naturally kept in the team's collective memory. Of course any long term incremental improvement only works if we have stable code ownership and team actually feels its long term responsibility. This is why code written by large group of people (exceeding efficient team size) with shared code ownership typically doesn't get better no matter how many good boy scouts there are.
So Boy Scout Rule is good approach but often we need to look at local cleanup in the bigger picture and see it as small increment towards some long term direction.