23

I've added a couple of user stories that address some technical debt to my Pivotal Tracker board. Should I consider them as features (keeping my velocity level) or as chores/bugs (lowering my velocity)? I understand it won't make any difference in the long run if I did one or the other consistently, but every time I add a technical debt story I have to make the decision.

Some thoughts:

  • They aren't actually bugs, they don't break anything
  • The users haven't requested anything as it is low-level implementation that doesn't affect them, but it will make long term development easier
  • If you define features as stories that add value to the users, well a) they don't as the users won't see any direct benefit, but then b) they do because they make future development/maintenance possible which does add value, just not right now

I'm not deciding whether or not to actually do the work, or when to schedule it, I just what to know what I should call technical debt in my project management tool, and why.

Rebecca Scott
  • 563

4 Answers4

21

It is a feature.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

It is defined and scheduled and tracked like any other features.

If implementing this feature is not sufficiently valuable (to the client or to you) for it to ever be scheduled, that's a different problem.

Community
  • 1
Steven A. Lowe
  • 33,828
21

(Repaying) technical debt is imho not a feature, because the client is not qualified to make decisions about it. Most importantly the client can't decide when it's finished, and additionally the client is totally dependent on you to explain the benefits. It is your judgment that there is technical debt, and it is up to you to decide how to fix it and when you are done. Technical debt is affecting your (future) velocity, not the clients perception of the software. If there was no debt, you would be more productive. And the velocity you've been measuring so far is wrong, since you should have taken more time to keep the code in shape.

I do think you should communicate this with your client, but it's not something in their control. You could say something like this: 'We've been taking a few shortcuts so far, which we will have to fix. This means our velocity will go down a bit in the next few iterations, but this is to make sure we have maintainable software in the long run.'

Continuing work on the client's feature will also help to keep your focus on improving the software for the client, instead of it becoming some sort of academic exercise to find the perfect design (this is something I personally struggle with sometimes).

Jaap
  • 2,305
15

IMHO a task to eliminate technical debt is definitely not a feature. It could be shoveled into the "bug" department, but it would be stretching the definition of terms, as again it does not result in behaviour changes observable by users.

I would just call it a maintenance task. In any development project, there are lots of such tasks, like setting up dev/test environment, assembling test data, merging branches in SCM etc. None of these are observable directly by the users, but failure to do them regularly results in increased development costs and bug rate in the long run.

It may not be necessary though to handle them as separate tasks (unless they are huge, and/or you are under no pressure to implement new features right now). Usually it may be better to just identify when a new feature requires refactoring / writing unit tests etc. and handle these as part of developing the new feature. This may be easier to explain both to management and end users (if they want to know what you spend your time on). Update: Moreover, it helps developers focus on the value of refactoring as well. It is easy to get carried away into refactoring for refactoring's sake, so focusing on what added value a specific refactoring brings from the client's perspective is IMHO useful.

Péter Török
  • 46,547
3

I would call it an improvement.

Not a bug because nothing is broken.

Nor a feature because refactoring will not be an request of your client. (because it works!).

Most tracking systems support an issue type improvement by default, if not you can probably alter the types anyway.

Wesley van Opdorp
  • 868