Here at Liferay many teams do this. I, personally, do not like it. What I used to do was to create tickets for every change I'd like to see. Then, when that technical debt made some story or bug hard to process, I'd then fix the technical issue as part of the story and bug.
It was nice because:
we were always delivering value;
the most costly debts were paid, while some of the ones we hated the most proved to be irrelevant; and
the fix of the debt was better: sometimes we dreamed about some specific refactor to be done, only to do it when needed and see that what we imagined as a solution was not the best approach.
I guess Ron Jeffries gives a good explanation of what I think is a better approach to technical debt.
Bachelor's and Master's in CS from MIT. Previously, worked @ Microsoft & Zynga. Currently Co-Founder of Moesif (moesif.com), the most advanced API analytics platform.
Here at Liferay many teams do this. I, personally, do not like it. What I used to do was to create tickets for every change I'd like to see. Then, when that technical debt made some story or bug hard to process, I'd then fix the technical issue as part of the story and bug.
It was nice because:
I guess Ron Jeffries gives a good explanation of what I think is a better approach to technical debt.
Ron Jefferies article seems very good. First time I read that one.