Le Scrum Planning poker (également appelé poker planning ou Scrum poker) est une technique aide les équipes agiles à estimer le temps et l’effort nécessaires pour réaliser chaque initiative présente dans leur backlog produit. Le nom du planning poker vient du fait que les participants utilisent des cartes physiques. Ces cartes, qui ressemblent à des cartes à jouer, permettent d’estimer le nombre de story points associé à chaque user story ou tâche à discuter. Voici dans cet article tout ce qu’il y a à savoir sur le Scrum Planning Poler en Product Management, de son fonctionnement à ses avantages mais aussi ses inconvénients.
Sommaire
Histoire et définition du Planning Poker
Le Planning Poker est un processus gamifié qui vise à aider les équipes produit à estimer plus précisément les échéances de développement, à favoriser le consensus parmi les membres de l’équipe cross-fonctionnelle, et à planifier de manière plus stratégique le travail de l’équipe.
Selon un article rédigé pour la Sacramento State University, l’histoire du planning poker est liée au développement d’une autre technique d’estimation appelée Wideband Delphi ou méthode DELPHI, développée par la RAND Corporation au milieu du XXe siècle.
L’entrepreneur James Grenning a par la suite affiné cette méthode dans les années 2000 la renommant Planning Poker et l’adaptant aux équipes agiles et au product management.
Enfin, en 2005, Mike Cohn de Mountain Goat Software a largement popularisé le planning poker dans son livre « Agile Estimating and Planning ».
Comment fonctionne le Planning Poker ?
Le planning poker rassemble des parties prenantes issues de différents départements de l’organisation dans le but de parvenir à un consensus sur l’effort nécessaire pour plusieurs initiatives du backlog. Pour une organisation agile de développement logiciel, les participants peuvent inclure un product owner, des développeurs, des UX designers, des QA testers et des product managers, entre autres.
Voici comment se déroule une session de planning poker :
1- On distribue les cartes
Chaque participant reçoit un deck de cartes (ou chips) identique, chacune portant un nombre différent. Une séquence courante est basée sur une progression par doublement : 1, 2, 4, 8, 16, 32, 64. La séquence recommandée par Mike Cohn de Mountain Goat Software, qui a popularisé le planning poker pour les équipes agiles, est : 0, 1, 2, 3, 5, 8, 13, 20, 40 et 100.
Ces decks sont délibérément limités, avec des sauts numériques significatifs, car l’objectif est que tous les participants parviennent à un consensus sur un nombre pour chaque story. Offrir trop d’options – par exemple, chaque nombre de 1 à 50 – rendrait le processus inefficace.
2- On lit les stories
Le product owner (ou dans certains cas le product manager) lit chaque histoire à haute voix pour l’ensemble du groupe.
3- On discute
Une fois que tout le monde a entendu l’histoire, le groupe engage une discussion. Les participants décrivent leur vision pour traiter le travail, estiment le nombre de personnes qui seraient impliquées, identifient les compétences requises et évoquent les obstacles potentiels pouvant ralentir la progression. C’est également l’occasion de poser des questions sur l’histoire.
4- On estime et on partage
Après que chacun ait pris la parole et que les questions ont trouvé des réponses, chaque participant choisit secrètement une carte dans son deck pour représenter son estimation en story points. Lorsque tout le monde est prêt, tous révèlent leurs cartes simultanément.
Plus la valeur sur la carte d’un participant est élevée, plus il estime que la réalisation de l’histoire sera difficile.
5- On arrive à un concensus
Si tous les participants révèlent la même carte, ce nombre devient le consensus et le groupe peut passer à l’histoire suivante.
En revanche, si les cartes divergent, le groupe poursuit la discussion sur l’histoire. Ceux qui ont donné des estimations supérieures (ou inférieures) expliquent leur raisonnement et tentent de convaincre leurs collègues afin que tous se rapprochent d’une vision commune.
Après cette nouvelle discussion, chacun révise sa carte en gardant son choix précédent ou en en sélectionnant une nouvelle. Ensuite, tous révèlent à nouveau leurs cartes simultanément.
Quels sont les avantages et inconvénients du Planning Poker en Product Management ?
Pour les équipes agiles, le planning poker est une excellente ressource pour prioriser les éléments de votre roadmap agile.
Les avantages du planning Poker
Voici les avanatges que je peux voir dans l’utilisation du Planning Poker dans les équipes produit :
- Le format ludique favorise la collaboration et le team building.
- Exiger un consensus parmi tous les membres de l’équipe, plutôt que de confier l’estimation à une seule personne, peut renforcer le moral en donnant à chacun son mot à dire.
- Le format conversationnel permet de faire émerger des insights précieux de la part de membres de l’équipe qui, autrement, n’auraient peut-être pas trouvé d’opportunité pour partager leurs réflexions et expériences.
Les Inconvénients du planning Poker
A l’inverse, voici les pièges à éviter lors de cette session :
- Parvenir à un consensus peut parfois donner à l’équipe une fausse impression de certitude. Il se peut qu’elle ait encore des informations manquantes, et que l’estimation soit donc inexacte.
- Une personne dominante dans le groupe peut influencer indûment les autres participants. Si l’on n’y prend garde, cela peut conduire à des estimations obtenues non par échange collectif, mais par force de persuasion
| Avantages | Inconvénients |
|---|---|
| Renforce la collaboration et l’esprit d’équipe | Peut donner une illusion de précision si des infos manquent |
| Implique tout le monde dans l’estimation | Risque d’influence par des personnalités dominantes |
| Fait émerger des idées et points de vue variés | — |
Qui devrait utiliser le Planning Poker ?
Le planning poker peut être une technique d’estimation utile pour toute équipe dans n’importe quelle organisation. Toutefois, cette approche fonctionne particulièrement bien pour les petites entreprises et les équipes de taille réduite. Dans les grandes organisations, qui disposent de groupes plus importants, le nombre élevé de participants peut allonger la durée nécessaire pour atteindre un consensus sur chaque item.
