Decrease Your Debt with Technical Debt Sprints

Technical debt is one of the primary impediments to long-term software product success. Every team feels the pressure to deliver value frequently to the business. At the same time, we know that we need to keep our code clean and supported by tests to operate at a sustainable pace. Regular technical debt sprints are one way to make our “interest payments.”

When time is short, even a well-disciplined team may cut a few corners. They might implement a code solution or automated tests in a less-than-optimal design, or make changes in old production or test code without taking time to refactor it. Future changes to this production or test code will be harder and take longer.

Ward Cunningham coined the term “technical debt” to represent the unfinished work due to shortcuts taken by the team to deliver a feature or user story faster. If we “borrowed” by skipping important steps, we have to pay back that “interest” quickly. If not, the interest will keep mounting up, and the growing technical debt burden will slow us down or even immobilize us.

Technical Debt Sprints
One way to pay down our technical debt is by devoting an entire iteration to activities such as refactoring production and test code to make it more maintainable and understandable, learning new ways of working better, upgrading test and code framework and tool versions, and improving the “living documentation” (also known as “automated tests”). We skip delivering new business value for just that iteration so we can pay down our technical debt.

“Sounds good,” you say, “but our product owner is never going to let us spend a whole iteration and not deliver new user stories to the business.” Or, you might be thinking, “Aren’t we supposed to ruthlessly refactor all the time? Why spend a whole sprint on refactoring?”

Even a highly disciplined team may run into limits to continual refactoring. If we have a lot of legacy code that is not supported with automated tests, it’s time-consuming to refactor and too risky if we don’t simultaneously add the tests. We also need to refactor our test code to keep tests maintainable and efficient. But, it can be risky to change our tests while code is changing.

There are other considerations. The team should choose its strategy. The work done in one quarter or a six-month period is going to be the same whether the team’s technical debt keeps growing—forcing them to work more slowly—or they devote some time exclusively to reducing the technical debt. Even with continuous refactoring, we find it works better to take some time to understand the debt and take the right steps to manage it for the long term. (See the sidebar for a helpful game about technical debt.)

Article continues below.

Technical Debt: Hard Choices

Nanda recently came across a game that explains technical debt and the results of not paying it back. The game, called Hard Choices, was designed by the Software Engineering Institute (SEI) and adapted from Shortcut: A Game About Speed and Risk by Elisabeth Hendrickson.

Basically, the game has the aspects of taking shortcuts (creating debt by incurring penalties) and paying it back (by losing a turn). If you don’t pay your debt, it will take you longer to reach the end.

Players can move in any direction and can even change directions in a single turn. They earn points by racking up “tool” cards and by being the first one to get to the end. For each bridge they cross, they must subtract one from subsequent rolls of the die.

Nanda plays differently than described in the SEI rules. In his version, three players still move the number of squares to match the roll of the die; however, there are specific rules for each player:

  • Player 1: Always takes the shortcut (represented by the bridges), but never “pays back” by losing a turn.
  • Player 2: Always takes the shortcut, buts pays back right away by losing the turn.
  • Player 3: Never takes a shortcut.

Nanda also changes the positions of the bridges so that each shortcut only bypasses a few squares, thereby making even clearer how Player 1 is going to suffer at the end. This is more like real life—shortcuts don’t usually buy you a huge amount of time. Played by these rules, Player 2 wins and Player 3 usually reaches the end ahead of Player 1.

The “Short Cut” game has similar rules, and several variations that let players experiment with different approaches to paying penalties back and changing goals from a competition to a collaborative team effort.

Playing either game helps teams and their managers understand the need for technical debt sprints to “keep the backyard clean.” At a minimum, this will allow the team to maintain its velocity, and there might even be a big improvement.

User Comments

Gerard Miller's picture
Gerard Miller

Excellent article!

I've been in this industry since the top of my head was covered with hair. You've uncovered a disfunctional pattern, to rush into the next project NOW.

Sometimes we are under time pressure and in the trenches where the goal is to do what must be done to ship. That happens, that's part of our jobs.

You have highlighted that we should make the time so we don't repeat the same mistakes and carry ever increasing technical debt.


June 13, 2011 - 9:53am
Philip Schwarz's picture
Philip Schwarz

Do any of the following lead you to reconsider your definition of Technical Debt at all?:

"Agile and Beyond :: The Technical Debt Trap"

"Debt Metaphor is not Technical Debt":

"Ward Explains Debt Metaphor":

"Technical Debt":

"The real Meaning of Technical Debt":

June 13, 2011 - 7:35pm
LIsa Crispin's picture
LIsa Crispin

Hi Philip, I have read/watched most of those before. What specifically in our article do you find in conflict with them?

-- Lisa

June 13, 2011 - 11:02pm
Jay Packlick's picture
Jay Packlick

If you think of Technical Debt (TD)reduction as an accumulation of product backlog items (usually unrecognized, un-prioritized, and missing as items visible in the backlog) then a TD sprint is nothing more than the prioritization of some of those items to the exclusion of all other customer focused items for the duration of a sprint.

Since TD reduction provides value to the organization (via improved development performance) then making TD reduction stories part of the visible product backlog creates a context to schedule their execution into sprints on an ongoing basis rather than (or in addition to) big bangs. The variable then simply becomes one of how much capacity to allocate to work them per sprint.

Think continuous flow of value; If you really want to see some ongoing improvement, add TD reduction stories to the backlog and make it a part of regular project / sprint planning.

J. Packlick

Agile Coach


June 14, 2011 - 2:27pm
Nanda Lankalapalli's picture
Nanda Lankalapalli

Hi Jay,

If the TD is sizable and could be defined as a story, we could add it to backlog and wait for it to be prioritized. We did that lot of times. However, if you have lot of smaller granularity tasks, it would be hard to negotiate with the PO in each sprint. It would be lot easier to ask for a week or two to take care of TD and let engineers decide what's the best priority rather than asking PO to prioritize TD items.

As we always say, do whatever works in your context.

June 15, 2011 - 1:14am

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.