Press "Enter" to skip to content

Les estimations agile pour les nuls

Photo by Elisa Michelet on Unsplash

Les estimations agile pour les nuls

En tant qu’êtres humains nous sommes naturellement peu doués pour fournir des estimations.

Plutôt que d’essayer de nous rendre meilleurs à cet exercice pour lequel nous ne sommes intrinsèquement pas doués, les estimations “à la sauce agile” proposent de prendre le problème sous un angle différent pour rendre l’exercice naturel et facile.

Les biais de l’estimation en temps réel

Estimer en temps réel consiste à donner une estimation sous la forme du temps que cela prendrait réellement à faire.

  • Nous sommes toujours trop optimistes
  • Difficile de tenir compte des imprévus, même s’ils se produisent de manière récurrente
  • Deux personnes différentes ne mettront pas le même temps à faire le même travail
  • Nous parlerons plus bas de l’estimation relative, c’est à dire estimer en comparant aux précédents éléments de travail ; si on peut en appliquer les principes tout en fournissant des estimations en temps réel, il est très difficile de ne pas se projeter lorsqu’on donne des estimations en temps réel ce qui met directement en péril l’approche d’estimation relative
  • Une fois une estimation en temps réel donnée, cela crée un cadre où, consciemment ou inconsciemment, nous allons essayer de nous y conformer — dans un sens comme dans l’autre : par exemple dans le cas où l’estimation est trop petite en prenant certains raccourcis pour tenir le temps donné ; ou encore dans le cas où l’estimation est trop grosse en passant trop de temps sur des sujets secondaires là encore pour tenir le temps donné
  • Enfin, certaines personnes peuvent avoir des difficultés à considérer des estimations comme des estimations et non pas comme des engagements ou des promesses ; les estimations en temps réel rendant cette incompréhension d’autant plus facile. Sur cette question des estimations non comprises comme des estimations, Constantin Guay a rédigé deux excellents articles qui en font très bien le tour (liens en fin d’article)

Les alternatives agile classiques : temps idéal et points

Plutôt que d’estimer en temps réel, on recommande plutôt dans le monde de l’agilité d’estimer en temps idéal ou mieux encore avec des points.

Deux clés expliquent pourquoi ces manières de faire sont considérées meilleures :

  • On décorrèle l’estimation donnée du temps effectif que cela devrait prendre, en se reposant vers un outil de traduction entre les deux : la vélocité. La vélocité est mesurée, ce qui garantit sa pertinence.
  • On favorise l’estimation relative, c’est à dire estimer en comparant à d’autres éléments de travail, plutôt qu’en se projetant en train de faire le travail.

Ces deux éléments ensemble permettent généralement de réduire voire d’annuler les biais précédemment énoncés.

Temps idéal et points : ne plus parler de temps réel

Estimer en temps idéal consiste à donner une estimation sous la forme du temps que cela prendrait idéalement à faire, sans aucune interruption ni autre ralentissement.

Estimer à 8 heures idéales cela veut dire que cela prendrait 8 heures dans un monde idéal, pour le développeur compétent sur le sujet, sans aucune interruption, aucun changement de sujet… En aucune manière cela implique réellement 8 heures de travail effectif, et encore moins 8 heures de délai de réalisation.

Estimer en points consiste à donner une estimation sous la forme d’une unité abstraite, complètement décorrélée du temps réel. L’utilisation de l’estimation relative est essentielle : ces points n’ont aucun sens en eux-même, c’est la comparaison entre plusieurs éléments qui leur donne du sens.

Estimer à 2 points cela veut dire environ autant qu’un autre élément estimé à 2 points, soit donc plus qu’un autre élément estimé à 1 point, mais aussi moins qu’un autre élément estimé à 3 points. Voilà tout, il n’y a rien d’autre à comprendre : c’est l’unité d’estimation relative par excellence.

