Réali­ser des esti­ma­tions avec le plan­ning poker

Le plan­ning poker est la tech­nique la plus répan­due pour faire des esti­ma­tions dans le cadre d’un projet agile. Les esti­ma­tions sont réali­sées en équipe et font appel à l’in­tel­li­gence collec­tive. Décou­vrez avec Florent Lothon de L’agi­liste comment fonc­tionne cette tech­nique inno­vante.

Extrait de la vidéo de forma­tion : MOOC Gestion de projet agile avec scrum  

Nous allons abor­der le sujet des esti­ma­tions de la charge de travail. Sur un projet agile, la tech­nique d’es­ti­ma­tion la plus répan­due s’ap­pelle le Plan­ning Poker. Une tech­nique qui présente plusieurs avan­tages, dont celui de tirer profit de l’in­tel­li­gence collec­tive de l’équipe de déve­lop­pe­ment. Cette tech­nique n’est donc pas basée sur une esti­ma­tion à dire d’ex­pert, mais plutôt sur la vision de plusieurs membres d’une même équipe.

Le jeu de carte

Cette méthode d’es­ti­ma­tion se pratique avec un jeu de carte, d’où son nom. Chaque parti­ci­pant dispose des même cartes dont les valeurs sont inspi­rées de la suite de Fibo­nacci: 0, 1/2, 1, 2, 3, 5, 8 etc jusqu’à 100. Plus ça monte et plus l’écart entre les valeurs est impor­tant. L’unité est géné­ra­le­ment appelé le point ou le story point. Pour simpli­fier, on peut la consi­dé­rer comme une sorte d’unité d’oeuvre de gestion de projet agile.

Dérou­le­ment du plan­ning poker

Le dérou­le­ment est simple. Tout d’abord, le Product Owner présente un élément du Product Back­log aux parti­ci­pants, c’est à dire les membres de l’équipe de déve­lop­pe­ment. Il répond aux éven­tuelles ques­tions. Puis chaque parti­ci­pant – en dehors du Product Owner  - choi­sit la valeur qui lui semble corres­pondre à la complexité de la solu­tion à mettre en oeuvre. On consi­dère que la complexité est direc­te­ment liée à la charge de travail. Pour y parve­nir, il va compa­rer cette complexité à un élément étalon auquel on a attri­bué au préa­lable une valeur arbi­trai­re­ment. Et plus il y a d’élé­ments esti­més, plus l’équipe dispose d’élé­ments de compa­rai­son pour fiabi­li­ser les esti­ma­tions.

Une fois que chaque parti­ci­pant a choisi sa carte, et il ne peut choi­sir qu’une seule carte, tout le monde retourne sa carte en même temps afin de ne pas influen­cer les autres. On constate souvent des écarts entre les diffé­rents membres, et c’est bien l’in­té­rêt du Plan­ning Poker en matière de prise de recul mutuelle au sein de l’équipe. On invite alors les personnes ayant les esti­ma­tions les plus éloi­gnées à expliquer leur esti­ma­tion. Puis on procède à un nouveau tour d’es­ti­ma­tion jusqu’à conver­ger.

Le nombre limité de cartes et les écarts entre les valeurs, permet d’ac­cé­lé­rer l’es­ti­ma­tion. La prise de recul mutuelle permet quant à elle d’évi­ter de trop grosses erreurs d’es­ti­ma­tion. 

Enfin, tout se base sur le constat qu’une esti­ma­tion, n’est qu’une esti­ma­tion, et qu’elle est donc fausse par défi­ni­tion. Elle permet simple­ment d’en­ga­ger un budget appro­prié, mais surtout d’ai­der le Product Owner à ordon­nan­cer son Product Back­log et à plani­fier les versions du produit à bon escient.

Quand esti­mer ?

Au démar­rage d’un projet, on passe pas mal de temps à faire l’es­ti­ma­tion de chaque élément du Product Back­log, jusqu’à esti­mer l’in­té­gra­lité du Product Back­log initial. Une fois qu’on a la somme totale, on peut commen­cer à é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éfi­nir, à peu près, le nombre de sprints qu’on pense néces­saires pour abou­tir à la livrai­son d’une première version du produit.

Puis en cours de projet, l’équipe Scrum sera régu­liè­re­ment amenée à esti­mer de nouveaux éléments candi­dats à inté­grer le Product Back­log. De nouvelles idées par exemple. Ou à décou­per, voire ré-esti­mer des éléments trop gros.

Synthèse des avan­tages

En synthèse, en termes d’avan­tages, le Plan­ning Poker tire parti de l’in­tel­li­gence collec­tive en matière de prise de recul et d’idées sur les moda­li­tés de réali­sa­tion. Le Product Owner peut parta­ger sa vision du produit à cette occa­sion avec l’équipe qui le réalise. Il béné­fi­cie égale­ment d’une trans­pa­rence abso­lue sur les esti­ma­tions et peut même ajus­ter son besoin en séance pour arri­ver à un “coût” de réali­sa­tion opti­mal par rapport à la valeur asso­ciée à son besoin. L’équipe de déve­lop­pe­ment quant à elle a la possi­bi­lité de poser ses ques­tions direc­te­ment, plutôt que de partir unique­ment d’un cahier des charges papier. Enfin, une fois la tech­nique rodée, les esti­ma­tions sont rapides grâce au recours à la suite de Fibo­nacci et au prin­cipe d’es­ti­ma­tion par rela­ti­vité. 

Inscri­vez-vous à la prochaine session du MOOC Gestion de projet agile avec scrum