Paul Tevis is on a team that is four months into a Scrum transition. The project has a significant amount of technical debt, and he is wrestling with the problem of how to track and pay down that technical debt. Tevis writes:
My concerns are (1) as soon as we start tracking non-story tasks we'll lose focus on delivering customer value, And (2) if we don't make these sorts of tasks visible, we won't make progress on them at the rate we need to. What are good patterns you've seen for dealing with technical tasks that aren't directly attached to a story (or that cut across multiple stories)?
What is technical debt? Ward Cunningham coined the term "technical debt" to refer to an obligation that an organization takes on when it decreases the quality of its code base in order to meet short-term goals. Bringing code quality back up invariably costs more to do later on than it would have if quality had been addressed immediately. This extra cost represents the "interest" on the technical debt.
Malcolm Anderson makes a case for taking on technical debt under certain circumstances:
There are a lot of reasons for taking on short term technical debt. I use the analogy of the credit card with a 36% interest rate. You do not want to use that card. But there are times when it makes great business sense to use that card in a short term situation.
But Adam Sroka objects:
If you were going to make that business decision you would at least want to know:When teams voluntarily take on technical debt they rarely (if ever) know the answer to even one of these questions.
- How much am I spending?
- How much interest will I incur? Over what period of time?
- Will I have enough revenue to pay it back?
Whether or not it was a good idea to do so, in Tevis' case the debt has already been incurred. So how can we best go about reducing existing technical debt in our projects?
Roy Morien offers two possible solutions to the problem of how to pay down technical debt:
Do you really have such a difficult choice to make? I would think that if your 'technical' development requirements are so important and so big, or so many, isn't it a practical thing to do to call a timeout on user-facing development, and get those technical matters squared away and off the table?Or, is it possible to reassign some developers to get these technical matters done, while the rest of the team continues on the user-oriented stuff? This may affect team velocity, but so what?
Ron Jeffries disagrees with these two approaches, however:
Working on the "technical matters" works best when it is driven by stories. The code base is probably in need of work everywhere, but the payoff will be received only where the code is going to be worked on for user-facing reasons. If no stories are going to pass through some crufty area, working on it is largely wasted.
Therefore, I prefer the approach of taking stories as usual (but probably fewer of them), and following the "boy scout rule" of leaving the campground better than you found it. In other words, wherever the stories lead us, let's write more tests, let's refactor more aggressively.
This approach has at least these advantages:
- maintains "best sensible" flow of stories;
- provides help from all team talent;
- provides for whole team to learn how to keep code clean;
- focuses improvement exactly where it is needed;
- does not waste improvement that "may" be needed;
... and probably more.
And "banshee858" offers this suggestion (with original credit to Tobias Mayer) that dovetails nicely with Jeffries' approach:
List all the technical debt stuff on little post-it notes Adjacent to the Task Board. When a Product Backlog item (PBI) is selected for a Sprint, look at the technical debt pieces and find the pieces that make sense to finish while working on the PBI. Add those to the scope of work for the PBI and estimate how long it will take to complete the feature and the technical debt pieces.That way you make the technical debt work visible, you can prioritize it and link it to real value.