When you should refactor code

Refactoring code it akin to not cleaning up your kitchen on a regular basis and doing one big clean every few weeks. Sure, in the short term you're saving time, but there's consequences down the line - the mug of coffee has left a ring stain on your kitchen worktop, the kitchen begins to smell and a few months later you have rodents.

I've been guilty of not prioritising refactoring into a team's sprint because the consequences are not immediate. I've also been guilty (in my younger years) of not cleaning up my flat.

Here's some approaches that I think work:

1- Timebox fixed amount of hours or time each sprint. It becomes part of the routine of each sprint. Almost like setting up a small standing order to another bank account each month. It's just part and parcel of what happens.

2- Dedicate time on the backlog in the future. If you have a release to work on which has more shorter term priorities that has a cost of delay, make a commitment to allocate the team's time to work on refactoring.

I personally prefer point 1, but dedicating time on the backlog allows for flexibility. You have to ensure there is a cost of delay though because otherwise everything is always a priority without being able to prove it.