Avant toute planification de réalisation d’un projet, il y a forcément une étape d’estimation. L’évaluation de la réalisation d’une tâche peut être basée sur des notions différentes comme des jours/homme, des heures, des points ou même les tailles des t-shirts (XS, S, M, L, XL…). Lorsque l’on pense méthode agile de gestion de projet, on pense souvent « poker planning » pour l’estimation. Nous allons voir ici que le poker planning, s’il est très répandu et a fait ses preuves, est loin d’être la seule méthode d’estimation agile à votre disposition.
Retour sur le principe de l’estimation agile
Le point commun à toutes les méthodes d’estimation agiles, c’est qu’elles sont basées sur la collaboration. On demandait souvent auparavant à une seule personne, n’ayant d’ailleurs pas forcément les connaissances nécessaires, de donner une estimation du travail à réaliser. Qui n’a pas connu il y a quelques années encore un projet dont l’estimation avait été faite uniquement par le commercial qui l’avait vendu au client ? On ne disposait alors que d’une vision étriquée du besoin, et même avec la meilleure volonté du monde, la personne chargée de l’estimation ne pouvait la faire qu’en fonction de ses connaissances et de son vécu.
Lors d’une estimation agile, toutes les personnes susceptibles d’apporter quelque chose au projet sont conviées et impliquées. Cela permet à chacun d’exprimer son point de vue et d’obtenir ainsi une vision beaucoup plus large de la fonctionnalité à estimer et des solutions pouvant être mises en place. La responsabilité de l’estimation est également partagée entre tous les membres de l’équipe et non pas imputable à un seul. Si l’estimation est incorrecte, c’est toute l’équipe qui est responsable. Chacun s’impliquera donc plus et ne craindra pas d’exprimer son opinion.
Le pragmatisme est le mot-clé des estimations agiles. Il ne s’agit pas d’obtenir au final la meilleure estimation, la plus juste et réaliste. L’estimation agile est basée sur un compromis obtenu entre les membres de l’équipe projet. Ce n’est pas une activité apportant une réelle plus-value sur le projet, aussi doit-elle prendre le moins de temps possible. C’est pour cette raison qu’une estimation agile ne sera jamais exprimée en jours/homme, en heures ou même en euros. Il s’agit d’une estimation qualitative et non quantitative. On va estimer la complexité de la réalisation d’une tâche, en se basant notamment sur l’expérience et sur des tâches similaires.
Cette complexité à réaliser une tâche sera mesurée grâce à une unité qualitative, généralement un nombre de points. Cela simplifie grandement l’estimation. Pour illustrer cela, nous pouvons demander à plusieurs personnes d’estimer le temps qu’elles ont passé à lire cet article jusqu’ici. Chacune aura une estimation différente, car la perception que l’on a du temps est différente suivant l’état d’esprit dans lequel on se trouve, l’intérêt que l’on porte au sujet…
En revanche, si l’on demande aux mêmes personnes d’estimer la difficulté de lecture de l’article par rapport à d’autres du même type, elles pourront beaucoup plus facilement répondre. C’est le même principe pour une estimation agile. On estime une difficulté en nombre de points en se basant sur des références.
Les différentes méthodes d’estimation agiles
Il existe plusieurs méthodes d’estimation agiles, chacune ayant ses avantages et ses inconvénients. Rien ne vous empêche de changer de méthode d’estimation à chaque sprint, jusqu’à ce que vous trouviez celle qui convient le mieux à votre équipe agile.
1- Planning poker
Certainement la méthode d’estimation la plus répandue dans Scrum.
Les participants utilisent un jeu de carte spécialement conçu pour le planning poker. Les cartes comportent les valeurs 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, « ∞ » et « ? ». Les valeurs représentent les estimations en nombre de points. Les valeurs faibles correspondent aux tâches les plus simples. Les valeurs 3, 5 et 8 sont généralement utilisées pour des tâches un peu plus complexes. La valeur 100 est généralement utilisée pour une tâche trop complexe, devant être redécoupée et répartie sur plusieurs sprints. La valeur « ∞ » représente une tâche beaucoup trop longue ou complexe pour être embarquée dans le sprint, et « ? » indique qu’il n’est pas possible de fournir une estimation dans l’état actuel des connaissances de l’équipe.
Chaque fonctionnalité est présentée, à la suite de quoi chaque participant au planning poker peut voter. Les cartes sont posées face cachée de façon à ce que personne ne sache qui vote quoi. Si un consensus n’est pas trouvé, chacun peut discuter de nouveau de la fonctionnalité. Votes et discussions s’enchaînent jusqu’à ce qu’une majorité se décide sur l’estimation. Le processus se répète pour chaque fonctionnalité présentée, généralement de deux à dix par planning poker.
2- Bucket System
Le processus est sensiblement le même que pour le planning poker, si ce n’est que l’on n’utilise pas des cartes, mais des conteneurs (bucket signifie « seau »). Chaque conteneur a une valeur (0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100 et 200), et on y place les fonctionnalités à estimer. Naturellement, il n’y a pas nécessairement de conteneurs physiques ou de seaux. Il suffit de les matérialiser avec leur valeur (un simple post-it au mur ou sur une table peut faire l’affaire) afin de pouvoir positionner les fiches des fonctionnalités en-dessous.
On choisit au hasard une première fiche dont on lit la description au reste des participants. Cette première fiche est ensuite placée dans le conteneur « 8 » et va maintenant servir de référence pour toutes les autres.
Une autre fiche est ensuite choisie au hasard pour être lue. Les participants discutent de la fonctionnalité jusqu’à ce qu’un consensus soit trouvé quant à sa position dans les conteneurs. Le processus se répète une troisième fois. Si l’on s’aperçoit que les estimations sont faussées à cause de fiches mal positionnées les unes par rapport aux autres, on les réévalue.
Les trois fiches évaluées vont maintenant servir de jalons pour les autres. Les fiches restantes sont réparties équitablement entre tous les participants. Chacun peut ensuite placer ses fiches dans le conteneur qu’il estime le plus approprié, et ce, sans consulter les autres.
Une fois l’ensemble des fiches réparties, la phase d’épuration peut commencer. Chacun examine l’ensemble des fiches et leurs positionnements respectifs. Si un participant trouve qu’une fiche n’est pas à sa place, il porte l’information à l’attention des autres. Une discussion s’en suit, jusqu’à ce qu’un consensus soit trouvé. La fiche est alors placée dans le conteneur correspondant.
A la fin de l’estimation, les valeurs des conteneurs sont reportées sur les fiches qu’ils contiennent.
Cette méthode d’estimation agile est un peu plus rapide que le planning poker, car il y a moins de discussions, tout en obtenant des résultats satisfaisants. Ce système peut également être utilisé avec des équipes plus importantes et un grand nombre de fonctionnalités (entre 50 et 500).
3- Big/Uncertain/Small
Si l’on a besoin d’une estimation moins précise mais plus rapide, cette méthode est tout à fait adaptée. Les participants classent simplement les fonctionnalités en trois catégories : big (importante), uncertain (incertaine) et small (petite). Quelques fonctionnalités sont discutées en détail et classées. Ensuite, le processus est le même qu’avec le « bucket system » : les fiches restantes sont réparties équitablement et classées dans les catégories. S’ensuit une phase d’épuration. A la fin de la procédure, toutes les fonctionnalités sont réparties d’un commun accord entre les trois catégories.
4- TFB / NFC / 1 (Sprint)
Cette méthode est très similaire à la précédente, mais avec les catégories TFB (« Too F-ing Big »), NFC (« No F-ing Clue ») et « 1 Sprint ». Le processus d’estimation est le même que pour la méthode « Big/Uncertain/Small ».
5- Dot Voting
Cette méthode est habituellement utilisée comme outil d’aide à la décision. Néanmoins, elle convient parfaitement pour réaliser rapidement l’estimation d’un petit nombre de fonctionnalités.
La liste des fonctionnalités à estimer est affichée et chaque participant se voit attribuer un petit nombre de points de vote (5 par exemple). Chacun vient ensuite distribuer ses points sur les différentes fonctionnalités. Il est possible de mettre plusieurs points sur une même fonctionnalité si on estime qu’elle est plus complexe ou plus longue à réaliser que les autres.
Une fois que tout le monde a distribué l’ensemble de ses points, on fait le total et une note est attribuée à chaque fonctionnalité. Plus la note est élevée, et plus la fonctionnalité va être longue ou compliquée à réaliser.
6- T-Shirt Sizes
Il s’agit d’une technique informelle, particulièrement adaptée pour traiter rapidement un grand nombre de fonctionnalités. Les catégories utilisées sont les tailles de t-shirt : XS, S, M, L XL.
Chaque fonctionnalité est discutée entre les participants, afin d’estimer dans quelle catégorie elle se place. Naturellement, la catégorie XS va contenir des fonctionnalités simples à réaliser, XL contiendra les plus complexes et les plus difficiles. Un vote peut être organisé si les participants n’arrivent pas à tomber d’accord durant la discussion.
7- Affinity Mapping
Les fonctionnalités ici sont regroupées par affinités, c’est-à-dire qu’elles présentent des similarités entre-elles, qui doivent être évaluées. Une fois les fonctionnalités classées, les regroupements peuvent être associés à une estimation numérique, ou être utilisés tels quels. L’estimation peut être complexe dans la mesure où elle demande une analyse fine des fonctionnalités pour pouvoir faire des recoupements. Cette méthode d’estimation est donc plutôt adaptée à un petit nombre de fonctionnalités, entre 20 et 50 maximum.
8- Ordering Procotol
Les fonctionnalités sont réparties aléatoirement dans un premier temps entre deux catégories : « basse » (« low ») et « haute » (« high »). Chaque participant a ensuite la possibilité d’effectuer une action. Une action peut consister à déplacer une fiche d’une catégorie à l’autre, de lancer une discussion à propos d’une fonctionnalité ou de passer son tour. Une fois que tout le monde a réalisé une action, le classement des fonctionnalités est définitif.
9- Divide until Maximum Size or Less
Avant de commencer, les participants décident de la taille maximale que peut avoir une fonctionnalité. On peut décider par exemple qu’une réalisation ne devra pas dépasser 1 jour-homme. Chaque fonctionnalité est alors analysée pour savoir si sa réalisation correspond à la limite fixée. Si les participants tombent d’accord sur le fait que la réalisation d’une fonctionnalité dépasse la limite fixée, elle est alors découpée en plusieurs sous-ensembles. On répète alors le processus sur ces sous-ensembles jusqu’à ce qu’aucune des fonctionnalités décrites ne dépasse plus la taille limite.
Pour conclure sur les méthodes d’estimation agiles
Il existe de nombreuses méthodes d’estimation agiles (vous pourrez facilement trouver des variantes de celles décrites dans cet article). Il ne faut pas hésiter à en tester plusieurs, à changer de méthode d’estimation d’un sprint à l’autre, et ainsi déterminer celle qui convient le mieux au projet, avec laquelle les membres de l’équipe sont le plus à l’aise. Vous pouvez également adapter la méthode d’estimation agile aux besoins du projet, suivant le nombre de fonctionnalités à analyser et de la taille de l’équipe. En fonction de ces critères, certaines méthodes seront mieux adaptées que d’autres, et donc plus efficaces.
La solution logicielle agile Nutcache fournit tous les outils nécessaires à la conduite d’une estimation pour un projet Agile. N’hésitez pas à tester la solution complète gratuitement durant une période de 14 jours.
