Agile Book – Technical Debt

In the next edition of this blog series highlighting excerpts from our upcoming book, we will tackle the tricky subject of Technical Debt.  To be honest, I had a hard time choosing a single topic from this chapter because there are so many great topics covered – debt2Definition of Done, Planning Poker, Value Stream Mapping, the Kano Model, Velocity, the XP Planning Game – and much more in this chapter on Grooming and Planning.  And it includes an interview with none other than Mike Cohn!  If this post, or any of the previous ones on Roles or Requirements or our guest blog from co-author Sondra Ashmore inspire you to want to purchase the book, please visit Amazon and search on Introduction to Agile Methods.

Back to Planning and Grooming, here are the Learning Objectives for the chapter.

Learning Objectives

  • Understand the elements of a product backlog and what traits lead to the strongest deliverables
  • Dive into prioritization and learn different methods for understanding what is the most important feature or item to work on
  • Explore estimation and the different practices and measures that are used today
  • Understand story points and planning poker as ways to discern the level of effort and complexity of the user stories/requirements
  • Learn the other inputs that affect the planning process, such as team velocity, definition of “done,” technical debt, and bugs/defects
  • Evaluate Sprint planning and the XP planning game to learn how commitments are made and work is planned
  • See how maintenance work can be incorporated into Agile teams
  • Review the triple constraints model and how it is handled within the Agile framework

Incorporation of Technical Debt

One of the discussion points with regard to the product backlog is the inclusion of technical debt. With Agile, teams are moving very quickly, and sometimes to achieve the sprint goal within the time frame allotted, the team, either knowingly or unknowingly, creates technical debt.

There are many definitions of technical debt; in fact whole books have been written on this subject alone (see References and Further Reading for details), so we use a basic description here, for illustrative purposes. Technical debt was first discussed on the wiki page, and the definition created by Ward Cunningham is commonly used today: “Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring” (Cunningham 2012).

There are two basic kinds of debt—unintended and intentional. Unintended technical debt is simply the consequences of the team’s learning curve. Perhaps they designed something poorly or did not test thoroughly enough, or the business was not 100% certain about the business requirements. No matter what the root cause, this type of debt is unintentional—no one meant to write bad code or be sloppy—and it happens as part of the continuous learning process that is essential to Agile.

Intentional technical debt is incurred as trade-offs are made in the development process. We may choose to incur technical debt for short-term, tactical reasons or long-term, strategic ones. Let’s consider some examples. Because our weather application for Cayman Design is going to be available with only information for the New York area in its first iteration, we are going to code the database lookups in a way that is quicker to deliver the initial release but will not be scalable once the data for the entire country is loaded. We decide that this is the best path, knowing that it will create technical debt, because it is the fastest way to release the initial version. It will allow us to research and learn more about the optimal database design once we better understand how users will interact with the application. Another example might be that Cayman Design is a cash-strapped start-up and can afford only certain hardware until we get revenue coming in, so we must code to those constraints. Again, we realize and accept that this creates technical debt that will have to be cleaned up once we are a thriving, profitable organization.

When we are ready to tackle technical debt, should it be included in the backlog of prioritized stories? Although there is some debate on this topic, most experts agree that it should. The technical teams may have to argue their case to the product owner to prioritize the efforts appropriately, and a good product owner should listen and understand the impact of allowing the debt to fester.


Having seen Agile transform organizations into more productive, happier and more innovative places to work, I have a deep and enduring passion for it.  I hope this post and the others on this site inspire you to want to learn more.  Happy reading!

One Response to Agile Book – Technical Debt

  1. As a developer I have created my fair share of technical debt. Working on an Agile team we wrestled with what to do with our technical debt. I have read some Agile coaches recommend calling out technical debt items should be called out in on the product backlog with an alternate color card or sticky note. Do you have recommendations for calling it out?
    Also I think it is up to the technical members of the team to communicate the importance of certain technical debt items.

Leave a Reply

Your email address will not be published.