Having a Refactor Plan

The Boy Scout Rule is mostly non-sense.

In any moderately complex system the smallest changes can have wide spread & unforeseen effects.

Technical debt is a problem & fixing it should be just as important to the business as fixing a bug or adding a new feature. It should be planned, tracked, & tested in the same process. Sneaking in refactors under the guise of the Boy Scout Rule is dangerous & puts the other feature or bug being developed at risk. Even worse if the side effect is in an area that isn't discovered in the normal course of testing for the feature.

Spend the time as a team discussing the bad parts of the system & coming up with a solution together. Discuss the problem in your planning sessions, refine the idea, & come up with real acceptance criteria around how the code should be structured when you are finished.

Spend the time & do it right. Future you will be glad you did.