Is your development team complaining about technical debt? Or do you suspect that technical debt is a problem in the code? If you’re working with scrum, you might wonder how you can address the technical debt while still staying true to the scrum framework and agile principles. In this article, we’ll look at what our options are to tackle technical debt and still deliver business value at the end of the sprint.
Defining Technical Debt
Before we can even begin to handle our technical debt, we need to know what we’re talking about. There are many definitions of technical debt. Wikipedia has a good one:
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
So this means that we can take shortcuts when writing code to deliver faster. But these shortcuts often mean bad design and code that are harder to work with in the long run. At some point, we need to improve that code (pay down the debt) instead of making things worse (taking on even more debt).
A piece of code might be considered bad and technical debt by one developer, while another developer might regard that code as good. So we need a way of not only defining technical debt but also identifying it in our projects.
However, let’s take a step back and consider if this is even an issue we should care about.
Should the Product Owner Even Care?
Scrum defines several roles with distinct responsibilities. The product owner represents the client and is responsible for managing requirements with business value. The development team is responsible for the technical implementation.
Some people are of the opinion that this means the product owner shouldn’t care about technical debt and that it is purely an internal matter for the development team. This means the team must factor in technical debt when they make their estimates. Others would say that the work is there and you should make it visible.
The Agile Manifesto chooses “individuals and interactions over processes and tools,” so we should be able to have a conversation with the product owner about our technical debt. Scrum is a framework within the agile ecosystem. We can adapt scrum to our team, as long as we stay true to the intentions of agile software development.
So with that said, what are our options to address technical debt in a scrum team? First, we need to know how bad the situation is.
Identify Your Technical Debt
There are different ways of pinpointing technical debt. Automated tools will show you problematic code and even suggest fixes. But they might not catch all issues. Probably the first source of knowledge will be the ones working in the code.
Talk With the Team
Since scrum is a methodology within the agile world and the Agile Manifesto states to prioritize individuals and interactions, get a conversation started with the team about technical debt. How do they feel about it? How bad is it? What do they think needs to be done?
A good conversation, without finger-pointing, will give you good insights into team dynamics, emotions, causes, and possible solutions.
Make Stories in Your Issue Tracker
A traditional approach would be to have the team create issues in the issue tracker they’re using, like Jira. Maybe add a tag to the item so you can list all technical debt tasks at once.
For teams that choose to handle technical debt without their product owner knowing, this is their technical debt register. The development team is responsible for tracking, prioritizing, and discussing these items.
If the product owner is in the loop, these items can be added to the product backlog so that the product owner can prioritize together with the team. Often, though, product owners are under pressure to deliver business value, so technical debt stories or tasks may be pushed back.
Wall of Technical Debt
The Wall of Technical Debt is a technique that should be credited to Mathias Verraes. It’s an interesting way to show stakeholders how much time a team is spending on technical debt. In short, the team puts sticky notes on the wall identifying areas in the code they feel are blocking them and should be improved. On these notes, the team adds how much time they wasted because of the technical debt and how much time they estimate it would take to fix the issues.
After a while, both the team and the product owner can see where the team is losing time and where the low-hanging fruit is (e.g., simple fixes that will save a lot of time).
Metrics
There are many metrics that can point you to technical debt, like code coverage and cyclomatic complexity. Those are developer-centric metrics, and teams are encouraged to use them.
LinearB also contains useful metrics. LinearB pulls in data from a variety of sources that the development team is already using, without any extra work for them. The work breakdown is especially interesting when considering technical debt:
“New work” means adding new features. “Refactor” refers to changing old code, while “rework” means changing code that was only written in the last few days. These numbers can indicate the balance between innovation and technical debt.
These are just numbers, and there will always be refactoring and rework going on. But they can be the basis for a conversation with the team.
LinearB also has a section on metrics where you can dig deeper:
Two other interesting metrics are cycle time and coding time:
The longer these times are, the harder the team is finding it to finish features. Of course, for the real causes, you should have an open conversation with the team (people and interactions, remember?). But it can point to technical debt.
Addressing Technical Debt With Scrum
So now that you’re measuring and identifying areas of technical debt in the code, what options do we have in scrum to address it?
Dedicated Stories
One possibility is to create stories dedicated to technical debt. One or more specific areas could be added to the story, and tasks can then be defined. The team can make their estimates, and the product owner can decide when to add the story to the sprint.
This is, of course, assuming that the team is open about technical debt and that the product owner has a say in when to fix it. There is a risk that these stories will be postponed because features with business value are prioritized.
In my experience, this is not a bad option, especially for larger areas of technical debt and with mature teams that have a good relationship with their product owner. In such cases, this can definitely work.
Continuous Refactoring
Continuous refactoring is purely an internal affair for the development team. When a developer works in a piece of code for a new feature or a change request, they should see if any of the existing code can be improved. Maybe some of it was identified as problematic earlier. If so, then now is the time to improve it, however small, as part of the work for the new feature.
I strongly believe this is something the team should be doing, whether using scrum or not.
Dedicated Sprints
Sometimes, teams advocate for a sprint dedicated to technical debt, but I advise against it. Addressing technical debt won’t provide business value at the end of the sprint. This makes such a sprint clash with the ideas behind scrum—that you should deliver business value to the product owner.
A Fixed Amount of Time Per Sprint
Scrum aims to stop estimating and counting in hours, hence the idea of story points. Allotting a fixed amount of time can seem to clash with this idea. This approach lacks a definition of the work the developers will take on. And what if the developer starts working on something that takes more time than allotted? Or less?
These are questions that might push you back to estimating in hours, which scrum wants to avoid.
LinearB Can Help
Even though the Agile Manifesto prefers human interaction, it doesn’t rule out tools entirely. The nice thing about LinearB is that it won’t bother the developers. They can keep using the tools that make them productive (like Jira and Git) while LinearB will surface the metrics that interest product owners, CTOs, and VPs of engineering.
Also, LinearB won’t look at metrics for individual developers but at the team as a whole. This avoids a toxic blame culture or stack-ranking environments that lower morale and productivity.
If you decide to describe your technical debt in stories—for example, in Jira—you can put those in a separate category and LinearB will show you how much time you’re investing in them:
You can also see these numbers over time, spread across your iterations.
Scrum and Technical Debt
Scrum definitely leaves room for addressing technical debt in a way that suits your team best. It can be an internal affair of the development team, but it might also be something that can be openly discussed, using tools to identify and measure the technical debt. Making things explicit will empower product owners and developers to pay down the debt and improve the quality of the code. This in turn makes the code more fun to work in and makes developers more productive, enabling them to deliver more business value at the end of each sprint.
