Originally posted on my blog apastuhov.com.
Today more people think about technical debt than 5 years ago. Because every project has a debt, bu...
For further actions, you may consider blocking this person and/or reporting abuse
Basically this is issue tracking for technical debt. Shouldn't we track technical debt issues together with all other issue, say features, bugs and change requests?
Nice point, and you are partially right. As I wrote in the article:
The idea of having such table is to focus on causes and ways to prevent an issue.
When we look at the debt as a simple technical task - we do not think why it happened. Also, you lose an ability to review your technical debt from a helicopter view.
But still - you are free to use any task tracking tool to track the progress of a single task.
I understand. My point is that all development processes I know are based on tasks. A developer is not supposed to do (or at least isn't paid for doing) anything outside a task. So to make the reduction of technical debt happen, you need to define tasks for it in the standard tracking system as well.
Yes, you need and you need to plan it as a part of the sprint/milestone/etc.
In my honest opinion, it is a bad practice from evolution/growth perspective.
Not neccessarily if a developer can create additional tasks without too much bureaucratic overhead.