Lot of people asked me why do they need “Technical Debt” sprints. In my experience lot of product owners don’t see value in these sprints. I would like to make an attempt to answer that question.
Technical debt is the unfinished work due to the short cuts taken by the team to deliver a story faster. This could be due to an impending deadline or under estimated effort or what ever. It is necessary for the team to periodically clean up that code before it gets unmanageable. Some one asked me that if the team is doing a ruthless re-factoring as one of their practices, why do they need technical debt sprints? Though the team is disciplined, it is not possible all the time to re-factor, for several reasons. For example, if there is lot of legacy code with no tests around it, it would be hard to change that code.
Besides all the reasons said above, in my opinion it is a strategy how the team wants to work. The work done in a quarter or six months is going to be same whether 1) the team doesn’t leave any debt, in which case they work slowly or 2) leave some technical debt and take care of it at the end (of quarter or six months). IMO, the later choice would lead to a better outcome since the team would have a better understanding of the debt. So, I always recommend a periodic technical debt sprint in addition to continuous re-factoring.
I recently came across a game that explains technical debt and results of not paying it back. This game is designed by Software Engineering institute (SEI) and called “Hard Choices”. Read about the original game at http://www.sei.cmu.edu/architecture/tools/hardchoices/ . Basically the game has the aspects of taking shortcuts (creating debt) and paying it back (losing a turn). If you don’t pay it back, it will slow you down.
I actually played it differently. I have three players and they move with the same roll of dice. However, there are rules for each player:
Player 1: Always takes the shortcut, but never pays back.
Player 2: Always takes the shortcut, buts pays back right away (by losing the turn).
Player 3: Never takes short cut.
At the end, player 2 won as I expected. Player 1 and 3 reached the end almost at the same time.
I looked at the board carefully and figured out that if I change the positions of the bridges, I could make it event clear on how player 1 is going to suffer at the end. In this case, even player 3 is likely to reach the end ahead of player 1.
In summary, technical debt sprints are very much required to keep the backyard clean. This will at least allow the team to maintain the velocity, if not there is a big improvement.