We have priority and severity fields in our bug tracking system. We define severity as how it impacts the user and priority as how it impacts the product. My question is about how to categorize a code improvement task in severity and priority. Suppose the improvement does not change any behavior but makes it a better code. We anticipate a long term maintenance improvement overall but it's hard to quantify. When we use our definitions for priority and severity, a code improvement gets the lowest values for both unless you introduce some hard to predict long term benefits into the picture. Therefore it implies that code improvement is a frivilous task and should never be attempted. However I believe it's cruical to constantly improve and refactor the code, because:Software development is itself a continuous learning process and without improving the code you can't get better at it.A team should be proud of their code.Future maintenance will take less time and over the long run savings will be significant.Or do you think such tasks should never be created and such improvements performed only on demand, when associated with a bug? Even if it's associated with a bug, wouldn't that be a discussion point on a code review, e.g. why did you do this drastic change in structure?.
How to determine the priority and severity of a code improvement?
project management;refactoring;issue tracking
Typically I do not like to view code improvement activities as a seperate assignable task because code improvement itself never directly brings you closer to completing user stories or requirements.  This is why code improvement tasks will always be such low priority that they never get assigned.I see code improvement as a constant, something that every developer should be doing as naturally as typing on a keyboard.  I factor it into my estimates for any task.  If my task involves me touching a class or some source code that hasn't been looked at in a long while, then I will assume that some janitorial work is probably in order and increase my estimate accordingly.Best case scenario I finish the task early and can use the remaining time to improve upon code or even design.  Worst case scenario the task takes much longer than expected but I have that extra time as a buffer.