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.

What is technical debt?

Technical debt is a metaphor used to describe the costs and risks incurred as a result of decisions or omissions. It is important to note that this metaphor can be applied 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. And then there is the test and documentation debt, which is far too often neglected.

However, they are rarely recorded and visualised.

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.

To avoid this, Technical Debts need to be tracked 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, the extended process templates AgileRCDA and ScrumRCDA were simply extended by an additional WorkItem type, which will be used in the future to record and visualise technical 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 only the technical debt type work items need to be recorded.

Summary

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.