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:
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.
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:
- Refactor enums to have consistent lookup() method. In some enums, it was spelled as lookUp().
- 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.
- Refactor automated API-level and GUI-level automated tests, extracting duplication and making tests easier to understand.
- Remove an unused database column from a table.
- Rename a database column in several tables and in the code for consistency.
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