I think separating tasks for features and for quality is wrong. They are not two different things. There is only purpose, and that is to serve the user's needs.

I think separating tasks for features and for quality is wrong. They are not two different things. There is only purpose, and that is to serve the user's needs. Therefore I also think technical debt is the wrong way to phrase it, because it takes away the need to express the task in terms of what it means to the user. If a tree falls in the forest and no one is around to hear it, does it make a sound? If the user won't notice technical debt, then who cares? You can refine technical debt by simply asking the question: what will the user notice if technical debt is not repaid? Use the answer to that question to phrase the task and suddenly it's not technical debt anymore, but actual work that the business will prioritize (or not).