To understand the problem with technical debt roadmaps, we’ll start with a quote from renowned philosopher, Homer Simpson. “If you have a problem, ignore it. It’ll go away,” the famous TV dad advised his family on dealing with challenges.
When you create a dedicated roadmap for technical debt, you are removing the problem from your immediate sight. And by doing this, it becomes easy to ignore (or, just as bad, hide) problems in your code that inevitably appear over time. Contrary to Homer’s view, ignoring these problems will only make them worse.
In this article, we’ll discuss why technical debt roadmaps don’t work. And we’ll provide a constructive alternative for dealing with your team’s technical debt. Below we’ve explained the definition of technical debt a little further.
What is a Technical Debt Roadmap?
Some product managers think of technical debt as flaws in their products. (They’re wrong about that. Technical debt is a natural part of all software development.) This worries them because they know they will have to deal with the technical debt eventually. (They’re right about that.)
But these product managers prefer to sweep it under the rug for as long as possible, rather than facing it head-on. So they create a separate roadmap just to track the product’s technical debt. You can call this a technical debt roadmap, or a refactoring roadmap. We call it a mistake. Here’s why.
3 Dangers of Technical Debt Roadmaps
1. Out of sight, out of mind.
Think of a standalone technical debt roadmap as the junk drawer of your product roadmap. How often do you want to look inside a junk drawer?
This is one reason we don’t believe managers should separate their technical debt issues out from the rest of the strategic items on their product roadmaps. To plan and prioritize effectively, product teams need access to all relevant information. They need to be able to weigh costs, benefits, and other factors against each other and decide which initiatives should receive the organization’s limited resources during any given period.
When you move all of your defects, refactoring, and other technical debt details to a separate document, you lose some of this relevant information, which could affect your priorities and decisions.
Keeping these issues isolated from your strategic roadmap will increase the chances you won’t get to them when you should. That will lead to the second danger of these roadmaps.
2. The longer you wait, the more dangerous technical debt becomes.
Planned technical debt is a type of development shortcut. Think of it as a loan (in effort saved, not money borrowed) that you take out today to help you achieve your product goals more quickly. You will have to repay this loan, of course, and the interest will come in the form of more difficult and time-consuming coding work in the future.
You can plan and budget for repaying your product’s technical debt, in the form of corrective coding called refactoring. This type of planning, regularly scheduled refactoring can keep your product code clean and up-to-date. Plus, the more often you devote resources to refactoring, the lower you can keep the interest payments on your technical debt.
But again, if you separate the technical debt issues from your product roadmap, and place it all on its own roadmap, your team is more likely to put off making these important refactoring payments. And the longer you wait to deal with technical debt, the more work it will require later and the more disruptive that work will be.
3. Keeping technical debt hidden will create more difficult conversations with stakeholders.
Keeping your technical debt front and center on your product roadmap will help you set stakeholder expectations.
When an executive asks why your team cannot meet a certain deadline for a new feature, you should be able to point to the fixes, refactoring, and other technical debt work also demanding your team’s resources.
This will give you a chance to explain how making these regular commitments to knocking down technical debt helps keep your product operating smoothly and ready for upgrades and new functionality. Ignoring technical debt or kicking it down the road, by contrast, will increase the chances your product will require major refactoring work or even experience catastrophic problems at some point.
But if you’ve hidden your product’s technical debt on a separate roadmap, one that your stakeholders don’t see when you present them your product roadmap, they will have no way of knowing just how much work your team must devote to development tasks that won’t result directly in the exciting new features they’re hoping to see.
How to Include Technical Debt on your Product Roadmap (where it belongs)
We’ve made the case against developing a standalone roadmap just for your technical debt. Where, then, should you track it?
Your technical debt belongs on your product roadmap—alongside your epics, themes, and any other strategic elements of your product’s plans and goals. (Yes, technical debt is a strategic element of your product.)
As product evangelist John Cutler puts it, “make technical debt a first-class citizen.” You can do this by including it on your strategic roadmap, giving your cross-functional team visibility into how much debt your product has at any moment, and making it a regular part of your prioritization decisions.
Here are a few ideas for handling technical debt on your product roadmap.
1. Create a dedicated “technical debt” swim lane.
This will make it easier to get an at-a-glance view of your current technical debt. It will also help you build into your product team’s culture a sense of the importance of monitoring technical debt to ensure it doesn’t become too big and difficult to manage.
2. Tag your technical debt items.
Assuming your team uses native roadmap software, start tagging fixes, refactoring work, or related issues as technical debt. This way, anyone on your cross-functional team can open your roadmap and find all open tech debt issues with a simple keyword search.
3. Make regular time for technical debt on the roadmap.
One example of this strategy would be to set aside time for technical debt. This could be between product iterations, after sprints, or at whatever intervals make sense for your team. This will reinforce in your organization’s culture the importance of addressing debt and also help keep it from growing too large.
Technical Debt Belongs on your Roadmap.
Technical debt is not necessarily a bad thing. For most companies, it is just a reality of developing software. But, what is bad is ignoring or hiding your product’s technical debt.
This is why we recommend against creating a separate technical debt roadmap. Instead, incorporate your team’s code debt right into your main product roadmap.
