INFOTEL VOUS REMERCIE POUR VOTRE CANDIDATURE

Un chargé de recrutement prendra contact avec vous prochainement.

LES RECETTES DU COACH AGILE #3

LES RECETTES DU COACH AGILE

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.

 

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 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. Par exemple, si la vélocité moyenne est de 30 points par Sprint et que l’équipe s’accorde sur le fait de résorber l’équivalent de 10 points de dette, alors, ils devront répartir les 20 points restants dans les histoires fonctionnelles.

La bonne 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 y a un bon et un mauvais, ici c’est pareil, il faut donc se surveiller. Vous pouvez profiter du BurnUp chart pour faire apparaître la différence entre les deux.

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 – Non estimée

Ce cas est plus délicat. Bien que la chute de vélocité soit 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. 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 –Estimée

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

Par Robin