Document title goes here Author Name:

Date:

Technical debt sounds like a financial term, which is where this

programming theory has its roots. When it comes to software
development, technical debt is the idea that certain necessary work
gets delayed during the development of a software project in order to
hit a particular deliverable or deadline.

Developers inherently deal with this issue: the idea of developing a

perfectly designed app, software, system, etc. Clean, well-designed
code allows future iterations and innovations to be more easily
implemented. However, in a business setting, time and resources often
mean that developers don’t have the ability to produce clean, perfect
code before delivering a product.

This is where technical debt comes into play. The concept recognizes a
trade-off between perfect products and the short timelines often
required for product delivery. While it can be useful to incur some debt,
as with money matters, there’s a limit to how much debt you want to
carry.

In this article, we’ll take a look at how technical debt is affecting your IT
team’s workload, and ways to manage the debt.

Defining technical debt

First up, let’s talk about the ins and outs of the theory. The concept was
first discussed in the early 1990s by Ward Cunningham, one of the
founders of Agile programming. Cunningham continues to speak on
this topic. The concept is that the “debt” represents the extra
development work that arises when code is implemented in the short
run, despite it not being the best overall solution.

What is the exact definition of technical debt? The Software Engineering

Institute at Carnegie Mellon University notes that technical debt
“conceptualizes the trade off between the short-term benefit of rapid
delivery and long-term value.” Another perspective comes from
Document title goes here Author Name:

Date:

industry analyst, Gartner, which defines technical debt as the deviation

of an application from any nonfunctional requirements.
Here’s a general example: Imagine that you’re a software developer and
you have to add a new functionality to a software or system. There’s
two paths to choose:

 The easier route – made up of messier code or design, will get you
there faster.
 The harder route – made up of cleaner code and design that takes
a lot more time.

Like monetary debt, technical debt can accumulate “interest”. In this

concept, the interest is the increasing difficulty it can be to implement
changes later on, especially as a software project dominoes through
multiple phases. The longer technical debt is ignored or unaddressed,
software entropy can occur.

(It is like cleaning by hiding everything under the couch – it’s tidy for
now, but nothing is in its correct spot. You’ll eventually have to spend
time properly cleaning and organizing it down the road in order to find
something you’re seeking.)

Regardless of how you choose to define it, recognizing the importance

of the core concept provides the best starting point for reducing risk.
This means honing the ability to acknowledge the fact that issues
related to the source code have a negative impact on productivity and
devising a plan to address same.

Technicalities of technical debt

Technical debt does not include ignoring or delaying things like
functionalities, which were intentionally not built.

Instead, the debt is incurred when IT chooses to delay better coding

and building internal pieces that should be there, for various reasons.
But this choice to ignore certain pieces is understood that it will impede
Document title goes here Author Name:

Date:

future development and delivery if left undone – and if the team

doesn’t go back to resolve the mediocre code or address known bugs,
the result is the cumulative interest.

While technical debt can refer to any part of software development, it is

commonly associated with extreme programming, particularly
refactoring. Refactoring is the restructuring of existing code as part of
the development process. The two main reasons for refactoring are
poorly written legacy code and evolving solutions as a problem is better
understood.

Identifying Technical Debt

Below are some warning signs that a project has created technical debt:

 Code smells are much more subtle than logic errors and indicate
problems that are more likely to impact overall performance quality
than cause a crash.
 Higher levels of complexity — when technologies overlap each
other.
 Product bugs that will cause an entire system crash.
 Issues with coding style. Developing a coding style guide and
sticking to it, will help to overcome this issue.

The key thing to note at this stage is that, if left unaddressed, these red
flags can result in higher total cost of ownership, longer time to market
and reduced agility. They can also negatively impact customer
experience and security.

Types of Technical Debt

Now that we know what technical debt looks and smells like, it’s time to
categorize its occurrence.
Document title goes here Author Name:

Date:

