Should technical debt/technology upgrade be scheduled as a feature (given points) or a chore (given no points)?

Question

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:

1. 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.

2. 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?

3. 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.

4. 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.

Answer 1

Short answer: paying down technical debt is a chore. You're not delivering new functionality for end users, so it doesn't get pointed.

---

Official answer:

Bugs and chores aren’t estimable by default

Feature stories are estimated because they contribute to business value. Bugs and chores are considered part of normal software product overhead—they emerge over time, and are continual overhead, an ongoing cost of doing business. Tracker’s automatic velocity calculation accounts for this as a built-in cost, and estimates how much business-valued work can be completed each iteration. This lets you focus your planning on business value, risk, and priorities. Therefore, bugs and chores in Tracker are not normally estimated. You can enable estimation for bugs and chores in Project Settings; however, we strongly discourage turning on bug and chore estimating. You cannot turn it off later if you change your mind.

https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores

This is why stories classed as bugs and chores can't have estimates assigned to them with PT's default settings, but I think also explains why you shouldn't count these tasks as features just to get points for them.

---

Firstly, I don't think you should count a fall in velocity as a penalty: it's just information. Perhaps it was something natural, like a new person joining that you had to spend extra time training. Perhaps it was something unexpected that reduced your capacity (e.g. illness) or consumed extra (e.g. "stop the world" bug). Perhaps you just hadn't estimated the features well, for whatever reason; this is something you can learn from. Or perhaps it was because you decided, as a team, to prioritise paying down some technical debt over delivering new features (and maybe incurring more debt).

Secondly, it's not necessarily a mistake to incur technical debt. It's not ideal to incur it accidentally, but if you decide to e.g. build the "quick and dirty" thing now in the knowledge that you'll need to tidy up later, for instance so that you can get more user feedback or meet a hard deadline, that's a deliberate choice you've made as a team and is OK.

As to whether something should be a feature, a simple rule of thumb is: do the end users care? You mention improving SEO: is this something they're at all interested in? Performance they might well care about, but on the other hand maybe they'd rather have some new feature than the same stuff with a few hundred milliseconds off the load time. Do some research: go and ask them what they want. Let them help you to prioritise what it's best to spend the team's time on.

You might decide that your current technology choices are holding you back from delivering certain features as efficiently as you'd like, in which case it's perfectly reasonable to (again, deliberately) spend time migrating all or part of the application over to something new.

I believe all types of chore mentioned above, if done wisely, should improve team's velocity in future.

Here I absolutely agree with you, but then isn't getting points for these chores double-counting? If you're doing the work so that you can deliver more features later, then you should see the higher velocity after you've done it, not while you're doing it.

Also, things like code reviews and basic refactoring in the process of delivery (e.g. the "refactor" part of the TDD cycle) should already be part of your ongoing work and therefore already included as part of the team's overall velocity.

---

Disclosure: I'm a Pivot, working for Pivotal Labs in London, but not on the Tracker team.

Answer 2

Just to be contrarian, we handle bugs and technical debt as any other PBI. In fact, we don't even have a "bug" type. Everything is a PBI. Our backlog is ordered by business value assigned to the PBI. As a result, a prominent user-facing bug that is causing problems will have a high business value assigned to it, since you risk losing money with something like that, and it will likely be one of the first things done. On the other hand, a bug that doesn't really have much impact and isn't affecting the bottom line will have a relatively low business value and may not be fixed for a while. That's an important mental wall that should be torn down: not every bug should be fixed. Sounds like sacrilege, I know, but if the effort involved in fixing the bug is more than the business value fixing it will bring, then the ROI is negative. Treating everything as a PBI gives you the freedom to make these types of empirical decisions without being distracted just because it's a "bug".

Likewise, with technical debt, there very much still is a business value in play. Some technical debt may be incurred with very little cost and may remain long-term, but some technical debt will kill your business over time, and therefore has a very high business value. The key again is realizing that everything is just a PBI. Everything goes into the backlog and you work on items in that backlog based on the value they add to the business. Whether it's a feature, a bug, or technical debt is really beside the point.

This also has the benefit of sidestepping your question entirely. Since everything is a PBI, everything contributes to velocity. The idea of doing work that's not actually sized and counted in your velocity is kind of insane to me. You're basically creating a huge blackhole in your empirical data. Velocity is already a pretty rough metric, it's an estimation based on an estimation based on even more estimations. Add in a bunch of variable amount of work not being tracked, and now the number is all but meaningless. Everything your team does in a sprint is part of your velocity.