What is meant by the term "technical debt"?
What exactly is meant by "technical debt"? Should there be user stories for activities related to technical debt?
Ward Cunningham coined the term "technical debt," comparing releasing new code with going into debt. Debt speeds development if it is paid back promptly with a rewrite, but if the debt isn't repaid, "interest" builds up. If you didn't pay interest on your mortgage, you'd lose your house eventually. Similarly, teams that don't keep up their "payments" eventually grind to a halt under the weight of the technical debt. For example, a business needs a feature into production quickly, so the team "hacks in" a change to legacy code. There are no automated regression tests, and the code now is even harder to understand than it was before. Next time the business wants to change that part of the code, the team will need more time to do it, and they're likely to break something. It's a death spiral.
User stories are one way to address technical debt, but there are others. For starters, teams should minimize technical debt by planning enough time to implement new stories in a good way, using tests to drive development. Teams working with legacy code need to invest time in refactoring it or rewriting it as they go. My team gets what we call an "engineering" sprint every six months, where we don't have to deliver any business value. This gives us time to do big refactorings that are too risky to do in a normal sprint, refactor test code, upgrade our tools and frameworks to the latest versions, rename poorly-named database columns, the things we can't easily work into a normal iteration. The business folks can see how this keeps our velocity steady throughout the year.
This was first published in September 2010