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.
Table of contents
- What is a technical debt register
- How to build a technical debt register
- How to manage a technical debt register
- Perform regular reviews
What is a technical 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.
How to build a technical debt register
There are two primary steps to creating a technical debt backlog
1. Define what you consider tech debt
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:
- Bugs
- Lack of automated tests
- Underperforming architecture
- Legacy or spaghetti code
- Data security problems
- Broken development pipeline
2. Estimate tech debt
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.
How to manage a technical debt register
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:
Monitor tech debt ratio
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.
What is a good technical debt register scale/ratio?
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:
- Maturity of the product
- Current priorities
- Type of product
- The cost of paying off the future debt
- The cost of missed opportunities (if you focus on technical excellence over speed)
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.
What does a high/low ratio mean?
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.
Perform regular debt reviews
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:
- How do you feel about your current state of debt?
- Are there any big risks or red flags there?
- Did you take any new debt recently?
- Did you pay off any debt recently?
- How did your tech debt ratio change? Is it still within a desirable range?
- Does your tech debt range still fit the current stage of your product? Should they be adjusted?
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.
Summary
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:
- Defining what technical debt means to you
- Capturing all known technical debt
- Estimating it to understand its size
- Controlling tech-debt ratio
- Having regular discussions around the register and the debt itself
Ultimately, technical debt can be your best friend or worst enemy, depending on how consciously you manage it.
Featured image source: IconScout
The post How to use a technical debt register appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/1A7infe
Gain $200 in a week
via Read more
