The problem I find with ticketing code quality tickets is three fold.

1) Not all code messes are equal.

Technical debt in an area of code with high churn is expensive. Technical debt in code that works and doesn’t need to be touched again is zero interest and zero payments, and refactoring it actually just introduces risk for potentially zero again.

If you make a ticket to clean up a messy module, you add the waste to talk about it in pointing, planning, etc.

If that component doesn’t actually impede our workflow, cleaning it up at a later time isn’t buying anything (arguably it’s just adding risk on top of wasted work).

We know the code that’s actually slowing us down, because we feel the pain as we’re in it, and when we feel that pain should be the time to fix it.

2) Ticketing systems are a bad place to track this kind of work.

Code cleanup isn’t really ever “done” so putting it in a ticketing system that intrinsically tracks “done” is a poor fit.

Code quality tickets tend to get stale quickly. Another refactoring might make the code quality ticket obsolete.

Software quality is inherently built in to agile story point estimation. It’s part of the motivation to track points and not hours. An agile team’s velocity is affected by its technical debt, so taking time to clean up might make your 2 point story closer to a 3 point story, but it will more than work out as our velocity will go up over time from the improvement.

3) Teams should feel free to clean up code as it’s needed.

Putting it as part of the ticketing/estimation process is just overhead that will cause that debt to balloon. (You put it in the system, point it in the next meeting and do the cleanup weeks later?) If a component sucks, waiting to fix it sprints later is just going to cost us more time.

Also, most importantly, you have the context of the component at the time you’re in it. One aspect of bad code is that it’s often hard to understand. If you have the context and understand it during your editing of the file, another person (or you three weeks from now) is going to have the same difficulty re-figuring it out. If you see what should be cleaned (again for medium or smaller refactorings) it’ll be far less overhead to do it when you’re in the code and aware of all the context than coming back to it weeks later.