Réaliser des estimations avec le planning poker

Le planning poker est la technique la plus répandue pour faire des estimations dans le cadre d’un projet agile. Les estimations sont réalisées en équipe et font appel à l’intelligence collective. Découvrez avec Florent Lothon de L’agiliste comment fonctionne cette technique innovante.

Extrait de la vidéo de formation : MOOC Gestion de projet agile avec scrum  

Nous allons aborder le sujet des estimations de la charge de travail. Sur un projet agile, la technique d’estimation la plus répandue s’appelle le Planning Poker. Une technique qui présente plusieurs avantages, dont celui de tirer profit de l’intelligence collective de l’équipe de développement. Cette technique n’est donc pas basée sur une estimation à dire d’expert, mais plutôt sur la vision de plusieurs membres d’une même équipe.

Le jeu de carte

Cette méthode d’estimation se pratique avec un jeu de carte, d’où son nom. Chaque participant dispose des même cartes dont les valeurs sont inspirées de la suite de Fibonacci: 0, 1/2, 1, 2, 3, 5, 8 etc jusqu’à 100. Plus ça monte et plus l’écart entre les valeurs est important. L’unité est généralement appelé le point ou le story point. Pour simplifier, on peut la considérer comme une sorte d’unité d’oeuvre de gestion de projet agile.

Déroulement du planning poker

Le déroulement est simple. Tout d’abord, le Product Owner présente un élément du Product Backlog aux participants, c’est à dire les membres de l’équipe de développement. Il répond aux éventuelles questions. Puis chaque participant – en dehors du Product Owner  - choisit la valeur qui lui semble correspondre à la complexité de la solution à mettre en oeuvre. On considère que la complexité est directement liée à la charge de travail. Pour y parvenir, il va comparer cette complexité à un élément étalon auquel on a attribué au préalable une valeur arbitrairement. Et plus il y a d’éléments estimés, plus l’équipe dispose d’éléments de comparaison pour fiabiliser les estimations.

Une fois que chaque participant a choisi sa carte, et il ne peut choisir qu’une seule carte, tout le monde retourne sa carte en même temps afin de ne pas influencer les autres. On constate souvent des écarts entre les différents membres, et c’est bien l’intérêt du Planning Poker en matière de prise de recul mutuelle au sein de l’équipe. On invite alors les personnes ayant les estimations les plus éloignées à expliquer leur estimation. Puis on procède à un nouveau tour d’estimation jusqu’à converger.

Le nombre limité de cartes et les écarts entre les valeurs, permet d’accélérer l’estimation. La prise de recul mutuelle permet quant à elle d’éviter de trop grosses erreurs d’estimation. 

Enfin, tout se base sur le constat qu’une estimation, n’est qu’une estimation, et qu’elle est donc fausse par définition. Elle permet simplement d’engager un budget approprié, mais surtout d’aider le Product Owner à ordonnancer son Product Backlog et à planifier les versions du produit à bon escient.

Quand estimer ?

Au démarrage d’un projet, on passe pas mal de temps à faire l’estimation de chaque élément du Product Backlog, jusqu’à estimer l’intégralité du Product Backlog initial. Une fois qu’on a la somme totale, on peut commencer à évaluer le nombre de points que l’équipe va se sentir capable de faire par sprint. Et c’est comme cela qu’on peut définir, à peu près, le nombre de sprints qu’on pense nécessaires pour aboutir à la livraison d’une première version du produit.

Puis en cours de projet, l’équipe Scrum sera régulièrement amenée à estimer de nouveaux éléments candidats à intégrer le Product Backlog. De nouvelles idées par exemple. Ou à découper, voire ré-estimer des éléments trop gros.

Synthèse des avantages

En synthèse, en termes d’avantages, le Planning Poker tire parti de l’intelligence collective en matière de prise de recul et d’idées sur les modalités de réalisation. Le Product Owner peut partager sa vision du produit à cette occasion avec l’équipe qui le réalise. Il bénéficie également d’une transparence absolue sur les estimations et peut même ajuster son besoin en séance pour arriver à un “coût” de réalisation optimal par rapport à la valeur associée à son besoin. L’équipe de développement quant à elle a la possibilité de poser ses questions directement, plutôt que de partir uniquement d’un cahier des charges papier. Enfin, une fois la technique rodée, les estimations sont rapides grâce au recours à la suite de Fibonacci et au principe d’estimation par relativité. 

Inscrivez-vous à la prochaine session du MOOC Gestion de projet agile avec scrum