What should we do for user stories for technical debt in Pivotal Tracker? Should we consider these as features (giving points) or as chores (giving no points, thus lowering velocity)?
I am confused what should be considered as a chore:
Duplication of Code - It's clear that if we have put same code in multiple places, that's really bad code practice and indicates developers in the team should give more thought to make software maintainable, do refactoring and team should spend time on code reviews. As all this would take maturity, time and code level experience, it's better to deliver less number of points so that code quality is not compromised. So, such mistakes should be penalized and velocity should be lowered by not giving points to chore.
Technology upgrade - Like moving to modularize JS, HTTP2, React, MVC or any other new/better technology. These steps will make performance and maintenance of the code better. But should this be chore or feature? I believe this is how technology world is, new technologies come every now and then and you have to migrate to it. So, I see no point in penalizing team's velocity for such work. Suggestions?
Duplication/Sub-Standard code in legacy code - Few code are which are untouched since long time OR when a new team is formed but the code base is a bit old, we face this challenge. The team says they have not coded this section so why should their velocity be penalized by picking such technical debts as they never created those debts.
Sub standard code due to business urgency - Sometimes developers are forced to push features ASAP on live due to competitors/targets/business/user pressure. Should cleaning up of such bad code be considered as chore (w/o giving points) too? This time development team is not at fault, so why should their velocity be pulled down, when in fact they mostly put extra hours in such cases.
I believe all types of chore mentioned above, if done wisely, should improve team's velocity in future. But how should we keep balance b/w maintaining team's velocity as well as penalizing for the technical mistakes team is doing by taking bad decisions?
The question is similar to: Should technical debt be scheduled as a feature or a chore (or a bug)?, but I didn't find convincing answers that cover all 4 points so I am reposting it in a different manner.