Planned Technical Debt – This type of technical debt occurs when the
organization makes an informed decision to generate some technical
debt with the full understanding of the consequences (risks and costs).
In the case of planned technical debt, it is critical to be as precise as
possible in terms of defining the compromises the organization intends
to make. An example could be: “In order to meet the new release
deadline of November, we have decided to forego writing unit tests in
the final three weeks of the project. We will write these tests after the
release.”
Because these decisions can accumulate quickly over time, it is
imperative to maintain a record of them. Doing so will increase the
likelihood that technical debt will get addressed and paid down quicker.
Otherwise, it will quickly be forgotten, potentially costing the
organization big time in the long run.

Unintentional Technical Debt – This refers to unplanned technical

debt that arises due to poor practices. For example, a design approach
that ends up containing many errors. This type of technical debt
sometimes occurs as the direct result of poor communication within
the organization or when the goals of Development and Operations are
misaligned.
Unavoidable Technical Debt – This occurs due to changes in the
business and the progress of technology over time that present better
solutions. It typically arises when scope changes are requested mid-
project, that result in an immediate cost such as adding a new feature
to an existing design to better support mobile delivery. In short,
technical debt is created when new business requirements make old
code obsolete.

Good vs. bad: reasons for technical debt

Just like financial debt, there can be good reasons for technical debt –
but it’s important to know that going in, so debt doesn’t get ahead of
the team, slowing down progress and future deliveries.
Document title goes here Author Name:

Date:

A good reason for incurring technical debt is often because a delivery is

more important than the internal cleanliness of code or smoothness of
functionality. If the product works for the user, despite not being the
best or cleanest product, then delivery may behoove your company (in
terms of time-to-market, revenue, etc.). If, however, business needs
require perfect design, you’ll take your time to deliver a cleaner
product.

A bad reason for incurring technical debt is because the team chose to
focus on other areas that are more innovative or interesting but less
important.

Even if you have a good reason for incurring debt, choosing the messier
option that ensures a quicker delivery isn’t the end of this design
choice. Instead, the team must return – at some point – to this piece of
design to add more functionality or revise it. The longer the team waits
to deal with an issue, the more likely it can cause more issues or get
buried in code. This is the interest: the time in the future you’ll have to
spend cleaning it up to get it to jive with new changes you have to
make.

Dev teams must be balanced. Looking at many sides of the issue to

determine whether or how much technical debt to incur.

Avoiding racking up technical debt

While financial debt is easy to track, technical debt is not inherently a
metric. With some tweaking, the theory of technical debt can be
translated to certain metrics, such as time-to-market versus time
working overtime to pay down interest. It can also appear as less
productivity from a team – which is also difficult to measure.

Experts recommend tracking your technical debt to keep it from getting

too unwieldy. As the debts can survive multiple development cycles,
tracking it is essential. Here’s how:
Document title goes here Author Name:

Date:

 Start a list of technical debts. (This includes all instances where

the developers know the code isn’t as clean as it should or needs to
be for future development.)
 List and group deferred tasks into workable units.
 Note the consequences of ignoring each unit.
 Keep the list visible.
 Inform teams that rely on delivery releases – like marketing, sales,
etc. – that you’re working on technical debt, so that each new
release cannot include only new features.
 Schedule regular and frequent time to pay off technical debt.

Taking Nonfunctional Requirements (NFR) Into

Account
Using the Gartner definition of technical debt necessitates a deep dive
into nonfunctional requirements or NFRs. Every system has NFRs
though they may not always be defined or tracked. NFRs refer to
constraints on a software system and include the following seven
attributes: compatibility, security, reliability, usability, efficiency,
maintainability and portability.

In contrast, functional requirements outline what the system should do

and are much easier to measure and analyze for example in the case of
epics. Achieving both functional and nonfunctional requirements are
critical to ensuring project success.

Shifting focus back to NFRs, there are also important sub-characteristics

