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 SprintsOne 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.

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.

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.

About the author

Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was honored by her peers by being voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012. Lisa enjoys working as a tester with an awesome agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world. For more about Lisa’s work, visit www.lisacrispin.com and follow @lisacrispin on Twitter.

About the author

Nanda Lankalapalli

Nanda Lankalapalli is an architect, Certified Scrum Practitioner, and agile coach. He built and led high-performance teams and is an active contributor to the agile community. Nanda is one of the founders of the Agile Hyderabad user group and has spoken at several agile conferences organized in Hyderabad, India. Nanda is part of Eplan Services and telecommutes from India.