A recruitment consultant will contact you soon.

Agile coach: recipes for success #3

Infotel_Agile coaching_Visualising technical debt

How to visualise technical debt and why

This is a question that comes up very often within teams: should we estimate and add up the technical debt in terms of velocity? The answer is not so straightforward and, as scrum master, all eyes may well be focused on you to provide some words of wisdom.

What is the technical debt?

The technical debt is made up of all those things we did not want to do, or could not do.

What is technical debt

For example, the Product Owner has conceded that stories are considered ‘done’ even though not all acceptance criteria have been validated. This is an anomaly. It can also happen that all the criteria in the ‘done’ list are left unchecked, or that the code is generating a minor bug.

An anomaly is created when a feature does not correspond to the Product Owner’s definition, creating an invalid acceptance criterion.

A bug is a problem created by changes to a code, often having an effect outside its usual sphere of influence – leaving the code itself perfectly compliant with the appropriate functionality and acceptance criteria.

All of these things will have to be done one day. The team is gaining time now in order to pay for it later. You create the technical debt.

Counting the technical debt in terms of velocity 

Some teams estimate this debt and take it into consideration. For example, if the average velocity is 30 points per sprint and the team agrees to reabsorb the equivalent of 10 debt points, they will then have to distribute the remaining 20 points throughout the functional stories.

Technical debt in terms of velocity







Good and bad velocity

If the velocity remains constant, the functional value added to the product decreases. It is therefore important to maintain a way of differentiating between the two. Like cholesterol, there is a good type and a bad type. The same applies in this context, so you must watch yourself carefully. You can take advantage of the BurnUp chart to reveal the difference between the two.

Good and bad velocity







Although the velocity remains constant, the technical debt is visible and provides information.

Do not express technical debt in terms of velocity

However, in contrast, you can decide not to quantify the technical debt. Paradoxically, this immediately reveals the scope of its impact.

1 –Not estimated

Not estimated technical debt velocity

This case is more delicate. Although the reduction in velocity is visible and still allows room to add a note to the BurnUp, Product Owners will not be able to forecast the impact of the reimbursement and will be reluctant to set any priorities in a climate of such uncertainty. This will cause a dramatic drop in team velocity (blue dots). Almost nothing (of value to the user) was produced during this period – the flat red line – but we cannot show the reason.


2 –Estimated

Estimated technical debt velocity

It is important to show why the velocity has dropped. If you have estimated the debt without counting it, you can use the type of BurnUp described in the previous paragraph, but this time using the velocity line. This is the recommended approach.



Automatic process of loan request and the simplification of KYC "Know Your Customer".


  • Improvement of KYC and the onboarding of new clients with automatic identity verification thanks to intelligent ID document processing on the web or in an application.
  • Acceleration in the dealing with requests for loans and mortgages: process and automatic classification of new documents, extraction of information and validation of data points.
  • Fraud prevention and respect of rules: automation of compliance requirements on contracts, financial documents and ID documentation.
  • Easing and simplification of the consumer spending comprehension: classification of bank transfers from the study of receipt and invoice item data.


Automated process of scientific papers and other documentation linked to the registering of a patent for intellectual property.


  • Recognition and automatic indexation of fields for a precise search among the documents relating to the patent application.
  • Standardisation of the documents with online specifications: bibliopraphy, expired patent, renewed patent, etc.


Automatic processing of receipts, bills and other financial documents.


  • Automisation of the accounting process: declaration of VAT, supplier bills, etc.
  • Standardisation and harmonisation of the business accounting processes.
  • Improving data security with the deletion of manual errors and with the synthesising of controls.
  • Contribution to the reduction in fraud risks, à la réduction des risques de fraude, reinforcement of operational security, audit trails and internal controls.
  • Support in the change management and accounting teams on the appropriation of this new solution.