that exist, namely explicit and implicit requirements. As you may have
guessed, explicit requirements are predefined by key stakeholders, for
example, a detailed design specification. On the other hand, implicit
requirements are those that are expected but which have not been
stated unequivocally. An example of an implicit requirement would be
ensuring the ease of use of an application.

Having an understanding of these nonfunctional requirements will be

important when it comes to identifying technical debt.
Document title goes here Author Name:

Date:

Managing Technical Debt: Best Practices

Assessment

In identifying technical debt you might have come across some key
signals. For example, your product’s performance ratings could be on
the decline or your developers may be taking much longer to iterate.
But how do you measure this? What is the true cost of technical debt?

One way to come up with this measure is to look at the number of days
developers would need to spend reducing technical debt by performing
activities such as refactoring or replacing the application. Once you
attached a dollar amount to these functions, you could then compare
this data to other milestones, like number of remaining days before the
release date. This will provide an excellent cost/benefit analysis and aid
in communicating more effectively with the rest of the organization.

In addition to providing a current status update, it is also important to

generate estimates of how you expect technical debt to change over
time.

Communication

One of the most important steps to take in managing technical debt is

to acknowledge that it exists in the first place and share that discovery
with key stakeholders. It should be the responsibility of IT management
to set the tone and communicate to non-IT managers about the true
cost of technical debt. The head of IT must also explain the importance
of paying down technical debt sooner rather later.

Implementation

There are three options to consider in terms of managing technical

debt.

 Waive the requirement altogether. In other words, the

organization decides to live with the system as it is and no longer
deems the requirement as necessary. If you cannot waive the
Document title goes here Author Name:

Date:

requirement, then you will need to refactor or replace the

application.
 Refactor the application. This option is aimed at reducing
complexity, removing duplicates and improving the structure of the
code. Refactoring is the only way to improve a code’s internal
structure without changing the behavior of the program.
 Replace the application. While this will introduce new technical
debt, the idea is to address it quickly and minimize it as much
possible.

Implementing Agile practices to minimize technical

debt
Users of the popular Agile approach to programming know that “done”
is a relative term. In traditional development environments, software is
done when it’s shipped to the users. But in Agile environments,
iterations of work are frequently delivered to the user, improving bugs
and issues that develop in each release. There is no “done”.

Agile relies on reducing the scope of a release to ensure quality work,

instead of promoting a large number of functions in a release.

Because Agile embraces increments and iterations, instead of finished

projects, implementing Agile theories can be a good way to stay on top
of technical debt. Always thinking in short bursts of work makes it
easier for IT teams to tackle smaller groups of technical debt: in an
ongoing fashion. This way, debt isn’t forgotten for bigger and better
projects and phases, thus avoiding long-term interest.

To alleviate technical debt, using Agile methodologies like test

automation and Continuous integration (CI) can ensure that your IT
team is always working on technical debt without. Weekly sprints will
also allow Agile teams to clean up data and outdated assumptions. By
implementing these theories in the long run, many believe that
technical debt can be avoided entirely.
Document title goes here Author Name:

Date:

The Way Forward: Reducing Technical Debt in New

Initiatives
The best way to reduce technical debt in new projects is to include
technical debt in the conversation early on. You will be able to account
for the impact of short term decisions on long-term ROI and create a
plan for paying off debt at the beginning of a project. Remember, just
like financial debt, technical debt gets more expensive the longer you
hold it. The idea is to minimize technical debt so your team can reduce
risk, improve agility and deliver best-in class results in today’s
competitive digital economy.

What are Technical Debt?

Technical debt is usually the result of a decision made by development teams to
take the easy path or skip development best practices, in order to meet a delivery
schedule. This leaves behind issues in the codebase that need to be resolved at
some point. In other cases, software needs to be updated or maintained, and these
changes are delayed to allow for the delivery of new features. This leftover work is
a debt that must be paid off at some point in the future.

All software development projects, including Agile projects, accumulate technical

