INFOTEL THANKS YOU FOR YOUR APPLICATION

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.