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.

Improve this question
1

4 Answers 4

Reset to default
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.

Improve this answer
21
  • 1
    Aha. Fantastic answer. I hadn't thought of stories written from my perspective, but it makes sense to me especially being an in-house developer, since I have to act as the client as well. Thanks!
    – Rebecca Scott
    May 25, 2011 at 9:18
  • 6
    I have to disagree. From this perspective, practically everything - even setting up my IDE or getting an SCM account - would look like a "feature"...
    – Péter Török
    May 25, 2011 at 9:38
  • 2
    @Peter - Not necessarily. Setting up your IDE is unavoidable effort; other things just fall into the "stuff that gets done" category. But replacing a framework or something is very different. The business should be aware of what you're going to do, the benefit to them and they should be allowed to prioritise it against other work. Thus, it is a feature in every sense.
    – pdr
    May 25, 2011 at 10:05
  • 4
    Surely a feature should add value to the product? Refactoring adds no such value, it simply enables developers to work on it more efficiently and reduce the chances of bugs. Added value from this sort of thing would be a secondary effect. Calling this a feature would simply be a way of presenting it so that the product owner might be more likely to prioritise it.
    – David Neale
    May 25, 2011 at 15:37
  • 3
    -1 Failure to do your job should never be treated as a feature.
    – Martin Wickman
    May 26, 2011 at 9:12
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).

Improve this answer
3
  • Agreed with this. It's not a feature because it's not the client's concern, and it's not something they should be aware of (in my experience, when the client is aware that you are refactoring/fixing code to pay off technical debt, they view it as wasting their time and money, so it's best they don't know you do it at all).
    – Wayne Molina
    May 25, 2011 at 14:05
  • +1 This is also a valid viewpoint on the issue. I like treating it as a feature because then it slots in nicely with the normal planning and tracking mechanisms. It is difficult to explain to the client though.
    – Steven A. Lowe
    May 25, 2011 at 14:23
  • +1, this is the only answer which clarifies how the velocity calculation will become wrong when you do count "technical dept tasks" as features.
    – Doc Brown
    May 22, 2015 at 13:20
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.

Improve this answer
2
  • 1
    I agree that refactoring away technical debt should be included when it is required by a new feature, but I read this question as paying down technical debt independent of or in advance of it being required by a new feature.
    – Steven A. Lowe
    May 25, 2011 at 14:15
  • @Steven, that was my interpretation too. Linking technical debt payback to a related feature is just a suggestion.
    – Péter Török
    May 25, 2011 at 14:20
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.