« Ce qui se mesure s'améliore » — mais aussi : dès qu'une mesure devient un objectif, elle cesse d'être une bonne mesure. Certaines métriques, en contexte agile, font plus de mal que de bien.

La vélocité comme objectif

Vu à la leçon sur la vélocité : demander « plus de points » pousse à gonfler les estimations. Le chiffre monte, la valeur livrée non.

Comparer les vélocités de plusieurs équipes

Chaque équipe a sa propre échelle. Comparer revient à comparer des températures en Celsius et en Fahrenheit sans conversion. Cela pousse les équipes à surestimer pour « bien paraître ».

Le taux d'occupation individuel

Viser « 100 % du temps de chacun occupé » supprime toute marge pour s'entraider, réfléchir, absorber un imprévu. Une équipe occupée à 100 % n'a aucune capacité d'adaptation — l'inverse de l'agilité.

Le nombre de lignes de code, de tickets fermés, de commits

Ces chiffres mesurent l'activité, pas la valeur. On peut fermer beaucoup de tickets sans résoudre le vrai problème de l'utilisateur.

Ce qu'on gagne à mesurer plutôt

• La valeur livrée : les fonctionnalités sont-elles utilisées, appréciées ?
• Le temps de cycle : combien de temps entre le début d'une story et sa livraison ?
• Les défauts qui échappent : combien de bugs découverts après la livraison ?
• La santé de l'équipe : mesurée simplement, en rétrospective.

Le principe

On mesure pour apprendre et s'améliorer, jamais pour évaluer ou mettre en concurrence. Dès qu'une métrique sert à noter, elle est manipulée.

Exemple concret : un rapport demande à l'équipe de fidélité son « nombre de tickets fermés par personne ». Le Scrum Master propose à la place un suivi du temps de cycle et du nombre de bugs post-livraison : des chiffres qui aident l'équipe à progresser sans la pousser à tricher.

À vous de jouer : citez une métrique qui nuit en contexte agile et une métrique utile à suivre à la place.