Le flux de valeur

Estimation et vélocité

Toute équipe s'entend demander quand le travail sera prêt, et la réponse donnée en heures se révèle presque toujours fausse. Les patterns de Scrum proposent d'estimer en points relatifs, puis de prévoir à partir de ce que l'équipe a réellement terminé lors des derniers Sprints : c'est la « météo d'hier ». Cet article explique ces pratiques, les calculs qui les accompagnent et la raison pour laquelle la vélocité ne doit pas devenir un objectif.

Comparer plutôt que chiffrer en heures

Cette façon de faire porte un nom dans A Scrum Book (2019) de Jeff Sutherland, James Coplien et leurs coauteurs : le pattern Estimation Points (points d'estimation). Un pattern décrit un problème récurrent, les forces en présence et une solution éprouvée par des praticiens.

Le problème est le suivant. L'équipe a besoin d'estimations fiables pour ne prendre ni trop ni trop peu de travail dans un Sprint (la période de travail de durée fixe, d'un mois au plus) et pour annoncer des dates plausibles. L'estimation en heures se heurte à plusieurs obstacles. Elle demande un long exercice, que l'on rechigne à refaire quand la situation change. Elle suppose de savoir combien d'heures par semaine sont réellement consacrées au travail prévu, alors que les réunions, les courriels et les interruptions en occupent une part que personne ne mesure. Elle invite enfin les parties prenantes (clients, direction, utilisateurs) à refaire le calcul sur la base de semaines pleines, puis à contester l'écart. Les auteurs ajoutent que les gens estiment mal en unités absolues, mais comparent bien.

La solution consiste à estimer avec des nombres sans unité, de façon relative, en partant d'un élément simple que tout le monde comprend et qui sert de référence. L'estimation couvre tout le travail nécessaire pour que l'élément soit vraiment terminé. Les auteurs soulignent un bénéfice indirect : estimer oblige l'équipe à réfléchir tôt au problème.

La technique la plus répandue est le planning poker, imaginé par James Grenning en 2002 et popularisé par Mike Cohn dans Agile Estimating and Planning (2005). Chaque développeur choisit en secret une carte, tous la retournent en même temps, ceux qui ont donné les valeurs extrêmes s'expliquent, et l'on recommence jusqu'à l'accord. Les cartes suivent à peu près la suite de Fibonacci (1, 2, 3, 5, 8, 13), et l'écart croissant entre les valeurs rappelle que l'incertitude augmente avec la taille.

Ceux qui font le travail estiment

Le pattern Pigs Estimate (ce sont les cochons qui estiment) répond à une question simple : qui donne le chiffre ? Deux situations faussent souvent les estimations. Un responsable bien intentionné estime à la place de l'équipe, et son chiffre devient difficile à contester. Un expert estime un travail que d'autres, moins expérimentés, réaliseront. Dans les deux cas, l'équipe ne se sent pas responsable d'un chiffre qu'elle n'a pas produit.

La solution est que les personnes qui feront le travail l'estiment, toutes ensemble, pour que chaque métier de l'équipe pèse dans le consensus. Le Product Owner, responsable de la valeur du produit, estime la valeur ; les développeurs estiment l'effort. Personne d'autre ne peut imposer ni contester une estimation a priori, et celle-ci reste une prévision que l'équipe révise quand elle apprend du nouveau.

Le nom vient d'une histoire que Ken Schwaber et Mike Beedle racontent dans Agile Software Development with Scrum (2001). Une poule propose à un cochon d'ouvrir un restaurant qui servirait des œufs au jambon. Le cochon refuse, parce que la poule ne serait que concernée alors que lui serait engagé. Le Guide Scrum a abandonné ce vocabulaire dès 2011. Son édition 2020 formule la même règle sobrement : les développeurs qui feront le travail sont responsables de son dimensionnement.

Ce que mesure la vélocité

La note Notes on Velocity (notes sur la vélocité) n'est pas un pattern mais une mise au point. La vélocité d'une équipe est la somme des estimations des éléments qu'elle a terminés pendant un Sprint. Les auteurs en tirent plusieurs conséquences.

• La vélocité ne mesure pas l'effort. Dans une équipe stable dont les Sprints ont une durée fixe, l'effort est constant ; c'est la quantité de travail terminé qui varie.
• Elle appartient aux développeurs et caractérise l'équipe entière, jamais une personne.
• Elle sert de prévision, à la manière d'un bulletin météo, et ne constitue ni une cible ni une garantie.
• Elle a une moyenne et une dispersion. Une équipe qui remplit son Sprint d'après sa vélocité moyenne doit s'attendre à ne tout finir qu'une fois sur deux. Son engagement porte sur le Sprint Goal, l'objectif du Sprint, et non sur la liste complète.
• Réduire la dispersion compte plus qu'augmenter la moyenne, car une vélocité régulière permet de prévoir. Augmenter la vélocité ne garantit d'ailleurs pas que l'équipe produise plus de valeur.

Prévoir le prochain Sprint

Yesterday's Weather : la météo d'hier

Le pattern Yesterday's Weather (la météo d'hier) part d'un travers humain. Par fierté, ou sous la pression d'objectifs « ambitieux » fixés de l'extérieur, les équipes prennent plus de travail qu'elles ne peuvent en finir. Elles bâclent alors pour tenir, ou elles déçoivent. La solution tient en une phrase : dans la plupart des cas, le nombre de points terminés au dernier Sprint prédit bien celui du Sprint suivant. Les auteurs rattachent cette règle aux travaux de J. Scott Armstrong sur la prévision par extrapolation (1984).

Running Average Velocity, la moyenne glissante

Un seul Sprint peut être exceptionnel, dans un sens ou dans l'autre. Le pattern Running Average Velocity (vélocité en moyenne glissante) décrit le danger d'y réagir trop vite : une baisse ponctuelle déclenche des mesures d'urgence, une hausse fortuite devient la norme exigée. La solution est de calculer la vélocité comme la moyenne des Sprints les plus récents, trois au minimum. Les auteurs préfèrent cette moyenne glissante à la moyenne de tous les Sprints depuis l'origine, qui garde la trace de pratiques abandonnées. Ils en signalent le défaut : un Sprint anormal pèse sur plusieurs calculs, puis provoque un saut inverse quand il sort de la fenêtre.

Updated Velocity, ou reconnaître un nouveau palier

La moyenne glissante a une faiblesse pour une équipe qui progresse : elle est toujours en retard sur une série qui monte. À l'inverse, un bon Sprint isolé ne prouve pas qu'un progrès est acquis. Le pattern Updated Velocity (vélocité mise à jour) fixe une règle : on ne reconnaît une nouvelle vélocité que si l'équipe tient le nouveau niveau trois Sprints de suite. Les auteurs rapprochent cette prudence du modèle du changement de la thérapeute Virginia Satir, où toute nouveauté ouvre une période de désordre avant un nouvel équilibre.

Reprenons l'équipe de la mutuelle. Elle automatise une partie de ses vérifications, et les trois Sprints suivants donnent 31, 33 et 32 points. Après le premier, elle ne modifie pas ses prévisions. Après le troisième, le palier est confirmé, et elle retient 32, c'est-à-dire 96 divisé par 3.

Avec plusieurs équipes

Quand plusieurs équipes travaillent sur le même produit, le Product Owner a besoin d'une vélocité d'ensemble pour prévoir. Le pattern Aggregate Velocity (vélocité agrégée) examine les fausses solutions. Si chaque équipe estime « ses » éléments avec sa propre échelle, les chiffres ne se comparent pas, et faire leur moyenne reviendrait à mélanger des miles et des kilomètres sans connaître le taux de conversion. De plus, les éléments se trouvent attribués à une équipe bien avant leur réalisation, ce qui retire au Product Owner la liberté de les réordonner.

La solution est que toutes les équipes estiment ensemble tous les éléments, à partir d'une référence et d'une échelle communes. La vélocité agrégée est alors la somme des vélocités des équipes. Trois équipes qui terminent 25, 30 et 20 points sur la même échelle ont une vélocité agrégée de 75 points, et un Product Backlog de 300 points représente environ quatre Sprints. Les auteurs mettent en garde contre la tentation de se servir de cette échelle commune pour comparer les équipes entre elles.

Le pattern Specialized Velocities (vélocités spécialisées) traite le cas où les équipes se sont spécialisées par partie du produit, par exemple le système multimédia et le freinage d'une voiture. Faire estimer le freinage par l'équipe multimédia serait du temps perdu. La solution est que chaque équipe spécialisée estime et réalise les éléments de son domaine, en sollicitant au besoin l'avis d'autres personnes. Le pattern pose deux conditions : la spécialisation suit les domaines du produit et jamais les techniques (pas d'équipe de test), et aucune équipe ne peut s'en prévaloir pour refuser un élément.

La vélocité n'est pas un objectif

Imaginons qu'une direction demande à l'équipe de la mutuelle de faire passer sa vélocité de 25 à 30 au trimestre suivant. Le moyen le plus simple d'y parvenir ne demande aucun travail supplémentaire : il suffit qu'un élément estimé hier à 3 points en reçoive 5. La vélocité monte, la quantité livrée ne change pas, et les prévisions deviennent inutilisables puisque l'unité a changé en cours de route. D'autres raccourcis existent, comme déclarer terminé un travail qui n'a pas été vérifié.

Ce mécanisme est décrit par la loi de Goodhart : un indicateur renseigne tant que personne n'a intérêt à le faire bouger, et il se dérègle dès qu'on en fait une cible assortie d'enjeux. Les auteurs du livre vont dans le même sens. La note sur la vélocité précise qu'elle n'est pas une cible. Elle ajoute que le manque d'effort est rarement le problème et que demander à une équipe de « travailler plus dur » n'est donc pas la solution. Le pattern Running Average Velocity avertit qu'une pression excessive conduit aux heures supplémentaires et aux chiffres truqués.

Comparer les équipes par leur vélocité n'a pas davantage de sens. Une équipe à 50 points et une autre à 20 livrent autant si la première donne 5 points à ce que la seconde estime à 2.

Limites et pièges

Le Guide Scrum 2020 ne mentionne ni la vélocité, ni les points, ni le planning poker. Il demande seulement que les développeurs dimensionnent le travail, et il note que plus ils connaissent leurs performances passées, leur capacité à venir et leur définition de « terminé », plus leurs prévisions sont sûres. Tout ce que décrit cet article relève donc de pratiques complémentaires, que l'on peut faire du Scrum sans adopter.

La vélocité additionne des estimations, pas des résultats mesurés. Convertir les points en jours (« un point vaut une journée ») annule l'intérêt de la méthode. La météo d'hier suppose en outre une équipe stable et des Sprints de même durée : chaque changement de composition perturbe la série.

Sur les preuves, il faut rester mesuré. Les auteurs affirment que l'estimation relative est plus juste que l'estimation en heures, mais ils renvoient aussi à un article de Magne Jørgensen (2013), chercheur spécialiste de l'estimation, dont le titre indique que le résultat dépend de l'élément auquel on compare et de la manière de comparer. La précision de plus ou moins 20 % qu'ils attribuent aux prévisions par vélocité est une observation de praticiens. Certaines équipes renoncent d'ailleurs aux points et comptent des éléments découpés à une taille voisine, option que la note évoque sans la recommander. L'article Critiques et état des preuves fait le point sur ces questions.