I wanted to write about how to illuminate technical debt. Luckily I noticed that my colleague Martin Stühmer had already written an article on this subject. This is available on the website Daily DevOps & .NET. You can also find his article and more exciting information on Microsoft .Net, MS certifications and IT architecture on the website.

In line with Martin Stühmer’s article, you can find more IT architecture articles on our blog. There is also a the german version here.

Illuminate Technical Debt

Whatever our role, be it developer, IT professional or architect, we try to avoid technical debt. If this is not possible from the outset, or if we decide to accept this technical debt for a limited period of time, we usually lack the tools to do so. This is where this article may help to Illuminate Technical Debt.

What is technical debt?

Technical debt is a metaphor we use to describe the costs and risks incurred as a result of decisions or omissions. It is important to note that this metaphor applies to all types of technical debt.

First, there is architectural debt, which is usually based on a decision made by an individual architect or group of architects. Then there is implementation debt, which is probably the most common in most projects, as it is also identified through source code analysis. We know there is the test and documentation debt, which we far too often neglect.

Whatever the type of technical debt, the common denominator is that it tends to cause problems in projects and later in operations. In July 2011, Phillipe Kruchten described them as “invisible negative elements in the backlog”.

However, we rarely record and visualise this.

How can I still make them visible?

In most projects, it is individuals or a small group of individuals who are aware of individual Technical Debts. However, these projects usually have another thing in common: when these technical debts are addressed, they are postponed or even dismissed.

So we can avoid this, we need to track it in the same way as requirements or defects. All you need is a person with administrative rights in Azure DevOps or comparable platforms.

Extension of the Azure DevOps process templates

Azure DevOps provides the ability to visualise technical debt by extending process templates. The Microsoft article [Customize a process template] (https://learn.microsoft.com/en-us/azure/devops/reference/process-templates/customize-process?view=azure-devops) details how to inherit and extend a process template to achieve the following result.

In this case, we extend the process templates AgileRCDA and ScrumRCDA by an additional WorkItem type, which we use in the future to record and visualise debt. In 2011, Kruchten already used the colour black for the colour scheme of technical debt.

For later prioritisation and sorting, it is advisable to pass additional parameters to the WorkItem type, such as

This creates the technical foundation based on the process templates, and within the project we only record the technical debt type work items.

Summary on Illuminate Technical Debt

The Azure DevOps extension (or alternative platforms) presented here takes only a few minutes to extend and deploy. But it will have the desired effect by the next sprint meeting. That’s because the black work items of the “technical debt” type quickly give the impression of a tombstone and provide the necessary visibility.

Don’t be surprised if the tombstones start to pile up after a few weeks. Your colleagues and team members know about other Technical Debts that you probably haven’t noticed yet.

How to get involved into this topic

For more details always feel free to reach out to Martin Stühmer and me on LinkedIn and follow our discussions around Software and Infastructure Architecture there.