5 Ways to Tackle Technical Debt in Scrum – Make Small Improvements For Big Gains

Technical debt happens in all software projects, regardless of the languages, frameworks, or project methodologies used. It describes the costs associated with each engineering decision made in a project. Often, quick-fixes will create a deficit in the system. Unless they are paid off, this will compound and cause a greater amount of debt over time.

We use this term to explain to people who don’t fully understand software development practices that there is a definite cost to rushing things. Much like monetary debt, you need to make a plan to reduce the technical deficit over time or it will spiral out of control.

Developers, like savers, have opinions on the best way to tackle debt. Some like to do small things regularly to keep debt down. Others let debt build up so that in the long run, a more drastic change needs to be made.

In this post, we share five ways to tackle technical debt in scrum. We’ve focused on scrum methodology for software development because it is a widely respected and adopted framework. Also, it provides us with many chances to pay off technical debt as part of the standard development workflow.

Take a look at these ideas for reducing technical debt in scrum.

1. Mention Technical Debt in Stand-Up

The majority of project teams that practice scrum have daily stand-ups. These are short meetings where the team shares a brief status report, their plans for the day, and highlight any blockers. They give everyone a quick overview of where things are and where things are heading.

If you are working on something that feels like it might create technical debt in the future, it is worth highlighting during these stand-ups.

Someone else on the team might have a suggestion about how to tackle the problem in a way that doesn’t incur debt. At the very least, it lets the project manager know that this is something that may need attention in the future.

2. Adjust Your Definition of Done

If you are writing tickets correctly, each one will have a definition of done. The definition of done is a series of tasks that will be true when the ticket is complete. When all are confirmed, you can close the issue.

Writing a good definition of “done” is a skill. A thorough explanation of “done” should include the tasks required to ensure that technical debt is addressed.

For example, if you’re using old code for your payment provider, and you have a ticket in that includes using some of the payment provider code, the definition of done could include “updates to version 3 of payment provider API.”

Adding tasks to your definition of done will increase the amount of time necessary to complete the ticket, but once complete, you won’t have to worry about old code slowing down development work.

3. Refine Your Code Review Process

There are several ways that technical debt can accrue in a project. One of the most common ways is a known technical debt. This is when a team or a team leader decides to do things a certain way knowing that this will cause issues down the line.

Another is unknown technical debt, where a code change wasn’t properly scrutinized.

Luckily, proponents of scrum almost always have a code review process as part of their development work. This process can help mitigate some of the risks involved in unknown technical debt.

Code review is the process by which someone who didn’t write the code reviews it, makes comments, and ask questions. Often, the reviewer is able to spot issues that the original developer didn’t think about.

If code is frequently passing the review but is later found to be the cause of technical debt, it may be time to refine your code review process.

Having debt-based code review doesn’t mean that code can never incur debt; it just means that no hidden debt should sneak past code review.

4. Create Tickets in Your Backlog

Sometimes, the technical debt is such that developers can’t address it unless it becomes a task. In scrum, there’s the notion of backlog. The backlog is where all tickets originate. During spring planning for the next body of work for the team, tickets move from the backlog into a to-do list.

It is completely fine for a ticket to address technical debt. It should get treated like any other ticket. Developers should discuss it like they do other tickets. If deemed important enough, it should make its way out of the backlog and into the next body of work.

Creating a ticket in your backlog suggests that there is a dedicated body of work that needs to be done, probably over several files or touching several parts of the system. When a team creates a technical debt ticket, it’s important to reflect on whether that made sense, or whether it would have been more appropriate to take one the actions mentioned earlier in this list.

5. Add a Project to Your Product Roadmap

The product roadmap is a high-level document used to communicate what projects need to happen for a product to achieve its product vision.

Usually, the types of projects you see on a roadmap are targeted to things that end-users of your product need.

There are some occasions in which you can argue for the need to add a technical debt project to the roadmap. This would be the case when significant time needs to be invested in the solution, more than would be covered by a few weeks of work.

Just like creating a ticket in the backlog, once a project is created in the roadmap, it should be evaluated along with all the other projects to determine a priority.

Always Provide Value

Whether you’re casually mentioning a potential issue during stand-up, or helping to create an entire project to fix some technical debt, you always want to make sure you are providing value.

How do you feel about technical debt? Do you try and pay it off immediately and put things in place to stop it from happening? Or do you let it pile up until it can’t be ignored anymore? Let us know in the comments below.