Estimation relative

Objectif

L'estimation relative sert à dimensionner et à ordonner un backlog sans chiffrer d'emblée des heures ou des francs. L'Agile Extension lui prête trois usages: déterminer le coût et l'effort d'un ensemble de travaux, établir les priorités de l'initiative, s'engager sur un calendrier. Le guide place les estimations hors de la solution livrée: elles servent aux décisions internes de l'équipe et de ses commanditaires.

Le produit de la technique est un backlog dont chaque item a reçu une taille sur une échelle commune, plus la vélocité relevée sur les itérations précédentes. Ces deux éléments ensemble répondent à la question que pose un comité de pilotage: combien d'itérations pour ce périmètre.

Place dans la famille des estimations

L'estimation au sens général rassemble les méthodes qui produisent une quantité dans une unité réelle, un délai, un coût ou une charge, fût-ce sous forme de fourchette. L'estimation relative produit un rang sur une échelle sans dimension. La quantité n'apparaît qu'ensuite, quand la vélocité de l'équipe convertit un total de points en nombre d'itérations, puis ce nombre en francs au coût constaté d'une itération. L'Agile Extension se rattache à la technique générale et en décrit l'adaptation au contexte agile.

Une charge en jours-personne se compare entre équipes, se cumule entre projets et s'inscrit dans un contrat. Un rang sans unité se prête à un seul usage, l'ordonnancement d'un backlog par une équipe donnée, et la plupart des erreurs viennent de ce qu'on lui demande les trois autres.

Usage

Quand l'utiliser

• Backlog à ordonner avant un engagement: comparer les items entre eux suffit à décider de la séquence de livraison.
• Équipe stable qui livre par itérations: la vélocité constatée traduit les points en nombre d'itérations.
• Items encore mal définis: l'incertitude entre dans la taille sans qu'il faille décomposer l'item en tâches.
• Arbitrage entre initiatives d'un portefeuille: situer l'ampleur des candidates avant d'engager une étude de coût détaillée.
• Ouverture d'une itération: chaque item reçoit sa taille en séance, sans travail préparatoire individuel.

Quand ne pas l'utiliser

• Engagement contractuel en heures ou en francs: chiffrer directement, par estimation ascendante ou paramétrique.
• Équipe recomposée à chaque itération: la vélocité n'a pas de base de référence, décomposer et chiffrer en unités de temps.

Description

Ce que le chiffre mesure

L'Agile Extension fonde la taille d'une user story sur cinq facteurs, que la séance interroge item par item. La connaissance: de quelle information l'équipe dispose-t-elle sur cet item. L'expérience: a-t-elle déjà fait cela ou quelque chose d'approchant. La complexité: quelle difficulté la mise en œuvre présente-t-elle. La taille: quelle quantité de travail l'item demande. L'incertitude: quelles variables et quels facteurs inconnus peuvent le perturber.

Un seul de ces facteurs suffit à placer un item en haut de l'échelle. Un travail de deux jours dont personne ne connaît le comportement du système voisin se cote au-dessus d'un travail d'une semaine que l'équipe a déjà mené trois fois. Le chiffre agrège une quantité de travail et un degré d'ignorance.

L'échelle et la story de référence

L'échelle usuelle est une suite de Fibonacci modifiée, arrondie dans le haut: 1, 2, 3, 5, 8, 13, 20. Les écarts se creusent à mesure que les nombres montent, ce qui interdit une discussion entre 12 et 13 sur un item dont on ne sait presque rien. Deux valeurs voisines dans le bas de l'échelle recouvrent des travaux dont l'équipe perçoit la différence; deux valeurs voisines dans le haut recouvrent des travaux qu'elle ne sait pas départager. Les tailles de t-shirt (XS, S, M, L, XL) appliquent le même principe ordinal à des étiquettes.

L'équipe choisit une story de référence: un item déjà livré, petit, bien compris de tous, auquel on attribue 2 ou 3. Toutes les autres tailles se posent par rapport à celui-là. Un item plus gros que la plus grande carte du jeu appelle un découpage, que la séance signale avant que l'item entre dans une itération.

Amorcer l'échelle

L'Agile Extension donne trois points de départ à une équipe qui n'a pas encore d'historique. Le premier est l'ordre de grandeur: on dimensionne grossièrement, on ajuste aux itérations suivantes. Le deuxième part d'un jeu de ressources donné et d'une itération de durée fixe, puis laisse la première itération montrer ce qui y tient. Le troisième fait estimer en temps, par l'équipe, un échantillon de stories de tailles différentes, puis extrapole ce que l'itération peut absorber.

La justesse de ces trois amorces importe peu: l'Agile Extension pose que les premières estimations sont plus grossières que celles produites à l'approche de la livraison, et la technique tire sa valeur de la correction qu'apporte chaque itération.

Le planning poker

Le planning poker dimensionne les items en séance, avec toute l'équipe, d'ordinaire pendant l'atelier de planification. L'équipe passe en revue un item du backlog jusqu'à ce que chacun en ait la même compréhension. Chaque membre choisit alors en privé une carte sur l'échelle de points, puis toutes les cartes se retournent en même temps. Si les valeurs tiennent dans un degré d'écart, l'équipe en retient une et passe à l'item suivant. Si l'écart est large, elle discute de la connaissance que l'un possède et que les autres n'ont pas, celle qui explique qu'un même item paraisse à 3 et à 13. La séance vise l'accord sur chaque item.

