IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech

IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on. What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management. “Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.