Le Planning Poker permet à une équipe d’estimer la charge de développement d’une fonctionnalité. Les concepts d’origine se trouvent sur CRISP[1] mais comme j’aime beaucoup les illustrations à base de pingouins de Yannick Quenec'hdu je me suis donc permis de lui offrir cette espace et le référencement en bas de page.

Cas d’une estimation sans carte

L’objectif étant de déterminer le temps de développement d’une fonctionnalité X, vous réunissez l’équipe chargée du travail (de 5 personnes pour l’exemple). Vous posez la question « combien de temps pour développer la fonctionnalité X ? »

Le développeur A évalue le travail à 5 jours alors que B et E ont une estimation beaucoup moins optimiste. Les acteurs C et D pour diverses raisons ne participent pas activement. Bref, c’est A qui annonce en premier « 5 jours ». Cas de figure classique, l’équipe est influencée par la première personne ayant exprimé un avis. Le risque d’erreur devient important, car B et E avaient envisagé cette fonction comme plus complexe et demandant plus de temps de développement.

Note : il est possible d’imaginer qu’une autre personne ait pu penser connaître une solution permettant la réalisation en une seule journée et qu’elle se soit alors abstenue. La déperdition d’informations utiles était alors considérable.

Estimation avec carte

Pour résoudre ces problèmes classiques, vous distribuez à chacun un jeu de cartes prévu à cet effet.

Les cartes sont basées en partie sur la suite de Fibonacci mais quelques cartes méritent une explication :

§  la carte « 0 » représente une fonction qui est déjà implémentée ;

§  la carte « ? » indique que vous n’avez vraiment aucune idée sur la question ;

§  la carte « café » est un joker pour signaler que vous souhaitez faire une pause.

L’unité n’est pas le nombre de jours / homme, mais une unité arbitraire.

Note : personnellement, je conseille d’utiliser une référence compréhensible : l’ « idéal day » qui a l’avantage de permettre de transformer aisément l’estimation Agile en valeurs utilisables dans un outil classique (comme MS Project par exemple), si un reporting standard est imposé par un comité de pilotage.

Première étape du Planning poker

Vous posez la question « combien de temps pour développer la fonctionnalité X ? » et vous donnez, éventuellement, un timing maximum pour la réponse (un sablier est utile dans ce cas).

Dans le cas de fonctionnalités importantes, il peut être possible de demander un complément d’information au « client sur site ».

Lorsque l’ensemble des participants informe qu’il a fixé son estimation, le meneur de jeu demande d’abattre les cartes. Cette fois-ci C et D sont obligés de participer et le résultat du premier vote est alors commenté par l’équipe.

Nous observons alors qu’entre A et C, une discussion s’impose. A la suite de quoi A réalise, par exemple, qu’il a omis de prendre en considération certains éléments et C réalise grâce à A qu’il est possible de réaliser plus simplement qu’il le pensait la fonctionnalité en question.

Seconde étape du Planning poker

Après avoir débattu, toute l’équipe refait une estimation.

A ce point, un consensus est généralement obtenu.

Dans de nombreux cas, les estimations convergent au second tour.

Sinon, le processus peut être répété ou bien l’on procède à une moyenne arithmétique des évaluations.

Une estimation ne nécessite pas une précision absolue, mais raisonnable.

Note : j’ai encore récemment initié des estimations en Planning poker game dans plusieurs grands comptes, dont des groupes du CAC40. Je peux vous assurer que non seulement cela fonctionne dès la barrière du changement franchie, mais qu’en plus les participants apprécient la responsabilité qui leur est confiée et se sentent engagés par leur estimation.

Autres formes d’estimations