Image for post
Image for post
Technical debt is like a loan. The longer you postpone paying it back, the more interest you pay

How to deal with Technical Debt in Scrum

Christiaan Verwijs
Jan 19, 2018 · 7 min read

Technical debt is one of the greatest frustrations and de-motivators of the Development Teams I work with. Teams generally have no difficulty summoning up examples of technical debt in their codebase. Shortcuts in the code, low-quality code, temporary-but-not-really workarounds and other hacks that may bring short-term solutions but guarantee long-term pain. Development Teams are often acutely aware of the accumulation of technical debt, but feel powerless and unable to explain why technical debt should be a priority. Instead, they feel that ‘business keeps adding more features over stabilizing the foundation’.

In this post I offer four practical tips on how to make technical debt transparent and how to help ‘business’ make a better trade-off between code quality and new features.

There’s also a podcast episode based on this post. So if you prefer to listen instead of reading, then this is for you.

1. Use powerful metaphors

Metaphors are powerful tools to create understanding. ‘Technical debt’ is such a metaphor itself. Originally coined by Ward Cunningham, and further expanded upon by Martin Fowler, it equates the writing of low-quality code to incurring financial debt. When low-quality code is written with the promise of improving it later, technical debt is incurred with the promise of paying it back later. But the nasty thing about debts is that you have to pay interest. And the greater the debt, the greater the interest. Until you find yourself spending all your time dealing with the interest. In the case of technical debt, the interest represents the time spent (or more accurately: wasted) on dealing with the fallout of incurred technical debt. Like bugs, code that is hard to understand and/or change, code that easily breaks and security risks. Sometimes we’re ok with some technical debt, and the resulting interest, but more frequently we’re not. The following visualization explains technical debt, and the consequences, even more poignantly:

Image for post
Image for post

2. Take responsibility as Developers

An important step is to stop acting like a victim. Take responsibility for (maintaining or improving) code quality as a team. This is not coincidentally heavily emphasized by the Scrum Guide. Use the tips in this post to put ‘technical debt’ on the agenda and make it transparent. Push back when you, as a team, feel that code quality is dangerously sacrificed in favor of adding more features. Make sure that any estimates that the team generates include the work that is needed to write sufficient-quality code. When necessary, extend the Definition of Done with aspects related to fighting technical debt (e.g. ‘code coverage should at least remain stable when new features are added’ or ‘code should be in accordance to our coding conventions’). Always make technical debt a part of the dialogue with the Product Owner, your stakeholders and the broader business. But also be emphatic to their needs.

3. Use Code Metrics to quantify Technical Debt

  • Cyclomatic complexity: This metric quantifies the complexity of your code by analyzing the number of branchings in the code compared to the total number of lines of code. An if/then/else statement, for example, has two branchings. A switch/case statement has as many as there are cases. The higher the cyclomatic complexity, the more difficult code generally is to maintain.
  • Code coverage: Code coverage is the percentage of your code that is covered by unit tests. A lack of unit tests is a source of technical debt, as unit tests both document and verify how classes are supposed to work. Most IDEs and CI-servers can calculate code coverage for you. Going for 100% shouldn’t be the goal, and easily leads to a lot of useless unit tests that take a lot of time to maintain. Instead, focus on unit tests for business rules and classes with important logic. A good rule of thumb is to make sure that the coverage stays at least the same when new code is added.
  • SQALE-rating: a metric that offers a broad evaluation of software quality, based on a number of internal rules. The scale goes from A to E, with A being the highest quality. Most specialized code quality plugins can calculate this rating (see below);
  • Number of rule violations: this metric calculates the number of rules violated from a given set of coding conventions. Violations are usually grouped in categories, from critical to minor
  • Bugcount: as technical debt increases, quality of the software decreases. The number of bugs will likely grow. Monitoring the number of (critical) bugs that pop up is a simple but useful metric to track;
  • Cost of Delay: this (mostly manual) metric helps to make visible how much time a team loses due to technical debt;

There are many tools and metrics available to quantify technical debt. Most of these tools are based on ‘static code analysis’ and can often be run from within the IDE or from build- & integration-servers. I’ve listed a few below as inspiration.

Image for post
Image for post
NDepend in action

NDepend is a plugin for Visual Studio (.NET) that offers a boatload of metrics. Especially useful are the SQALE-rating (from A to E), the percentage of technical debt incurred so far and the number of days needed to repair this (a rough estimate, of course). NDepend can also generate a heatmap of the classes that are prime candidates for refactoring — very useful. The Visual Studio IDE (starting from Professional) also offers a number of built-in metrics, like Cyclometic Complexity.

Another option is SonarQube. This platform easily integrates with most CI-pipelines and IDEs and automates a huge number of code metrics (including the SQALE-rating).

Image for post
Image for post

Although these metrics are sometimes rough and imperfect, that’s no reason to discard them. The metrics do help people understand the consequences of technical debt, and helps them make more informed decisions about code quality. Teams that inspect these metrics (at least) during the Sprint Review tend to have excellent and balanced discussions about technical debt. A far-cry from the lack of understanding that often characterizes teams that don’t use these kinds of tools.

4. Make Technical Debt transparent on the Product Backlog

Another option is to agree with the Product Owner to set aside a percentage of the time in a Sprint to deal with Technical Debt as the Development Team sees fit. There is a risk in this approach that Technical Debt (and what is being done about it) remains invisible to everyone outside the Development Team. So make sure to create items for the specific improvements and put them on the Sprint Backlog during the Sprint Planning.

Closing thoughts

But transparency alone is not enough. Development Teams should also take the responsibility for reducing technical debt. While balancing the needs of the stakeholders with the quality of the code, they should prevent the accumulation of technical debt over time and explain how and why this impacts stakeholders. Together, they can then create amazing products.

Image for post
Image for post
You can already support us with $1/month. Find out more on patreon.com/liberators

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Christiaan Verwijs

Written by

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Christiaan Verwijs

Written by

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store