Before starting work on a new story or feature, I take a look at the areas of the codebase I’m expecting to change, and see if there’s anything I need to immediately address. (View Highlight)
Note: On refactoring
If there is tech debt that I’d classify as active tech debt, I refactor as needed, and then implement what’s described in the story. The emphasis here is on has to be dealt with: if it’s not getting in your way, don’t go looking for an excuse to refactor. (View Highlight)
If there is no tech debt getting in my way, I just get on with the change, without any upfront refactoring. (View Highlight)
If it’s dormant tech debt, I just note it down and continue on with delivering the story (View Highlight)
When it comes to dormant tech debt, I optionally tackle that after I’ve delivered a story. I deliver the story, and then spend some time after it’s merged tackling some dormant tech debt. This must be scoped though, you can’t spend the entire week working on dormant tech debt. Furthermore, you should tackle just the tech debt you identified. (View Highlight)
If you spot more, note it down for another time — showing restraint is key in balancing delivering value, and maintaining a healthy codebase. (View Highlight)
Another key aspect of paying off dormant tech debt is that it must be related to the story you’re working on. You can’t deliver a feature for the checkout journey, and then hop over and refactor something in the marketing tracking area. (View Highlight)