Comment et pourquoi visualiser la dette technique

C’est une question qui revient très souvent dans les équipes : doit-on estimer et compter la dette technique dans la vélocité ? La réponse n’est pas si simple et en tant que Scrum Master, tous les yeux risquent de se tourner vers vous pour une parole sage.

La dette technique ?

La dette technique représente toutes ces choses que nous n’avons pas voulu –ou pas pu– faire.

Développeur lutant contre la dette technique

Par exemple, le Product Owner a accepté que des histoires soient considérées comme Done malgré que les critères d’acceptation ne soient pas tous validés (anomalie), ou que tous les critères de la définition du done ne soient pas cochés, ou bien encore que le code génère un bug mineur.

• Une anomalie est créée lorsqu’une fonctionnalité ne correspond pas à ce qui avait été défini par le Product Owner, comme un critère d’acceptation non valide
  • Un bug, c’est un problème qui est créé par une modification du code, souvent en dehors de son périmètre –par influence– alors que le code en lui même, réponds parfaitement à la fonctionnalité et aux critères d’acceptation

Toutes ces choses devront être faites, un jour. L’équipe **gagne **donc du temps aujourd’hui, pour le payer plus tard. Vous créez de la dette technique.

Compter la dette technique dans la vélocité

Certaines équipes estiment et tiennent compte de cette dette dans leur vélocité. Par exemple, si la vélocité moyenne est de 30 points par Sprint, et que l’équipe s’accorde sur le fait résorber l’équivalent de 10 points de dette, alors, ils devront répartir les 20 points restants dans les histoires fonctionnelles.

La vélocité de l’équipe devrait donc rester dans leur moyenne

La bonne vélocité et la mauvaise vélocité

Si la vélocité reste constante, la valeur fonctionnelle ajoutée au produit, diminue. Il est donc important de garder un moyen de différencier les deux. Comme le cholestérol, il parait qu’il y a un bon et un mauvais; là, c’est pareil, il faut donc se surveiller. Vous pouvez profiter du BurnUp chart pour faire apparaître la différence entre les deux.

Visualiser la dette contenue dans la vélocité / Répartition de la dette dans la vélocité

Ici, bien que la vélocité reste constante, la dette technique est visible et apporte de l’information.

Ne pas compter la dette technique dans la vélocité

À l’opposé, il est possible de ne pas comptabiliser la dette technique. L’avantage certain est la mise en lumière rapide et immédiate de son impact (paradoxalement).

1/ La dette n’est pas estimée

Ce cas est plus délicat. Bien que la chute de vélocité sera visible et qu’il est toujours possible d’ajouter une note au BurnUp, le Product Owner ne pourra pas se projeter sur l’impact du remboursement et aura donc des réticences à prioriser dans le flou.

Chute de vélocité, incompréhensible

Nous voyons ici une chute spectaculaire de la vélocité de l’équipe (pointillés bleus). Presque rien_ (de valeur pour l’utilisateur)_ n’a été produit pendant une période –la ligne rouge, plate– mais on ne visualise pas la raison.

2/ La dette est quand même estimée

Il est important de montrer pourquoi la vélocité a chuté. Si vous avez estimé la dette sans la compter dans la vélocité, vous pouvez utiliser le type de BurnUp du précédent paragraphe, mais avec cette fois-ci la ligne de la vélocité. C’est la méthode que je recommande.

Il est simple de faire le rapport avec la dette

Estimez et affichez

Le Product Owner doit être capable d’avoir une vision du volume de la dette en cours, pour :

1. **accepter ou refuser **une nouvelle dette en toute connaissance 2. mesurer la qualité du produit actuel 3. savoir quelle quantité de dette il doit prévoir dans le prochain Sprint 4. prévoir le temps nécessaire pour rembourser le tout 5. comprendre l’équipe

Exemple de visualisation

Une plaque Lego© collée au mur. La couleur et la taille des éléments peut être en relation avec le type d’élément (un gros bug rouge, une petite fin d’histoire, une moyenne tâche technique …).

La dette s’accumule

La taille de la plaque support peut être la limite que l’on se fixe pour accepter la dette. On retire les éléments qui sont remboursés.

Tips : une tâche technique ou un bug peut recouvrir un autre élément, pour exprimer une dépendance

Jenga© (lien) est un jeu de construction. Ici, une brique serait ajoutée à chaque élément de dette, quelque soit sa taille. L’avantage est que la structure devient vite instable de part sa hauteur.

La brique de trop … ?

Métaphore imparable de l’état du produit, la tour va se mettre à vaciller et peut même s’effondrer en plein Sprint quand un membre de l’équipe ajoute une brique. On empile la dette qui au début est assez stable et maîtrisée, sans mesurer l’ampleur des conséquences. On peut bien sûr retirer les éléments remboursés (en retirant les briques par le haut !).

Le p’tit bonhomme qui stress© : Un moyen assez simple de visualiser la dette est d’empiler des bouts de post-it (la couleur correspond si possible au type de l’élément) sur un emplacement dédié et défini en taille, que vous aurez imprimé en A3. On décolle les éléments une fois qu’ils sont remboursés.

On peut y ajouter un peu de gribouillage …

Priorisation de la dette dans le backlog

Qu’on estime ou pas en points d’histoire, il n’en reste pas moins que chaque tâche de la dette doit avoir sa valeur business pour être priorisée.

Conclusion

Il existe vraiment plein de possibilités pour visualiser la dette en toute transparence. N’hésitez pas à partager vos idées.