If you’re a product manager and your first question hitting this article is ‘what is technical debt anyway? Never heard of it’, this article is a must read.

I’ll keep t as simple as possible to make you understand its importance and its relation towards your product development speed.

What is technical debt

So what is technical debt really? It’s basically the technical version of financial debt. Building software is like buying a house: you create debt. The difference is that technical debt has no explicit form like a bank loan with monthly statements.

It comes in very technical terms and sits mostly within the code, infrastructure or third-party services of your product.

Most of your technical debt will have 1 thing in common: lifetime. Even in software, code has a certain amount of lifetime to it. It doesn’t live forever and needs to be changed or replaced somewhere down the line.

…here is a true fact:

Technical debt will always be there, no matter what. It will haunt you for the rest of your product manager career. It also affects if you can release your product on time or will always struggle while delivering over time/budget. Building software is fun, right?

What are the most important causes of technical debt?

It comes in many shapes and/or forms. I’ll just run through the most common categories I encountered in most projects:

1. Shortcuts

No product manager can deny they never allowed shortcuts. Taking shortcuts means you use code that’s only reaching bare minimum for product requirements, usually not the best quality and will probably fail somewhere down the line. Due to pressure on delivery, shortcuts can be tempting to take without knowing the true consequences.

2. (Outdated) libraries/ frameworks

Every developer uses code they haven’t written themselves (thanks to the global open-source community). We use libraries and frameworks to make building software easier, faster and more cost-efficient. It also creates a challenge: maintaining third-party code. Developers can have several types of issues with a library as a survey revealed:

Project can be poorly maintained overtime and create issues with maintaining or expanding own functionality. Support can be a big issue when the owner of the project doesn’t go in the direction your developer wants them to go. What seemed efficient at first can create road blocks longer term. Replacing or overhauling such components can take months and create a backlash in your product development.

3. New product development

You eager to get that new killer feature build. Your developers point out your current data layer or application stack isn’t really ready for such magic.

And to be honest to your stakeholders, you’re actually not sure if that feature is actually killer. In most cases, we tend to go for shortcuts (see initial point) or code hacks to get it done without large upfront development investments. You promise everyone those shortcuts will be managed later when that feature can pay its bills.

Oh and your developers probably need more hardware resources. Those bar metal servers don’t scale, so you need to go cloud with Amazon AWS or something similar. Creating new deployment challenges and migrations.

4. Third-party services

We live in an interconnected world and so is your product. All those partner API’s need to communicate with your system and vice-versa.

Somewhere down the line your partner will send you an e-mail saying: “We’re improving our system and we’ll deprecate these API’s or endpoints. We will stop supporting these from date X”.

You’ll have no other choice then put this in your backlog and plan on-time accordingly.

How to determine the amount of technical debt

There is no magic formula to put a number on technical debt. The reason why is simple: for every system the same implementation or change can be different in timeframe or required resources.

…There is a way to put a number on technical debt. Here is how:

Step 1: Create a dedicated (SCRUM) epic for debt.

In order to create visibility, you create an epic for technical debt. Put every story concerning debt in here. If it applies to a specific feature, you also just attach the specific debt stories to the feature epic. Attaching a story to multiple epics makes sure you can see total debt and debt on feature level at any time.

Note: In Jira you can’t apply multiple epics to a story in the default setup. You can use Components instead of that. It shouldn’t affect your burndown chart if you have assigned stories to the current release version.

Step 2: Spike first, then story.

Because technical debt is within your system and mostly on a deeper technical level, you’ll need to define/clarify the actual debt in order to create stories. Stories which aren’t 100% clear to your team, should never pass into a sprint.

So what do you do what do? The answer: create Spikes. They look like stories but without story points. Instead of that, they have a time-frame (ex. 5 hours to investigate X) allocated and their main purpose is to investigate to clarify what needs to be done. The result of a Spike is a story.

It’s important to get rid of all spikes as early as possible. You and your team need to clarify the full scale of debt and estimate them in the first upcoming planning session. All story estimated points combined will give you the total number of debt.

Step 3: Adjust your roadmap, take deadlines into account.

The next step is to plan debt for short-term execution and incorporate technical debt in the longer-term roadmap. Basically it will look like if you’re paying off your loan debt to the bank.

Don’t be fooled, you’ll always create debt. Monitoring your debt is not a one-time exercise, more like within the DNA of your operation.

Step 4: Communicate to stakeholders

The last step is communication. Now all technical debt incorporates within your operation, it’s time to communicate to your stakeholders. The most important group will be higher management, as they’re paying the bill for this debt. The most important thing is to explain is how this will affect the organization and more importantly, your customers. A second would be how this will impact the speed of product development.

You don’t have to bore them with the whole ‘what is technical debt’ story. Just explain key parts so they know what you’re referring to in future communications.

How do we manage this debt?

I hope this answered your questions about ‘what is technical debt’ as much as possible. You may also be able to determine the technical debt in your product by now. There is one thing left: how to manage technical debt.

Continue reading on ‘How to manage technical debt‘.