Decrease Your Debt with Technical Debt Sprints

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.

 

What Should You Do in a Technical Debt Sprint?

Let’s step into our product owner’s shoes and think about what she would expect from and after a technical debt sprint. A steady velocity allows the business to plan effectively. They have a good idea of how much work will be done in the next few iterations. Increasing velocity would be even better, if the team can maintain the higher level. Let’s look at some activities the team should do in technical debt sprints to achieve this goal.

Code Cleanup

Maybe you’ve left some unused code in the system, or an unused database column is lying around. Perhaps you really want to refactor some code that is bothering you. No doubt you can come up with a long list of pain points—things that get in your way any time you work in a particular part of the code.

The same rules apply to testing debt. Test-related activities in a technical debt sprint include reorganizing and refactoring automated tests, removing unused tests, and making any test changes associated with code changes. Your goal is to remove most of these pain points, resulting in cleaner and more maintainable code by the end of the sprint.

Here are some items our team chose to work on in a recent technical debt sprint:

  1. Refactor enums to have consistent lookup() method. In some enums, it was spelled as lookUp().
  2. Delete unused legacy code. Since this code isn’t covered with automated tests, we weren’t 100% sure if it was used. We were able to remove 3,500 lines of code. One thousand lines were in the last piece of legacy code, which we were able to remove from a module.
  3. Refactor automated API-level and GUI-level automated tests, extracting duplication and making tests easier to understand.
  4. Remove an unused database column from a table.
  5. Rename a database column in several tables and in the code for consistency.

Software Upgrades

Technical debt sprints are well suited to upgrading your third-party software, including test tools. This lets you start using the latest and greatest features of that software. If you delay upgrading software for too long, you may find yourself stuck on a version that’s no longer supported. You need to make sure that all dependent software is upgraded together, which can take a lot of time.

Build Features That Reduce Supporting Activities

The

About the author

Lisa Crispin's picture
Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of 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 Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

About the author

Nanda Lankalapalli's picture
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.