Tout le mécanisme tient à la révélation simultanée: elle empêche la première valeur énoncée de fixer les suivantes. James Grenning a formalisé la technique en 2002, Mike Cohn l'a diffusée dans la pratique agile en 2005.

La magic estimation

La magic estimation, appelée Silent Sizing au §7.13.4 de l'Agile Extension, traite tout un backlog par le déplacement de cartes, en silence. L'équipe prépare un jeu de cartes, un item par carte. Il lui faut aussi un mur ou une table pour aligner les cartes. Chacun à son tour prend une carte et la pose sur la ligne, les plus petits items à une extrémité, les plus gros à l'autre; un membre peut déplacer une carte déjà posée. Le tour se répète jusqu'à ce que toutes les cartes soient sur la ligne. L'équipe repère ensuite les ruptures, les endroits où l'écart de taille entre deux cartes voisines se creuse, puis forme des groupes. À ce moment seulement, chaque groupe reçoit une valeur de l'échelle, et chaque carte prend la valeur de son groupe.

La position relative est posée avant qu'un nombre existe. Le prix à payer est le silence: la connaissance qu'une discussion aurait fait sortir reste chez celui qui la détient.

La vélocité et la conversion en calendrier

La vélocité est le total des points terminés dans une itération. Sur plusieurs itérations, elle donne la mesure du débit de l'équipe, sur laquelle reposent ses engagements suivants. Elle se lit en fourchette: une équipe qui a livré 34, 41, 38 et 45 points annonce une fourchette de 34 à 45 points. Une moyenne unique, 39,5, donnerait au comité une précision que quatre relevés ne portent pas.

Le total des points du périmètre divisé par la vélocité basse puis par la vélocité haute donne un nombre d'itérations en fourchette. Le coût s'obtient en multipliant ce nombre par le coût complet d'une itération, celui que la comptabilité analytique connaît. La conversion passe donc toujours par la vélocité. Un prix au point la court-circuite et coupe le seul lien qui rattachait les points à une quantité réelle.

Ce qui fausse l'estimation

Le taux de conversion fixe

Poser qu'un point vaut quatre heures rétablit l'unité que la technique écarte. Le rapport ainsi figé bouge pourtant à chaque changement de composition de l'équipe. L'équipe cote alors les items en heures dans sa tête, puis divise pour trouver la carte à jouer. Les cinq facteurs disparaissent, l'incertitude avec eux. Il ne reste qu'une estimation en heures déguisée en points.

La comparaison entre équipes

Les nombres appartiennent à l'équipe qui les a posés. Un 5 chez l'une n'a pas de rapport avec un 5 chez l'autre, et l'Agile Extension range la comparaison entre équipes parmi les limites de la technique, pour la confusion qu'elle installe chez les parties prenantes. La vélocité comparée devient un indicateur de performance, et une équipe mesurée sur sa vélocité l'augmente en une itération, en cotant plus haut. Le chiffre monte, le travail livré ne bouge pas.

L'ancrage en séance

Un architecte qui annonce sa valeur avant la révélation retire à la séance ce qu'elle produisait: des jugements formés indépendamment, puis confrontés. Le même effet s'obtient plus discrètement par le tour de table où l'on montre les cartes de gauche à droite. L'ordre de révélation se fixe donc d'avance.

Le recalibrage passé sous silence

Une équipe recalibre son échelle avec le temps: ce qu'elle cotait 3 il y a six mois, elle le cote 2 aujourd'hui. L'opération est saine, mais elle rend l'ancienne vélocité incomparable à la nouvelle. Recalibrer sans le dire produit une courbe de vélocité qui semble décrocher sans raison et une discussion de comité sur une baisse de performance qui n'a pas eu lieu. La parade est de dater le recalibrage et de repartir de la nouvelle fourchette.

L'estimation lue comme une date

L'Agile Extension signale deux lectures fautives de la part des parties prenantes extérieures à l'équipe. La première prend l'estimation relative pour un délai ferme. Dans la seconde, l'attention se fixe sur l'estimation, qui est une production, quand le résultat recherché est la valeur livrée. On y répond en présentant la conversion: une fourchette d'itérations et le coût qui en découle, révisés à chaque itération. Un comité auquel on montre un total de points cherchera toujours à savoir combien vaut un point.

Considérations IA

Avant la séance, un modèle de langage travaille sur le backlog et sur l'historique de l'outil. Il repère les items dont la description ne permet pas d'en juger la taille, ceux qui recouvrent un item déjà livré dont la taille passée sert de comparaison, ceux qui dépassent la plus grande carte du jeu et dont il propose un découpage. Sur l'historique, il calcule la fourchette de vélocité, isole les itérations atypiques et signale une dérive de l'échelle en comparant la taille moyenne des items d'un trimestre à l'autre.

