Technical debt is a commonly used phrase, especially when quoted as the reason why “things take so long.”
Taking up debt can also be a great way to speed up the development process and deliver faster.
Ultimately, tech debt is neither bad nor good. It all comes down to proper debt management. Yet, most people who talk about tech debt don’t monitor it.
The main reason for the lack of discussion is the ambiguity and fear surrounding the concept. It’s hard to manage something you can’t clearly see and assess, but there are ways to make tech debt and its management more tangible.
One of them is a tech debt register.
In simple words, a technical debt register is a backlog of all known debt.
It doesn’t have to be a separate Jira backlog or a spreadsheet (although, if that works for you, then why not). The technical debt register is an integral part of the product backlog.
Look at your product backlog, filter out all technical issues, and, voila, you have a register of all your debt.
Here is an example of what a technical debt register looks like:
A tech debt register brings additional transparency and clarity as to what type of and how much debt you have. That clarity should help you make better decisions in the future.
There are two primary steps to creating a technical debt backlog
Defining technical debt comes close to defining the meaning of life. Put two product managers in one room, and I bet they won’t come up with the same answer.
There’s no formal definition of what debt is and isn’t. There never was and there never will be. That’s not really important, though. What matters most is for your team to have a cohesive and aligned definition of debt.
Is the bug a technical debt? Is the lack of E2E tests a debt? Are performance issues a debt?
These are the questions that each team has to answer on its own. We all have a somewhat different picture of concepts, such as agile and product development. Use the definition that works best for your general context.
The traditional definition technical debt is the difference between the current technical state of the product and the desirable one.
Meaning that, if I’m building an app that I believe should be covered with automated E2E tests, I treat the lack of these as a debt. On the other hand, if it’s a small app that we don’t ever plan to cover with automated tests, I don’t count the lack of automation as debt.
In other words, something that one company defines as a debt, another company might not. It all depends on your definition and your goals.
I try to answer the question, “What is the ideal technical state of this product?” Then, I list out all the differences between the ideal state and what we currently have. It could include:
For the technical debt register to be actionable, you need to estimate it. After all, 30 tech debt positions might mean a day of work or two years of development freeze.
I recommend you estimate it exactly the same way you estimate other product works. If you use hours for your user stories, then estimate debt in hours. If you use story points or t-shirts, then do the same with debt.
Tech debt items are usually so ambiguous that it’s hard to give a precise estimate, but that’s OK. At the end of the day, all you need is the general scale of the tech debt register; it does not need to be measured on an individual debt item level.
You invested all this time to define, capture and estimate debt. Great. Now what?
A tech debt register is only useful if it’s used to draw insights. My favorite ways to use the register are to:
The tech debt ratio answers how many sprints you need to pay off all known debt.
Tech debt ratio = technical debt / velocity
For example, suppose your technical debt register is estimated at 400 story points and your average velocity is 70. In that case, your tech debt ratio is 5.7, which means you need roughly six dedicated sprints to pay off all the known debt.
Due to lack of precision, it’s probably far from the truth. But it does give us some sense of scale.
Now, you’re probably asking yourself, “Well, is a 5.7 high or low? Is it a good thing or a bad thing?”
You’re going to hate me for saying this, but — it depends.
Every product should have some guardrail for optimal debt range, and these depend on:
For MVPs, where speed is the most important factor, 5 might be low debt. For mission-critical military software that requires both reliability and fast upgradability, 3 might be already too high.
Define the ratio you believe is most optimal in your specific context (e.g., 3–7) and monitor the register to keep your debt in check.
Too high a tech debt ratio is a signal that perhaps it’s time to slow down and fix some issues before they become a problem. On the other hand, the low tech debt ratio isn’t necessarily a good thing, either. It might mean you are sacrificing speed and flexibility for excessive technical excellence.
At the end of the day, it’s more an art than it is a science. It takes months of experimenting and conscious debt management to discover the best ratio. But, don’t fixate on specific numbers, and try not to be too precise.
Ultimately, it’s not about specific tech debt numbers but about the conversations these numbers bring.
The tech debt register is a great conversation starter.
Sit down with the team, take a look at your debt register, and ask yourself a few questions:
Discussions around the tech debt register are often more valuable than the register itself. Make sure your discussions take place regularly.
You should try dedicating 10 minutes of every sprint review to your debt review or have an entire dedicated session once a month. In any way that works best for you, have that conversation regularly.
Most of the teams are aware that they have some technical debt. But very few of them regularly discuss them. It’s like money management. If you don’t discuss it regularly, and teach it to your kids, you can’t expect them to be good at managing money later in life. The same goes for tech debt and software teams.
Although technical debt is a critical concept for software product delivery, it’s often quite ambiguous. You can use the tech debt register to make it more tangible.
Bring your tech debt management to another level by:
Ultimately, technical debt can be your best friend or worst enemy, depending on how consciously you manage it.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