debt, and a major challenge of development teams and R&D leadership is to keep
technical debt at a level that does not affect the team’s performance on the one
hand, and the organization’s long-term goals on the other hand.

How Technical Debt Challenges

in Development Organizations.

No Time to
“Do Things Right”
Developers prefer releasing well designed, well crafted software solutions. Clean
code allows for easy maintenance, extension and modification. In reality, this is
often not possible, due to tight schedules, limited resources and a push to meet
Document title goes here Author Name:

Date:

business objectives. Developers may intentionally generate technical debt to keep

to a delivery schedule, or unintentionally create debt during a rush to a release.

Poor Software
Quality
Technical debt is one of the major causes of poor software quality. With the
growing complexity of software systems, it’s impossible to test everything.
Whether you focus on comprehensive unit test coverage, integration tests between
major components, or UI test automation, you are bound to miss some components
or integrations which are critical for functionality, stability or performance.

Long-Term Software
Viability
Technical debt negatively impacts the long-term viability of software solutions,
resulting in application outages, security vulnerabilities, and increased maintenance
costs. Eventually, technical debt will make it very expensive to upgrade or
continue supporting the solution. Software products can become a legacy monolith
which developers are afraid to touch or modify because any change can have
unexpected results.

Ideally, developers and their managers want to allocate development resources

towards new functionality that benefits users and enhances revenue. But in reality,
developers spend a lot of time on maintenance and bug fixing. Optimizing this
activity is key to making development organizations more effective.

Test Impact Analysis.

Too many redundant tests are created and kept, taking up engineering resources.
SeaLights reduces test creation by isolated areas where code was recently modified
or executed in production but did not undergo regression testing. Team members
and managers can use smart data to identify gaps and to develop new tests in
sprints to come.

Untested code in production results in failures, poor user experience, and time
wasted on carrying out hotfixes. SeaLights analyzes modifications to your code
Document title goes here Author Name:

Date:

and lets you know whenever an untested code change has gone through production
unnoticed. Prevent risky code prior to shipment and address critical issues before
they affect your users.

Manual Test Coverage.

Manual testing is concurrent learning, test design, and test implementation of
critical components of the application. It provides quick feedback and reveals
critical bugs in newly released features. These tests are manual, so they have a
longer test execution time, and there are more costs involved. Thus, it is essential
to minimize overlap with different kinds of tests. Achieve visibility into which
areas of code are being tested with exploratory and manual tests, in order to
enhance team success and productivity.

Functional Test Coverage.

Applications are developed with several builds each made up of distinctive code
changes. This climate of incremental code changes, particularly functional, API
and regression testing CI/CD pipelines, demand straight forward functional test
code coverage to facilitate visibility and efficient feedback loops.

Learn more

Learn more

Learn more

Test Coverage Analysis.

SeaLights integrates with all your testing tools, monitors test execution and
calculates a holistic test coverage score across all test types. Holistic test coverage
reveals your technical debt. If 60% of your software is tested, the other 40% is
untested and probably contains unknown problems – the missing tests and
unknown problems represent your technical debt.
Document title goes here Author Name:

Date:

Recently Changed Code Analysis.

Recently changed code is much riskier than code that has been in your system for
ages and is frequently executed by users. SeaLights can monitor and analyze
untested code changes in a specific build, across a period of time, or comparing
two or more builds. Untested code changes are a high-risk portion of your
technical debt which should receive high priority.

Frequently Used Code Areas.

The SeaLights production listener monitors real user data coming from production,
and tells you which methods in your codebase are actually in use. To prioritize and
determine the importance of different code areas, Sealights applies business
criticality weights to different code areas. It visualizes untested, frequently used
code areas and these represent high-risk technical debt.

What is Technical Debt?

Technical debt (also known as tech debt or code debt) describes what results when
development teams take actions to expedite the delivery of a piece of functionality
or a project which later needs to be refactored. In other words, it’s the result of
prioritizing speedy delivery over perfect code.

