Once the ledger of technical debt reaches a certain amount, it’s a good idea to sit down with the product owner (PO) and review the list. The PO can prioritize the work, and the project manager (PM) can slot the work into a future release.
Or not.
Keep in mind not all technical debt needs to be refactored. There’s always a cost-benefit analysis to consider.
If the cost to refactor the code is more than the benefits it provides to the business, then it’s probably not worth doing it. Sure, the developers will groan a little that the code/flow/other isn’t “perfect”, but that’s not the goal. “Good enough” is the goal.
If the functionality works and the benefit to change it isn’t sufficiently large, you are allowed to leave it as is. Really.
The takeaway
Only when “good enough” isn’t good enough anymore is it a good idea to refactor the tech debt. Else it could serve as a distraction to moving forward and releasing higher-values updates.