In an effort to reduce technical debt, I often find my clients creating “Technical Stories” – stories typically originating from the Tech team instead of the Product Owner. Often these technical stories latch onto a Product Backlog Item (PBI) and spawn into a life of it’s own as a code refactoring or architectural foundation effort which should realistically stand on it’s own as a separate initiative.
Ward Cunningham coined the term – referring it to an obligation that the team assumes when it decreases code quality to meet short-term business goals. The cost of bringing the code to quality later translates to the “interest” in technical debt.
In an ideal world, the team would built in quality up-front as they code. The reality is that sometimes compromises are made to meet an immediate business need. Agile teams (particularly those completing the ‘forming’ or well into the ‘norming’ phases) are conditioned to think and deliver in terms of MVP – minimal viable products.
Often times this results in what Brad Appleton puts as “design that is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery.”
Technical debt can be incurred not only by under-engineering as above, but also by over-egineering such as the case in code-base refactoring or architectural restructuring.
If we shouldn’t write Technical Stories, then how can we bring down our technical debt? Newly formed Agile teams or organizations undergoing an Agile transformation typically inherit technical debt from previous/existing projects.
Invariably, I coach my teams to avoid writing Technical Stories and work towards addressing technical debt within the context of business driven PBIs.
Ron Jeffries suggests a similar approach:
“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.
A technique I recommend to my teams (credit to Tobias Mayer) is to take an inventory of all their technical debt and create a Kanban board prioritizing each item and placing the board adjacent to the Sprint Task board. This reminds the team to check the Technical Debt board to see which debt items intersect with current PBIs. This is also a valuable visual tool for both the Architecture team and the Business to plan, prioritize and schedule larger scale initiatives.
Increasing the transparency between product and technology (a self-imposed boundary often the source of contention and misunderstanding) can keep both forces flowing in the same direction.