Que choisir entre temps idéal et points ? Il est recommandé par défaut de pencher pour les points. En effet, les points effacent encore plus les biais de l’estimation en temps réel que le temps idéal car ils se séparent complètement de toute notion de temps.

On a beau préciser qu’on parle de temps idéal, certaines personnes continueront de considérer ce temps comme un engagement plutôt que comme une estimation. En manipulant des points et en ne parlant plus du tout de temps, on réduit ce risque.

Qu’il s’agisse de temps idéal ou de points, ces unités d’estimation ne peuvent en aucun cas donner un volume de travail effectif ni un délai de réalisation qui permet de faire une quelconque planification. Et c’est exactement le but recherché, pour réduire au maximum l’impact des biais de l’estimation en temps réel évoqués au début de cet article.

Une première clé : la vélocité, mesure factuelle

Or, c’est pourtant bien le volume de travail effectif ou le délai de réalisation qui sont utiles. Ainsi on voudra savoir s’il sera possible de tenir une quelconque échéance, par exemple pour être prêt pour une démo lors d’une prochaine conférence.

Comment faire le lien entre temps idéal ou points et le volume de travail effectif ou le délai de réalisation ? Avec la vélocité.

La vélocité est la mesure moyenne du volume de travail que produit l’équipe pendant une itération, à durée d’itération moyenne.

Avec la vélocité, on peut donc projeter sur un calendrier les estimations en temps idéal ou en points. Par exemple, si une équipe a une vélocité moyenne de 20 points par itération, alors on peut estimer que cela nécessitera 5 itérations de travail à cette équipe pour livrer une release de 100 points :

estimation (points) / vélocité moyenne(points/itération) = temps (itérations)

L’utilisation de la vélocité change la donne par rapport aux estimations en temps réel :

  • La vélocité est mesurée, elle est donc factuelle, réelle.
  • En particulier elle n’est plus sujette à l’optimisme, et elle tient compte des imprévus récurrents.
  • Plus précisément, elle donne la véritable capacité de production de l’équipe : il est impossible de dire que l’équipe n’avance pas assez vite… Elle avance juste à son rythme. S’il s’annonce compliqué de tenir les délais, la solution est à chercher ailleurs que de mettre la pression à l’équipe pour aller plus vite.
  • La vélocité est une moyenne, ce qui permet de la rendre assez fiable en gommant les situations exceptionnelles.
  • La vélocité est également une mesure d’équipe et non pas individuelle.
  • En particulier cela prend naturellement en compte les absences d’équipe, mais aussi les différences de compétence entre ses différents membres.

Une deuxième clé : l’estimation relative

L’estimation relative consiste à comparer l’élément de travail à estimer avec d’autres éléments de travail déjà réalisés. On choisira l’estimation qui correspond le mieux en comparant à ces éléments de travail déjà réalisés.

L’estimation relative permet de fournir plus rapidement des estimations plus fiables:

  • Une estimation classique consiste à se projeter sur le travail à faire et à le découper en plus petits morceaux, en théorie plus faciles à estimer. L’estimation relative reste au niveau global de l’élément de travail à estimer et permet donc d’estimer plus rapidement.
  • Par définition, une estimation sera toujours imprécise. Cependant, en faisant de l’estimation relative, on réduit cette imprécision pour un cout minimal car on compare à des éléments de référence déjà connus, déjà mesurés.

On peut constater que l’estimation relative est une autre raison forte qui incite à préférer les points au temps idéal : en enlevant toute notion de temps, il est naturel de faire de l’estimation relative lorsqu’on estime en points. À l’inverse, lorsqu’on estime en temps idéal on reste tenté de se projeter et de partir du travail à faire. Faire de l’estimation relative en temps idéal demande plus d’efforts que lorsqu’on estime en points.

Autres astuces

Il est important de réaliser que le temps passé à estimer est du temps perdu. En langage Lean on parle de gâchis ou waste.

