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.

Tweet This Post