How to tackle technical debt (for teams using Scrum)

Technical debt happens in all software projects, regardless of the programming languages, frameworks, or project methodologies used. It is a common metaphor for software’s accumulated backlog (like bugs, missing documentation, and legacy code).

Here you can read more about technical debt explained, but you’ll need to pay that debt off sooner or later. If you don’t, over time, it will compound and cause greater debt and issues in your software.

So how can you do it? In this post, we share different ways your team can start by identifying and tackling technical debt while delivering value at the end of each Sprint. Let’s dive in!

Identify technical debt

There are different ways of identifying technical debt. Automated tools can be great allies in showing you problematic areas in your code and suggesting fixes. But your team will prioritize the debt according to your needs and goals. In fact, developers will be your best source of knowledge since they work with the code.

Talk with your teams and mention technical debt in meetings

The first step is to discuss the technical debt with your team. Ask questions to understand their perspectives on it:

• How does your team feel about technical debt? 
• How bad is technical debt in your codebase? 
• What does your team think needs to be done?

A good and honest conversation will give valuable insights into team dynamics, reasons, and possible solutions for previous technical debt.

You can also use the meetings to discuss the future technical debt. For example, it’s worth mentioning during these meetings if you are working on a feature or functionality that might create future technical debt. There are two main reasons for this:

1. Other team members might have a different approach on how to tackle the problem in a way that doesn’t incur future debt; 
2. It lets the project manager and the entire team know that this is something that may need attention in the future, and you can better plan for it together.

Look at your metrics

Another great way to find technical debt in your code is by using metrics. Of course, no single data point will give you a precise understanding of your technical debt, but a collection of metrics can help you build a better picture and point you to technical debt. Some good metrics to track are, for example:

• The number of new issues vs. the number of closed ones – If new issues outnumber closed ones, you might need to make some changes fast.
• Overall quality and complexity of your code – Here, we’re talking about metrics like cyclomatic complexity, class coupling, and depth of inheritance, where you should aim for the lowest possible score.
• Cycle time – It measures the time it takes for your team to complete work items once they begin working on them. For example, if your team spends several hours fixing minor issues, your code might have some technical debt.
• Code coverage – It tells us what percentage of our code is covered by tests. For most software, 80%-90% code coverage is an excellent score. A lower code coverage indicates that your team needs to work on improving the number of tests in your codebase.

Add technical debt to your issue tracker

After and when your team identifies technical debt in specific parts of your code, they should create issues in the issue tracker they’re using. It might be helpful to add a tag to the item so that you can filter and list all your technical debt at once.

You should track, discuss and prioritize all the items and add them to the product backlog. Don’t forget that technical debt should not be overlooked and pushed back all the time, even with pressure to deliver value.

Tackling technical debt

Now that you’re identifying and keeping track of areas of technical debt in the code, what options do you have to tackle it? 

It might seem daunting at first, but remember that keeping things explicit will empower all your team, from product owners to developers, to pay down the debt and improve the code quality. Plus, your developers will be more productive, enabling them to deliver more value.

Have stories dedicated to tech debt

One way to address technical debt is to create stories dedicated to it. For example, you can add a particular area of your code to the story and define specific tasks. Your team would then make their estimates, and the product owner could decide when to add the story to the sprint.

This is a good option if you are open about technical debt and have a mature team with a good relationship with their product owner. Plus, keep in mind this is not the same as having a sprint dedicated to the technical debt since, in that case, your team would not be providing value at the end of the sprint – despite all the benefits of paying out debt.

Add a project to your product roadmap

We know – usually, the types of projects you see on a roadmap are related to new or improved features. However, there are times when adding a technical debt project to the roadmap can be beneficial. This would be the case when significant time needs to be invested in the solution for the technical debt, more than would be covered by a few weeks of work.

Once you create a project in the roadmap, you should evaluate it along with other projects to determine a priority. Your team should then set aside time to resolve the technical debt periodically.

Focus on gradually refactoring instead of a great refactor

It might be tempting to do a great refactor, where developers spend some time reworking code without delivering new features. However, a better approach is gradually refactoring.

How does continuous gradually work? When a developer is working on a piece of code for a new feature or a change request, they should see if they can improve any existing code, especially if your team has already identified it as problematic.

Adjust your definition of “done”

If your team is writing tickets correctly, each one will have a concrete definition of “done” – a series of tasks that will be true when the ticket is complete, and you can then close it.

We know that writing a good definition of “done” is both an art and a skill. However, remember that a detailed definition of “done” should include the tasks required to ensure your team addresses technical debt. This will also help the process of gradually refactoring your code.

Improve your code review process

It might be the case where your team is accruing technical debt to your code because code changes are not adequately analyzed. If your code is frequently passing manual code reviews, but then it is the cause of technical debt, you should improve your code review process.

Having a debt-based code review doesn’t mean you’ll have zero technical debt. In fact, it means that no hidden debt should sneak past code review unnoticed, so you’ll always know where you are regarding technical debt.

Plus, consider having an automated code review process in place. As we saw, manual code reviews can be error-prone, and you can miss essential rules that should be checked and enforced in the code. Therefore, automating your code reviews significantly impacts your code’s quality (and the amount of technical debt).

Codacy: the go-to solution for tackling technical debt

We run a DevOps Intelligence Platform that helps thousands of developers ship billions of lines of code per day by automating and standardizing code reviews. We’ve built a suite of products that help developers quantify and act on their software quality, engineering performance, and security.

Codacy is the best-in-class solution for static code analysis. Integrating seamlessly into your workflows, Codacy helps engineering teams save time in code reviews and tackle technical debt. Codacy supports 40+ programming languages and is available in free open-source and enterprise versions.