How To Survive Technical Debt

About 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).

  5 comments for “How To Survive Technical Debt

  1. Michael James
    March 27, 2009 at 11:51 am

    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
    March 27, 2009 at 11:52 am

    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
    March 27, 2009 at 11:52 am

    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
    March 27, 2009 at 11:52 am

    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
    November 7, 2009 at 3:10 pm

    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 *