If you’ve been in the software industry for any period of time, chances are you’ve
heard the term “technical debt”. Also known as design debt or code debt, the
phrase (or more accurately, the metaphor) is widely used in the technology space.
It is referred to as a catchall that covers everything from bugs to legacy code, to
missing documentation. But what exactly is technical debt anyway? And why do
we call it that?

Technical debt is a phrase originally coined by software developer, Ward

Cunningham, who in addition to being one of 17 authors of the Agile Manifesto, is
also credited with inventing the wiki. He first used the metaphor to explain to non-
Document title goes here Author Name:

Date:

technical stakeholders at WyCash why resources needed to be budgeted for

refactoring.

He didn’t realize at the time, but he had coined a new buzzword in the software
community. Later, it would become the subject of countless academic studies,
debates, and panel discussions.

Years later, Cunningham described how he initially came up with the technical

debt metaphor:

“With borrowed money, you can do something sooner than you might otherwise,
but then until you pay back that money you’ll be paying interest. I thought
borrowing money was a good idea, I thought that rushing software out the door to
get some experience with it was a good idea, but that of course, you would
eventually go back and as you learned things about that software you would repay
that loan by refactoring the program to reflect your experience as you acquired it.”

Is There a Simplified Definition of Technical

Debt?
Since metaphors are inherently abstract, the true definition of technical debt is up
to interpretation. Various people have developed their own personal definitions for
it over the years. Over time, several highly-nuanced explanations have evolved but
at a high level. We can see several themes that can help us build a concrete
definition for technical debt.

It is a Tool

Much like someone may take out a loan on a property as a means of getting into a
booming real estate market before being priced out, technical debt is often used as
a tool for “getting ahead.” Trey Huffine, founder of gitconnected explains the role
Document title goes here Author Name:

Date:

of technical debt through the lens of a startup. His definition is straightforward,

“technical debt is any code added now that will take more work to fix at a later
time—typically with the purpose of achieving rapid gains.”

It Has Consequences

Shaun McCormick’s definition of technical debt focuses more on the consequences

in the long term, “I view technical debt as any code that decreases agility as the
project matures. Note how I didn’t say bad code (as that is often subjective) or
broken code.” He suggests that true technical debt is always intentional and not
accidental.

Gaminer’s explanation of what they call the fallacy of technical debt focuses

heavily on the concept of paying interest later. “Technical debt happens when you
take shortcuts in writing your code, so that you achieve your goal faster, but at the
cost of uglier, harder to maintain code. It’s called technical debt because it’s like
taking out a loan. You can accomplish more today than you normally could, but
you end up paying a higher cost later,” they write in a Hackernoon article.

It is NOT a Mess

Sometimes when trying to define a somewhat abstract concept it can be useful to

understand what it is NOT.

In an impassioned post, long-time software development consultant, Uncle Bob

writes “A mess is not a technical debt. A mess is just a mess. Technical debt
decisions are made based on real project constraints. They are risky, but they can
be beneficial. The decision to make a mess is never rational. It’s always based on
laziness and unprofessionalism, and has no chance of paying off in the future. A
mess is always a loss.”
Document title goes here Author Name:

Date:

By his definition, taking on technical debt is always intentional and strategic. His
explanation supports McCormick’s claim that bad code does not qualify as
technical debt. Later, when we address the various ways to classify technical debt,
you’ll see that not every instance of technical debt falls into this category.

An Academic Definition for Technical Debt

With the wide array of opinionated definitions for technical debt, several academic
works have attempted to present an unbiased, concrete definition for this abstract
concept. For example, an article in the Information and Software Technology
Journal defines technical debt in very specific terms:

“Technical debt describes the consequences of software development actions that

intentionally or unintentionally prioritize client value and/or project constraints
such as delivery deadlines, over more technical implementation and design
considerations…”