Quoi qu’il arrive, passer une heure à estimer crée moins de valeur que passer une heure à faire le travail en question.

Loin de moi l’idée de dire que les estimations sont complètement inutiles : seulement, il faut essayer de réduire au maximum le temps passé à estimer.

Tout l’enjeu des estimations agile est de trouver des manières d’estimer qui permet d’obtenir des estimations suffisamment précises pour un minimum de coût — en un minimum de temps. C’est tout l’enjeu de l’estimation relative introduite dans la précédente section.

Voici d’autres éléments classiques des estimations agile qui permettent d’optimiser effort et qualité d’estimation.

Suite de Fibonacci ou puissances de 2

On estime généralement en suivant la suite de Fibonacci. Parfois les puissances de 2. Cela veut dire que lorsqu’on estime, on est obligé de sélectionner un des éléments de la suite, et pas une valeur entre deux éléments de la suite.

La suite de Fibonacci définit ses éléments comme la somme des deux précédents éléments de la suite. En voici le début : 1, 2, 3, 5, 8, 13, 21,34, 55… Par exemple 8=5+3 ou 21=13+8.

La suite composée par les puissances de 2 définit ses éléments comme la multiplication par 2 du précédent élément de la suite. En voici le début : 1, 2, 4, 8, 16, 32, 64, 128… Par exemple 4=2×2 ou 64=32×2.

Pourquoi s’imposer ainsi d’utiliser ces valeurs ? Pourquoi s’interdire d’utiliser les valeurs intermédiaires ? À nouveau pour minimiser l’effort d’estimation tout en maximisant la qualité de l’estimation.

Ces suites en tant que valeurs d’estimation nous disent une chose :

Plus l’élément à estimer est gros, plus il est difficile de l’estimer précisément.

En se forçant à utiliser ces suites pour fixer l’estimation, plus l’élément est gros et moins on se préoccupe des détails.

Cette approche est réellement puissante. Elle permet de facilement trancher si une discussion est pertinente ou non lorsqu’elle rentre dans les détails. Et d’ainsi gagner du temps ! Il suffit de se demander :

“Est-ce que cela va changer significativement l’estimation ? Au point de le faire passer à la valeur supérieure ou inférieure ? Si ce n’est pas le cas, ce n’est pas le bon moment pour aller dans le détail. Passons à autre chose.”

Les estimations collectives avec le Planning Poker

Vous avez sûrement entendu parler du Planning Poker : c’est l’icône du folklore agile.

Le planning poker
Un jeu de Planning Poker typique

Le Planning Poker est une manière de faciliter les sessions d’estimation. Il prend la forme d’un jeu de cartes comportant les valeurs utilisées pour fixer les estimations, typiquement la suite de Fibonacci ou parfois les puissances de 2. Chaque personne qui participe à la session d’estimation dispose de son propre jeu avec toutes ces valeurs.

Après une brève présentation de l’élément de travail à estimer, chaque participant va choisir, cartes cachées, la carte avec l’estimation qu’il pense être la bonne. Puis toutes les cartes sont retournées en même temps, pour confronter les estimations de chacun.

Si tous les participants ont donné la même estimation, alors on estime cet élément de travail à cette valeur-là. Si par contre les valeurs diffèrent, on va demander aux valeurs lers plus basses et plus hautes d’expliquer brièvement leurs positions. Puis on se lance dans un nouveau tour d’estimation.

Le Planning Poker sert donc tout d’abord à accélérer le processus d’estimation en lui donnant du rythme et un côté ludique.

Il sert aussi ce but en limitant le temps passé sur les détails : si tout le monde s’accorde sur une même estimation sans être d’accord sur les détails, cela n’empêche pas de fixer l’estimation et d’avancer.