Le chiffre lui-même reste à l'équipe. Un modèle interrogé sur la taille d'un item produit une valeur plausible tirée d'autres projets, alors que les cinq facteurs portent tous sur ce que cette équipe sait, a déjà fait et ignore. La valeur arrive donc calibrée sur une échelle étrangère à l'historique dont l'équipe a tiré la sienne. Le risque est plus grand encore quand le modèle est mis dans la boucle de la séance: une proposition affichée avant la révélation des cartes est un ancrage comme un autre. Enfin, un backlog contient des segments de clientèle, des montants et des contraintes réglementaires qui n'ont pas à sortir de l'entreprise, et on les retire avant tout envoi vers un modèle public.

Exemples

Dans une banque de détail suisse, l'équipe du produit de banque numérique dimensionne les items du module de simulation hypothécaire de son application mobile, avant la revue budgétaire du comité de pilotage. Le jeu de cartes va de 1 à 20 et la story de référence, cotée 2, est l'ajout d'un champ au formulaire de simulation, livré deux itérations plus tôt.

Le flux de taux a démarré partagé entre 5 et 13. La discussion a fait apparaître que le fournisseur était nouveau pour tout le monde, et l'équipe a retenu 13 pour cette raison seule, sans que le volume de travail attendu ait changé. La reprise des simulations est au plafond du jeu pour une raison voisine: rien de ce que l'équipe a livré ne lui ressemble. La justesse de la technique tient à cette ressemblance.

Sur les quatre itérations précédentes, l'équipe a terminé 38, 44, 36 et 42 points, soit une fourchette de 36 à 44 points par itération de deux semaines. Le périmètre présenté au comité totalise 210 points, ce qui donne cinq à six itérations. Au coût complet d'une itération, CHF 45'000 au niveau d'effectif actuel, le comité reçoit une fourchette de CHF 225'000 à CHF 270'000 et la date correspondante. Il ne reçoit à aucun moment un prix au point.

Visualisations

Le dessin qui enseigne la technique est la ligne de la magic estimation. Une première rangée y montre les cartes d'items posées les unes après les autres, du plus petit au plus grand, sans qu'aucun nombre n'apparaisse. La même rangée, en dessous, est coupée aux ruptures d'écart en quatre groupes, et chaque groupe reçoit alors sa valeur de l'échelle.

Le tableau du backlog dimensionné est la seconde figure: un item par ligne, sa taille et le facteur qui l'explique.

Coût

Outils

Les outils de gestion de backlog (Jira, Azure DevOps, GitLab et leurs équivalents) tiennent le champ de points sur l'item et calculent la vélocité à partir de ce qui a été terminé. Ils sont aussi la source de l'historique dont vit la technique: sans relevé fiable par itération, la vélocité est une opinion.

Les outils de vote simultané (applications de planning poker, modèles de tableau blanc collaboratif) rendent la révélation simultanée praticable pour une équipe distribuée, ce qu'une visioconférence sans dispositif de vote ne permet pas: quelqu'un y annonce toujours son chiffre avant les autres.

Le jeu de cartes physique reste le plus rapide pour une équipe co-localisée, et le mur avec ses cartes est le seul dispositif où la magic estimation se déroule à sa vitesse naturelle. À distance, un tableau blanc collaboratif reprend la ligne et les groupes, au prix d'une manipulation plus lente.

Le tableur suffit à tenir la fourchette de vélocité et la conversion en itérations et en francs, quelques lignes que l'on montre au comité de pilotage.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.13 Relative Estimation: la finalité de la technique, le caractère progressif de l'estimation en contexte agile, les trois apports aux parties prenantes, les cinq facteurs de la taille d'une story, l'échelle de Fibonacci, la définition de la vélocité, les trois amorces d'échelle, le planning poker et le dimensionnement silencieux, ainsi que les forces et les limites énoncées, dont la dépendance de la justesse à la ressemblance des nouvelles stories avec celles déjà livrées, la comparaison entre équipes, la lecture de l'estimation comme un délai ferme et l'attention portée à la production plutôt qu'au résultat.
• IIBA, Agile Extension to the BABOK Guide, §4.7.1, §5.7.1 et §6.7.1, les techniques par horizon de planification: l'usage de la technique à l'horizon Stratégie pour situer la valeur et les ressources des initiatives d'un portefeuille et aux horizons Initiative et Livraison pour décider quelles fonctionnalités livrer et dans quel ordre.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.19 Estimation: la technique générale d'estimation, à laquelle l'Agile Extension se rattache et dont elle décrit l'adaptation au contexte agile.
• Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005: la référence de pratique qui a diffusé les story points, la story de référence, le jeu de cartes de Fibonacci arrondi dans le haut et l'usage de la vélocité comme unique voie de conversion vers un calendrier.
• Mike Cohn, Agile Estimating: How Teams Estimate with Story Points, Mountain Goat Software: l'énoncé de la distinction entre effort relatif et durée absolue, ainsi que le caractère propre à chaque équipe de l'échelle de points.
• Agile Alliance, entrée Planning Poker du glossaire: le déroulement de la technique et sa formalisation par James Grenning en 2002, puis sa diffusion par Mike Cohn en 2005.