Technical debt workshop
Understand what is technical debt? and how to deal with it
This workshop is a 2 hours workshop you can run in your team during a retrospective or ad-hoc to align on this concept.
This workshop is designed to be accessible to technical and non technical people as well
Here is the facilitation support :

Connection : 3 words

Ask to the participants :
  1. 1.
    In solo : Write down three words that you associate to the expression "Technical debt"
  2. 2.
    In pair :
    • Share your thoughts
    • Agree on a definition
  3. 3.
    All together :
    • Share your thoughts
    • Agree on a definition


What is Technical debt ?

“Some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off.” - Ward Cunningham
Technical 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.

Difference between Bad code & Technical debt

"Just because some code is bad doesn't mean it's technical debt. It's not technical debt unless we have to pay interest on it, and interest rate is a function of time" - Adam Tornhill in Software Design X-Rays


  • Accumulate bugs
  • Add a new functionality will cost a lot of money : reduced velocity

How do we create this debt ?

"We don’t have time!"

One thing we hear the most in teams is the lack of time as an explanation of technical debt creation :
  • “No time to rethink the design of this class, just keep adding new stuff to it!”
  • “I didn’t have time to write the unit tests”
  • No time to think about how someone else will fix or extend the code

Other causes

  • Poor Conception : No time for architecture and design.
  • Poor Business understanding : It is impossible to design something you do not understand...
  • Poor Scheduling / Underestimating : No testing effort in estimations.
  • Bad Development Practices : Development team needs to have a set of practices and conventions so that there is a little or no significant difference in design and implementation from feature to feature.
  • Outdated Technology : As technology evolves, software standards become higher every day : No technology watch, innovation time
  • No team rules / conventions
  • Only Michel knows this piece of code, no one else can update it (SPOF
The technical debt creation can be deliberate or inadvertent. That's what Martin Fowler explains with the Technical Debt Quadrant :

Some examples of technical debt

  • Source Code Formatting
  • Bad naming : Source code is not understandable by anyone.
  • Low/No Test Coverage : Tests ensure that each part of the code is behaving the intended way.
  • Code duplication
  • Lack of Modularity : Some code sometimes serves different business logic. The more codes developers write, the more lack of modularity can bottleneck.
  • Code Complexity : Complexity can be measured in several different ways, but it measures the dependence and path length to perform an operation. A long path leads to complex code.
  • No automation : Deployments and tests are done manually.

Concrete practice : Dice of debt

Dice of debt is a serious game that demonstrates the importance of managing technical debt. It has been documented on the agile alliance website here :

How to play ?



  • You are a scrum team that rocks.
  • Your mission : create the highest amount of new software value by the end of the project.
  • You have a strong dead line : 10 sprints of 2 weeks.
Technical debt can reduce that value dramatically.


  • Sprint = 1 turn
  • You have a finite capacity in each sprint represented by 12 dice
    • 8 dice to create new value (NV)
    • 4 dice for technical debt creation (TD)
You must run the technical debt dice at each turn.

Technical debt reduction measures

You can lower the burden of technical debt during the game by investing in some reducing tech debt measure :
  • Continuous integration (CI)
  • Test-driven development (TDD)
  • Code review
  • Increase test coverage
Each investment in a TD-reducing measure reduces your NV dice for a few turns.
Get the associated effect

Scoring sheet

Tracking sheet

How to play ?

At each turn (x 10) , each team must :
  • Choose a strategy (use the investment effort or no)
  • Roll the NV dice
  • Roll the TD dice
  • Update the score sheet
  • Update the tracking sheet
  • Small retrospective
    • What do we need to adapt ?


Debrief the game with the participants

You will always face some Technical Debt

  • Some amount is to be expected (Unintentional)
  • The amount of technical debt will never be zero
BUT it has to be manageable.
We must build quality in by using great development practices

How to manage it ?

Ask questions to the participants / small technical retrospective :
  • Which examples of technical debt do you identify i our code base ?
  • How do you materialize it in the backlog ?
  • How can we improve the management of the technical debt ?
  • How could we reduce it ?
    • A concrete action that we could implement tomorrow

Measure things

We can easily measure things that can help us quantify our technical debt :
  • Functionalities : Measure the performance of the system for each period of time (iterations) by measuring the number of functionalities (User stories) done / delivered.
  • Bugs : Number of "stuff" to fix in the code : bugs, fixes.
  • Technical debt : Number of refactoring or technical improvements identified by the team.
    • The definition of this measure can differ from one team to another and it’s fine. The only things is that this definition must be constant for the team.

Use static code analysis tool

Tools like Sonar can give an idea on the health of your code base (some trends to follow). It calculates technical debt indicator :

Make the debt visible

Create items in a backlog for everything that is identified and monitored by the team as a subject for refactoring or technical improvement.


Dedicate time to technical debt reduction and prevention.

Technical retrospective : Focus on the technical/architectural improvement

Objectives : Find technical improvement actions / prioritize technical items.
Questions during those sessions :
  • Where are the defects?
  • Where are the 'hard bits' ? What makes them hard ?
  • Where are the 'easy bits' ? What makes them easy ?
  • What keeps changing ? Why ?
  • Could we better quantify our technical debt ?
  • ...

Apply the boy scout rule

“Always leave the code you’re editing a little better than you found it.” - Uncle Bob

Use great development practices

There are a lot of them in XP
“I'm not a great programmer; I'm just a good programmer with great habits.” - Kent Beck
Some of those practices :
  • Follow Clean Code rules
  • Test Driven Development
  • Static code analysis
  • Pair/Mob programming
  • Knowledge sharing
  • Code review
  • Mentoring
  • Coding style guides
  • ...

To go further :