Mais le Planning Poker permet aussi d’améliorer la qualité des estimations. Le Planning Poker fait estimer tous les participant en même temps : tout le monde est tenu d’estimer et on retourne les cartes en même temps. Cela réduit voire annule un certain nombre d’effets de groupe :

  • L’effet d’ancrage : dès lors que la première estimation est donnée, cela va influencer tout le groupe durablement. Ainsi, une première estimation très élevée va naturellement et significativement influencer tout le monde à donner une estimation élevée. De la même manière une première estimation très basse va naturellement et significativement influencer tout le monde à donner une estimation faible. En révélant les estimations de tout le monde en même temps, on annule cet effet d’ancrage.
  • L’expert qui annonce de but en blanc l’estimation ou tous les éléments de contexte qui mènent à cette estimation. Tout le monde se range à son avis sans vraiment réfléchir à la question. On peut également le constater avec un manager, ou un Tech Lead. Le Planning Poker sert à faire participer tout le monde. Cela permet de faciliter l’intelligence collective et ainsi obtenir de meilleurs estimations en prenant bien en compte les différents points de vue.
  • Timidité : certains membres de l’équipe peuvent être très brillants mais peu à l’aise pour prendre la parole. Le Planning Poker les fait participer directement et leur crée naturellement le forum où ils s’exprimeront, lorsqu’ils donneront une estimation plus élévée ou plus basse que les autres participants.

Les premiers sprints

Comment faire lorsqu’on doit estimer le volume de travail que peut prendre une nouvelle équipe ? En l’absence d’historique de vélocité pour en jauger ?

La vélocité doit servir à de la planification à long terme, qui dépasse l’horizon d’un seul sprint. Et en effet, lors de la constitution d’une nouvelle équipe, il n’existe pas de vélocité qui permet de faire de planification à long terme. Une fois les premiers sprints terminés, on commencera à avoir une vélocité, qui deviendra de plus en plus précise au fil des itérations.

On n’a pas besoin de vélocité pour définir le périmètre du prochain sprint. Il suffit à l’équipe de se projeter sur le volume de travail à faire et de juger de si elle réussira à le faire d’ici la fin du sprint ou non. Pour ce travail-là, qui est à court terme et sur de petites choses, l’équipe peut faire des estimations en temps réel si elle le juge nécessaire. Mike Cohn a très bien décrit cette approche dans une série d’article. (liens en fin d’article)

Et pourquoi ne pas se passer complètement d’estimations ? #NoEstimates

Si on résume la situation décrite précédemment :

  • Les estimations ont un tas de problèmes
  • Passer du temps à estimer est moins rentable que de travailler directement

À partir de là Vasco Duarte crée le mouvement #NoEstimates qui promeut l’abandon complet des estimations.

Cela peut sembler révolutionnaire, voire irréaliste, pourtant la mise en pratique est très rationnelle :

  • Ne plus donner d’estimation précise à chaque élément de travail, mais uniquement compter le nombre d’éléments de travail. En moyenne, cela donnera un indicateur très fiable.
  • Pour fonctionner, cela n’annule pas le besoin d’échanger et de comprendre le travail à faire. L’équipe continuera donc de se retrouver et discuter, même si elle n’estime plus.
  • Par ailleurs, cela renforce potentiellement le besoin de découper les éléments de travail en petits éléments de travail, et d’une taille relativement uniforme.

Le #NoEstimates mérite certainement son propre article de vulgarisation à part entière. Néanmoins, on peut retenir que cela ne change pas fondamentalement les choses et qu’il est inutile d’en avoir peur.

Pour aller plus loin

Rappel du sens d’une estimation

Comment mener la Planification de Sprint, avec et sans vélocité

#NoEstimates : présentation par Samuel Retiere et Twitter de Vasco Duarte

Que pensez-vous de cet article?

J’apprécierais vraiment si vous pouviez me laisser un commentaire pour me dire ce que vous appréciez ou ce qui pourrait être amélioré dans cet article.

Et si vous avez aimé cet article, merci de le partager !

À bientôt 😊

Top