Expressing Technical Debt as User Stories Helps with ROI

I’m not a fan of ROI (Return on Investment) measures for software, except in the case where you have waste. Several of my clients have huge technical debt which creates waste for the development staff (not just developers, anyone involved with the development of the product). When you’re dealing with waste, user stories just might be the thing to help discuss how much waste now and later, when you fix the technical debt.

Here’s an example. Say the full build currently takes three days to complete. An incremental build takes at least 6 hours. You might create these user stories:

  • As a developer, I want to be able to build the full system from my machine in under 30  minutes so I can see what the effects of my changes are to the whole system. (Yes, I know, you might want it shorter, but to go from 3 days to 30 minutes sounds impossible to these folks.)
  • As a developer, I want to be able to do an incremental build from my machine in under 5 minutes so I can see the effects of some of my changes without having to do a full build. This will allow me to make progress faster on small chunks of work.

One senior manager asked, “How many full builds do you do per day now?” “We can only do one every three days, so none.” “How much will this save?”

The real key to savings is how long does it take for a developer to find and fix a defect. In this organization, it takes 3-7 days for a developer to find and fix defects, before the code is tested by anyone else. That means there is no such thing as a one-day task. The minimum duration task is 3 days.

Well, when the senior manager heard that, he said, “How long will it take to fix the build system?” “We think it’s 4-5 weeks of these 3 people.” That’s 12-15 person weeks to fix a problem that prevents 65 developers from finishing anything quickly. As the manager said, “No brainer. Fix the build system first, and tell me how did it get this way after you fix it. We want to prevent it from getting there again.”

If you’re having trouble getting your technical debt work into an iteration, consider using user stories and explaining the cost of the user story for each type of user vs. the cost of continuing to work the way you are. You might be pleasantly surprised.

11 Replies to “Expressing Technical Debt as User Stories Helps with ROI”

  1. good post. it does require management to realise that developers are in a very real sense “users” of the codebase/build process, and the better state it is in, the more quickly and reliably user stories for the end customer can be delivered

  2. Thanks for the great post, Johanna.
    We, too, were very successful with this approach. The team did retrospectives and added user stories for overcoming the one or two worst impediments to the top of the backlog. That way we managed to reduce our technical debt dramatically.

  3. Hi Johanna, The team I work with likes to capture tech stories and provide and estimate. The question we keep throwing around the table is if the business is OK with the team playing the story, should we record this as an increase in our body or work (scope increase) and track with velocity or just play it without including the points in the velocity, therefore running the team at a slower velocity. The reason for these two views is that a tech story is not a business story and in the end that is all the business understands.

    1. Marc, your developers are also users. The business people must learn to understand the tradeoffs they make, otherwise, *they* are not managing the backlog. You are. You can. I don’t recommend it.

  4. I like the idea, but I wish you used an additional example that is more typical. For example, there are “don’t repeat yourself” violations all over the place or a “done” but buggy part of the app is very difficult to understand.

  5. I don’t really understand this post. You say you don’t like ROI as a measurement for software, but surely with your user story and the cost benefit that is precisely what you have done?

    By defining things in cost benefit terms to the project as a whole you then provide the business with the information they need to make valid decisions. The use of user stories is helpful, but its not either user story OR ROI (cost benefit or whatever term you care to use).

  6. Pingback:
  7. Pingback: Anonymous
  8. Pingback:

Leave a Reply