En Scrum, la vélocité mesure le nombre de points d’effort que l’équipe termine pendant un sprint, c’est-à-dire un cycle de travail court (généralement deux à quatre semaines). Sa raison d’être est simple: aider l’équipe à estimer combien de travail elle peut raisonnablement accepter lors du prochain sprint planning (la réunion de planification qui ouvre chaque cycle). Rien de plus.
Pourtant, dans beaucoup d’organisations, la vélocité est devenue autre chose. Elle apparaît dans les tableaux de bord de direction, se retrouve dans les objectifs annuels des équipes et sert de base à des comparaisons entre groupes de travail. Ce glissement, qui transforme un outil de planification interne en indicateur de performance managérial, est l’un des malentendus les plus répandus et les plus nocifs de l’agilité en pratique.
Des chiffres qui ne mesurent pas ce qu’on croit
Pour comprendre pourquoi la vélocité fait un mauvais indicateur de performance, il faut revenir à la nature des points d’effort (story points). Ces points sont des estimations relatives: l’équipe compare la difficulté d’une tâche par rapport à d’autres tâches, en utilisant généralement la suite de Fibonacci (1, 2, 3, 5, 8, 13…). L’unité n’a pas de valeur absolue. Un “5” dans une équipe n’a strictement aucun rapport avec un “5” dans une autre, de la même manière qu’attribuer une note de difficulté à une randonnée dépend du groupe qui l’évalue.
Cette nature relative rend toute comparaison inter-équipes absurde. Comparer la vélocité de deux équipes revient à comparer les résultats de deux examens dont les barèmes sont différents et inconnus. Le Guide Scrum lui-même ne mentionne d’ailleurs la vélocité que comme un outil de prévision, jamais comme une métrique d’évaluation.
La loi de Goodhart en action
Le problème ne s’arrête pas à l’interprétation erronée. Dès que la vélocité devient un objectif, un mécanisme bien documenté se déclenche. La loi de Goodhart, formulée par l’économiste britannique Charles Goodhart dans les années 1970, énonce qu’une mesure qui devient un objectif cesse d’être une bonne mesure. En d’autres termes: si vous demandez à une équipe d’augmenter sa vélocité, elle trouvera des moyens de le faire, mais pas nécessairement en travaillant mieux.
Le mécanisme le plus courant est l’inflation des estimations. Si la direction attend une vélocité de 40 points par sprint, l’équipe apprend rapidement à estimer à 8 ce qui valait 5 le mois précédent. Le chiffre monte, les rapports sont satisfaisants, mais la quantité réelle de travail accompli n’a pas changé. Pire, l’inflation rend les estimations inutilisables pour leur fonction première, qui est d’aider l’équipe à planifier son propre sprint.
Un autre effet pervers est le sacrifice de la qualité technique. Pour maximiser le nombre de points terminés, les équipes peuvent réduire les tests, accumuler de la dette technique (des raccourcis dans la réalisation qui devront être corrigés plus tard) ou découper le travail de manière artificielle pour gonfler le compteur. Le résultat à moyen terme est une baisse de la capacité réelle de l’équipe, exactement l’inverse de ce que le management cherchait à obtenir.
Ce que la vélocité stable révèle vraiment
Il existe un paradoxe que les équipes Scrum expérimentées connaissent bien: une équipe qui s’améliore réellement voit souvent sa vélocité rester stable, voire baisser temporairement. Le blog Savoir Agile, spécialisé dans le coaching agile francophone, décrit le cas d’une équipe dont la vélocité n’avait pas bougé en six mois, alors que ses résultats réels s’étaient considérablement améliorés: temps de cycle (le délai entre le début et la livraison d’un élément de travail) passé de sept semaines à trois, satisfaction client en hausse, nombre de corrections post-livraison en baisse.
Ce cas illustre un point fondamental: la vélocité mesure un volume d’effort estimé, pas la valeur produite ni la qualité du travail. Une équipe qui investit du temps dans l’amélioration de ses pratiques, la réduction de sa dette technique ou l’approfondissement de sa compréhension des besoins utilisateurs produit plus de valeur avec moins de points, ce qui fait baisser sa vélocité sur le papier.
Quoi regarder à la place?
Si la vélocité n’est pas un bon indicateur de performance, que faut-il observer? Les praticiens Scrum expérimentés recommandent généralement de se concentrer sur des métriques qui reflètent la valeur livrée plutôt que le volume estimé. Le temps de cycle, qui mesure la durée effective de réalisation d’un élément de travail, donne une indication concrète de la fluidité de l’équipe. La satisfaction des parties prenantes (stakeholders), évaluée à chaque revue de sprint, renseigne sur la pertinence de ce qui est livré. Le taux de livraison par rapport aux prévisions de sprint, observé sur plusieurs cycles, indique la fiabilité des engagements de l’équipe.
Ces indicateurs ont un point commun: ils ne peuvent pas être gonflés artificiellement sans que le détournement soit immédiatement visible. Une équipe qui réduit son temps de cycle livre réellement plus vite. Un taux de satisfaction en hausse reflète une valeur perçue réelle. La vélocité, elle, ne peut offrir cette garantie, précisément parce que l’unité qui la compose est définie par ceux qu’elle est censée mesurer.
La vélocité reste un outil utile à l’intérieur de l’équipe, pour calibrer la charge de travail d’un sprint à l’autre. Mais quand un directeur de programme affiche les vélocités de ses dix équipes sur un même graphique et demande aux trois dernières de “rattraper leur retard”, il ne pilote plus la performance: il incite chaque équipe à recalibrer ses estimations jusqu’à ce que les courbes convergent, sans qu’un seul livrable supplémentaire n’ait été produit.