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
  • 13

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,808
  • 2
  • 84
  • 151
  • 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 '11 at 09: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 '11 at 09: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 '11 at 10:05
  • @pdr, the fact that business needs to be aware of a task does not make it a feature. Or is testing / deployment / platform upgrade / performance tuning a feature too? – Péter Török May 25 '11 at 10:22
  • @Peter - Testing and deployment: no, they are an ongoing part of every feature. You cannot prioritise testing against another issue. Platform upgrade: if it affects the development team (and thus other deliverables) then yes, but more often than not it doesn't. Performance tuning: should be part of every feature, like testing, but technical debt is where those things haven't been done for expedience sake. In that case, yes it is a feature - As a user, I need to see a response within five seconds in order to stop me leaving the site in a huff. (or something similar but less flippant) – pdr May 25 '11 at 10:39
  • @pdr, OK, performance improvement can be a feature. My point is that not everything on the backlog needs to be called a "feature". The general name I use is "story". So a story can be a feature, a (recurring or one-time) maintenance task, a testing task, a DBA task etc. I prefer to restrict the term "feature" to things which actually change the behaviour of the product. – Péter Török May 25 '11 at 11:25
  • @Peter - Alright, I see that point. I think you'll find that BDD-minded people use the terms feature and story interchangably, largely because Gherkin uses the term feature to mean either one. But in terms of common English, I totally agree with you. – pdr May 25 '11 at 11:39
  • @Peter @pds setting up your IDE is generally part of 'iteration zero'. I do tend to use story and feature interchangeably though - to me a feature is what you get when a story is implemented. – Steven A. Lowe May 25 '11 at 14:14
  • 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 '11 at 15:37
  • @David: in some ways it is just a matter or presentation so that it fits into the project framework smoothly. But also such a feature enhances the quality of the product, and thus adds value. Whether a client wants to pay for it or not is a different discussion! If the client balks but the developers think it is necessary, perhaps the developers should be allocated one story (or a few story points) per iteration for basic quality improvements. The benefit to the customer is that it keeps future iterations shorter. Like routine maintenance on a car - if you wait until the wheels fall off...! – Steven A. Lowe May 25 '11 at 18:13
  • @Peter i should also add that i regard a feature as being defined by one _or more_ stories. – Steven A. Lowe May 25 '11 at 18:15
  • 3
    -1 Failure to do your job should never be treated as a feature. – Martin Wickman May 26 '11 at 09:12
  • 1
    @Martin: LOL - making decisions to balance deadlines, quality, future maintenance, efficiency, and client desires _is_ our job. Often we don't want to leave technical debt in the code, but it can be unavoidable. To quote a well-known expert in the area, it's a matter of _prioritization - what is the single most important thing to build right now_ - because everything cannot be top priority, and time is not infinite. – Steven A. Lowe May 26 '11 at 13:22
  • @Steven: Yes, knowing when to occur technical debt and make a (real) commitment to fix it is of course part of our job. No doubt. But I simply cannot agree that fixing our mess, planned or not, can be considered a feature. – Martin Wickman May 26 '11 at 20:43
  • 1
    @Martin: dang, I was hoping quoting your own blog post would convince you ;-) – Steven A. Lowe May 26 '11 at 20:51
  • 1
    There's a recent blog item that argues completely the opposite: http://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/ – David M Jan 25 '13 at 20:31
  • @DavidM: interesting, but i happen to disagree. thanks for the link! – Steven A. Lowe Jan 26 '13 at 19:14
  • -1 just like @MartinWickman. "Failure to do your job should never be treated as a feature.". And to anyone that may say "but the customer will benefit from having me cleaning the mess so I can go faster", my reply is "then do it for free". Also, if you believe that "leaving technical debt behind is inevitable" then change your estimations to include enough amount of cleanup within each iteration, just like you include the time for testing. If you always keep your system clean, you'll never have to stop producing real value to your customer in order to just go and clean your own mess. – MichelHenrich Sep 03 '14 at 00:58
  • @MichelHenrich: in a perfect world, agreed. Never lived in one ;) – Steven A. Lowe Sep 08 '14 at 16:05
  • -1 Using this logic it would be possible to continually refactor badly and thereby continue adding valuable business features to the system. Clearly something is wrong with this notion. – Bradley Thomas Sep 28 '16 at 14:40
  • @BradThomas: refactoring badly will not add value; recheck your logic ;) – Steven A. Lowe Oct 06 '16 at 23:38
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,295
  • 16
  • 21
  • 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 '11 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 '11 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 '15 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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • 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 '11 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 '11 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.

Wesley van Opdorp
  • 878
  • 1
  • 6
  • 15