How To Survive Technical Debt

As a developer, my least favorite kind of work was being added to a project late in the game.

I felt like an archaeologist trying to clean up an artifact that’s likely to crumble unless I worked very cautiously, analyzing each step. I complained that the software was poorly documented, when really no amount of documentation would have helped much, even if I trusted it. The act of *writing* the documentation can be a way to learn how it’s supposed to work. Lately I’ve found writing *tests* provides more bang for buck.

The scariest part was never knowing for sure whether the last “fix” I made caused a regression failure.

The way to higher velocity and reduced risk in the long run is to incrementally add automated tests so you aren’t flying blind as you make changes. You can’t afford to add all the missing tests at once. Instead, you can prioritize where the test coverage is most needed, adding it incrementally as you also add business functionality on a daily basis.

Normal amounts of technical debt can be repaid at the team’s discretion, as a tax on each business work item accepted into a Sprint during Sprint Planning. The team and Scrum Master may promote a more rigorous definition of done including:

  • “Automated tests have been added to all existing code touched by the added code,” or
  • “We left it cleaner than we found it.”

Large amounts of technical debt can be made visible as first class Product Backlog Items, to be split many times and prioritized along with the business stories. This approach will require the developers and Scrum Master to explain each item’s impact on development velocity in terms the business stakeholders can understand and prioritize appropriately. If they don’t see why they should be concerned, refer them to Kane’s article on technical debt, or call us for help.

Some parts of the legacy system may NEVER get test coverage, and that might be OK if those parts aren’t involved in the changes and have been proven to work in the past, perhaps through years of manual testing and live deployment.


Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
5 comments on “How To Survive Technical Debt
  1. Michael James says:

    The idea that technical debt items appear as first-class Product Backlog Items contradicts the misconception that all PBIs (or stories) must have direct business value. At a recent Scrum Exchange I challenged participants to bring stories that could not be split into vertical slices. A participant we’ll call “H” was very attached to the idea that none of his stories could be split small enough to complete in one Sprint because his system had fragile global tables inhibiting progress in any direction.

    Other participants pointed out that this problem itself could be split. “H” was well versed in how he could do this, having read Michael Feathers’ book Working Effectively With Legacy Code. But he couldn’t imagine listing the technical debt itself on the Product Backlog.

    The lesson for those of us who promote Scrum is to remind everyone:

    * ANYONE can add items to the Product Backlog.
    * Our preference for PBIs as user stories with direct business value should not deter you from making large technical debt visible in the backlog.
    * Technical debt PBIs, infrastructure PBIs, etc. can all be split if necessary.
    * Teams and ScrumMasters must convince Product Owners to adopt technical debt “orphan tasks” when taking on related business stories.

    Michael James
    Software Process Consultant

  2. Anonymous says:

    It’s true that anyone can add items to the backlog; and we do. But we all know that the customer is the one that prioritizes the backlog, and if the story doesn’t bring value to him/her, it’ll never make it.

    Additionally, if the engineering team [minus the customer] pushes the point, it’ll break trust with the customer.

    Haven’t changed my mind,


  3. Michael James says:

    If we’re talking about Scrum, the Product Owner’s role is to prioritize the Product Backlog, synthesizing the interests of all stakeholders (including customers, the development team, other stakeholders). Sometimes it makes sense for the end customer to be the Product Owner, other times it does not. Picking the wrong person as Product Owner, or reluctance to realize you don’t really have a Product Owner, is a pretty common failure mode.

    During backlog prioritization and at the Sprint Planning Meeting, we expect:

    1. the Product Owner to push for as much immediate business value as possible, and
    2. the development team to push for technical debt reduction, engineering elegance, using the latest and greatest resume-stuffing technologies, etc.
    3. the ScrumMaster to facilitate negotiation, helping everyone make their case in language both sides understand so that both sides can get some of what they want each Sprint.

    This won’t go well if the Product Owner can’t see beyond the current Sprint, the development team didn’t learn their lesson from Ken Schwaber’s “squirrel burger” exercise, or the ScrumMaster doesn’t do his job.

    This doesn’t change the fact stories, including technical debt stories, can be split when people co-operate.


  4. Casper says:

    One solution to this common problem could be to somehow figure out a way to visualize any “links” between PBIs representing actual “business value”, and their respective “children” representing technical dept.

    Although scrum enforces as few dependencies as possible between PBIs, it still might be necessary to add it.

    “Business value” PBIs with little or no dept-children might be prioritized over PBIs with many dept-children, but isn’t that exactly what our main goal was? To visualize how much technical dept will be involved (and how much extra work needs to be done) on each business value PBI.

    My point of view is, that techical dept doesn’t become a problem until you need to interact with it, change it or expand it. So if PO decides never to prioritize PBIs with much technical dept to it, that’s fine. The tests will never be written, but since no changes will affect the legacy code, it really doesn’t matter that much.

    Just my five cents 🙂

  5. Michael James says:

    I like Casper’s point above — you can address the debt that’s impeding current development by linking it to the customer-centric stories the debt is impeding.

    I noticed Johanna Rothman also suggests making debt first class PBIs when necessary:


Leave a Reply

Your email address will not be published. Required fields are marked *