Decrease Your Debt with Technical Debt Sprints

time spent doing production support is time lost for developing new features. Identify little features that will reduce support time, thus increasing velocity, and implement those during the technical debt sprint. Some of the small features our team delivered in the most recent technical debt sprint were:

1. Users didn’t have any way of knowing when a long-running daily process completed, so a developer had to monitor this for them. We changed the process to send an email to the users when it completes.
2. Some reports ran extremely slowly, causing users to file production support tickets. The developers and DBA tuned these.

Do You Have Enough Time?

Now you know what tasks you could work on in your technical debt sprint. But, you only have one iteration. How do you maximize your return on investment (ROI)?

Some tasks may be mandatory. For example, you may be using an unsupported version of third-party software and you can’t delay upgrading it any longer. For the rest of the tasks, consider the following aspects:

Utility, or Value: What’s the value of a new feature to address the root cause of a common production support issue? Is it in a framework used throughout the system, or will it only affect a small area? How much support time will it save?

Effort: How difficult is the task? Some tasks only take a few hours, while others might take the whole sprint. A general guideline is to prioritize tasks in the following sequence:

1. Easy and high value.
2. Hard and high value.
3. Easy and low value.
4. Hard and low value.

What About the Testers?

What do testers do during a refactoring sprint? Obviously, someone has to verify that the upgrades and refactorings didn’t break anything, and any new features must be tested. In some ways, a technical debt sprint is business as usual for the testers on the team. Still, these sprints provide time for trying out new test tools and learning new techniques. Programmers, testers, DBAs, system administrators, and others on the team need to plan together and ensure that technical debt is addressed adequately in both tests and code.

On our team, testers take advantage of these sprints to upgrade to the latest version of our test frameworks and drivers. Here are some other tasks we’ve done during technical debt sprints:

1. Split automated test suites into multiple jobs in our continuous build process, letting them run in parallel so we get the feedback more quickly.
2. Put our FitNesse tests under source code control with the rest of the production and test code. This allowed us to track changes to test pages and tie the tests to the matching production code build version.
3. Install and learn how to use an integrated development environment to create and maintain automated tests.

Testers often pair with a programmer or a system administrator for these types of activities.

If they have good coding and design skills, testers may be able to refactor automated tests on their own. No matter what their technical skill level, testers can pair with programmers to refactor test code. Going forward, new tests will be much easier to add, taking advantage of libraries of test components.

Plan Your Technical Debt Sprint

In normal iterations, spend time on each user story to refactor production and test code, leaving it cleaner than you found it. If a task needed to reduce technical debt seems too big or too risky to try in a normal iteration where your team must deliver new business value, write it on a card and keep a backlog of “refactoring” cards.

Just