Planning poker Scrum
Introduction
La véritable question lorsque l’on se lance dans la programmation est « comment réaliser des estimations fiables lorsqu’on ne possède aucun historique ou quand le scénario s’avère des plus compliqués ? ».
En 2002, James Grenning et Mike Cohn, deux des fondateurs du Manifeste Agile, créent une nouvelle méthode d’estimation qu’ils appelleront « Planning Poker ». Vous pouvez retravailler l’ensemble des détails de cette technique dans le livre de Mike : Agile estimating and planning. Hormis l’utilisation de carte lors des estimations en équipe, le Poker n’a rien à voir avec cette méthode.
Le but des cartes ? Ne pas subir l’influence de ses collègues puisque, comme à la bataille, chacun abat sa carte en même temps sur la table et laisse apparaître son estimation.
Le déroulement
Que cherche-t-on à estimer ?
Comme dans tous les projets, qu’ils soient informatiques ou non, l’estimation des coûts de réalisation d’une action sont souvent compliqués à planifier. Et bien, pour les développeurs, c’est comme pour le reste, il faut s’appuyer sur l’expérience personnelles ainsi qu’avoir une connaissance approfondie du client et du projet sur lequel nous sommes amenés à travailler.
Et, comme d’habitude, les méthodes Agiles viennent nous sauver la mise et notamment Scrum qui va apporter un outil nécessaire à la bonne planification et estimation de ces charges : le planning poker scrum.
Que représente les cartes ?
Chaque carte possède une valeur distincte permettant d’assurer une estimation la plus précise possible. Il est nécessaire de préciser qu’on distingue aujourd’hui de types d’estimation : les « points de récits » et les « journées idéales*« .
- La carte interrogation est utilisée pour définir l’incertitude quant à la durée de développement d’une implémentation.
- La carte infinie décrit une tâche n’ayant pas de fin déterminée ou difficile à accomplir : optimisation, découverte.
- La carte café, comme l’image l’indique, est une carte à utiliser en cas de nécessité d’une pause pour l’équipe. Tout simplement.
- La carte 0 est la base des cartes numériques. Ici, elle représente une tâche possédant un rapport complexité / durée nul ou presque.
Tandis que la simulation évolue, la valeur des cartes augmente parallèlement et et donc l’écart avec la carte de l’échelon supérieur évolue d’autant.
*
Une journée idéale correspond à une journée durant laquelle le ou les développeurs ne sont dérangés par aucun facteur extérieur (bruits, incendie, collègues, etc.).
Poker menteur ? Non. Poker bavard !
Le principe même du planning poker scrum est de mettre en place des axes de communication autour des estimations de chacun. En ce sens, un Poker Master est désigné lors de la première phase. Ce dernier aura un rôle de médiateur et de facilitateur de dialogue. Il doit aussi s’assurer que tout le monde soit aux uses de cette technique et des informations qui ressortent de chaque partie.
Cependant, c’est le PO (product owner) qui décide quelles fonctionnalités doivent être considérés comme prioritaires et devront être la cible des prochains sprints. Cette technique lui permettra de déterminer les fonctionnalités à mettre en avant lors des sprints en cas d’un coût trop élevé ; elle doit donc être réalisée en amont des sprints.
⚠️
Le planning poker Scrum ne sert en aucun cas à définir un calendrier mais à déterminer quelles fonctionnalités doivent être traitées prioritairement.
Les jeux sont faits, rien ne va plus …
La règle du jeu de carte est des plus simples. Chacun des acteurs possède la même suite de cartes. Toutes les valeurs inscrites sur ces dernières proviennent de la suite de Fibonacci soit 0, ½, 1, 2, 3, 5, 8 jusqu’à 100. Chacune des unités est nominée « point » ou « story point ». La question qui se pose donc ici est de savoir comment déterminer le taux d’effort qui sera quémandé.
Celui-ci est illustré par les stories-point qui sont en fait des points d’efforts. Tout simplement. L’approche par les stories point facilite la prévision des risques et permet avant tout d’instaurer un climat de confiance entre les développeurs par le partage d’information.
Croupier, à vous de jouer !
La première personne à prendre la parole est le Product Owner (PO). Il va présenter un élément du Product Backlog aux autres parties prenantes (les membres de l’équipe de dev). Avant toute chose, un tour de question doit être organisé afin de ne pas s’éparpiller lors de l’estimation des tâches.
La deuxième phase est plus concrète puisque chacun – sauf le PO – pique une valeur dans son jeu qui lui semble correspondre à la difficulté* de la solution à implémenter et la pose sur la table. Un repère de complexité aura été au préalable définit afin que chacun puisse visualiser au mieux l’échelle de difficulté sur laquelle placer sa valeur.
*
La difficulté correspond ici à l’effort demandé au développeur. Elle comprend donc à la fois la complexité de la tâche, le temps à allouer à cette dernière et tous les facteurs pouvant ralentir le travail du génie informatique.
⚠️
Une seule carte doit être choisie.
La troisième phase pourrait s’intituler « prise de recul » puisqu’elle implique que les personnes ayant les valeurs les plus éloignées exprime le pourquoi de leur choix. Ensuite, des tours de carte sont effectués jusqu’à ce qu’un point de convergence apparaisse.
⚠️
Une estimation reste une estimation. Elle doit être considérée comme fausse afin de pouvoir la valider le moment venu.
Quand est-ce que la partie commence ?
L’estimation doit se faire au démarrage d’un projet puisque c’est une méthode qui prend tout de même du temps : il faut faire une estimation individuelle pour chacun des éléments du Product Backlog.
L’équipe Scrum doit être poussée à estimer les nouveaux éléments potentiellement intéressant pour intégration dans le Product Backlog. Bref, des modifications sont à prévoir et le planning poker n’est en aucun cas une méthode infaillible.
L’As dans la manche
Listons les avantages non négligeables du planning poker Scrum
- Fonctionnement en équipe permettant une valorisation des idées et l’émergence de nouvelle méthodes de travail et surtout rendant le plus fiable possible l’estimation finale.
- Le Product Owner fait partie intégrante de l’équipe et possède une transparence absolue sur l’avancée du projet et ses composantes.
- Élaboration d’une relation de confiance par le rapport d’équivalence des complexité de tâches.