The same article expands on the metaphor for technical debt, “Conceptually,
technical debt is an analog of financial debt, with associated concepts such as
levels of debt, debt accrual over time and its likely consequences, and the pressure
to pay back the debt at some point in time.”

Are There Different Types of Technical Debt?

For as many definitions of technical debt that there are out there, there are just as
many types of technical debt. For years, software development practitioners have
sought new ways to classify and communicate technical debt.

In 2007, Steve McConnell suggested that there are 2 types of technical

debt: intentional and unintentional. According to him, intentional technical debt is
Document title goes here Author Name:

Date:

technical debt that one takes on consciously as a strategic tool. As opposed to

unintentional debt, which he calls “the non-strategic result of doing a poor job.”

A few years later, Martin Fowler took McConnell’s concept a step further and
published what he calls the “Technical Debt Quadrant.” This quadrant attempts to
categorize technical debt into 4 categories based on both intent and context. Fowler
says technical debt can be classified based first on intent: is it deliberate or
inadvertent? And then even further distinguished by whether it is prudent or
reckless debt.

In 2014, a group of academics noted the existing frameworks for categorizing

technical debt didn’t directly address the specific nature of the debt. They
dismissed the categories proposed by McConnell and Fowler and proposed
classifying technical debt by its nature rather than whether it was strategic or not.
Document title goes here Author Name:

Date:

According to the resulting paper, which was published by the Software

Engineering Institute as “Towards an Ontology of Terms on Technical Debt,” there
are 13 distinct types of technical debt and a set of key indicators for each.

 Architecture Debt

 Build Debt

 Code Debt

 Defect Debt

 Design Debt

 Documentation Debt

 Infrastructure Debt

 People Debt

 Process Debt

 Requirement Debt

 Service Debt

 Test Automation Debt

 Test Debt

Is Tech Debt Bad?

If you want a simple answer: technical debt is neither good nor bad, it’s debt. And
just like financial debt, there are several schools of thought around whether
technical debt is a good or bad thing. So rather than searching for an objective
answer, we will address a few of the different perspectives here.

Most software companies today are under pressure from the market and
competitive forces to develop and ship fast. Startups especially feel this “ship or
Document title goes here Author Name:

Date:

sink” pressure. This need for speed leads many product and software development
teams to make the trade-off between taking on technical debt or launching later.

This is why the general consensus from most agile teams is that technical debt is
not inherently bad. In fact, most, if not all software products have some degree of
technical debt. When you consider how much code teams ship every day
(especially in agile environments where working software is the primary measure
of progress) this is not a surprising claim.

On the other hand, many software development teams working strictly within the
Waterfall software development methodology and other documentation-driven
frameworks do not share this perspective.

As Steve McConnell points out, attitudes toward technical debt vary greatly based

on not only company philosophy but also across departments and roles.

“I’ve found that business staff generally seems to have a higher tolerance for
technical debt than technical staff does. Business executives tend to want to
understand the tradeoffs involved, whereas some technical staff seems to believe
that the only correct amount of technical debt is zero.” McConnell writes,
explaining that he attributes this aversion to technical debt to the communication
challenges it will inevitably create down the line.

Technical staff, he says, often are tasked with trying to explain technical debt to
business staff, who may not immediately see the implications. “The main issue
seems to be that, unlike financial debt, technical debt is much less visible, and so
people have an easier time ignoring it,” he suggests.
Document title goes here Author Name:

Date:

So the takeaway here is, context matters when determining whether technical debt
is good or bad. In general, you can think of technical debt in the same way you do
financial debt: it’s not problematic until it is.

See also: Refactoring, Technical Product Manager, Product Development Process

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?
Document title goes here Author Name:

Date:

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:
Document title goes here Author Name:

Date:

source: opensourcesurvey.org

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.
Document title goes here Author Name:

Date:

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:
Document title goes here Author Name:

Date:

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
Document title goes here Author Name:

Date:

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‘.