Qu’est-ce que le Planning Poker ?
Le Planning Poker (ou Scrum Poker) est une méthode d’estimation de la charge associée à l’implémentation d’une User Story ou d’une Epic. Cette méthode est généralement utilisée lors des sessions de Backlog Refinement (ou de Backlog Grooming), en préparation de la session de Sprint Planning, afin de dimensionner les éléments du backlog et d’éventuellement affiner les User Stories, c’est-à-dire, les redécouper.
Les estimations sont généralement données en Story Points, et non en jour-homme, afin de s’efforcer à estimer de façon relative la charge de travail des différents éléments du backlog. Vous pouvez vous appuyer sur l’acronyme CURSE pour définir les paramètres le Story Point doit agréger :
- La complexité (Complexity) englobe la difficulté technique propre de la User Story ainsi que son intrication avec d’autres composants du système ;
- L’incertitude (Uncertaintiy) reflète l’éventuel manque d’information ou d’assurance concernant la technologie ou l’impact sur d’autres composants du système ou l’architecture en elle-même ;
- Le risque (Risk) associé au changement apporté par l’évolution fonctionnelle ou technique, que ce soit sur le système, le design ou l’architecture ;
- Le périmètre (Scope) des composants susceptibles d’être impactés par l’évolution fonctionnelle ou technique ;
- L’effort (Effort) représente la quantité de travail effective qu’il est nécessaire d’accomplir pour implémenter l’évolution fonctionnelle ou technique.
Les cartes utilisées reprennent généralement les nombres de la suite de Fibonacci : 1, 2, 3, 5, 8, 13, etc. Le fait d’utiliser une suite ayant une progression non linéaire participe au caractère relatif de l’estimation.
L’utilisation des Story Points permet d’introduire le concept de vélocité, qui est le nombre cumulé de Story Points qu’une équipe est capable de réaliser en moyenne sur un sprint.
Animer une session de Planning Poker sur Draft.io
Organisation de la séance de Planning Poker
L’atelier de Planning Poker est communément animé par le Scrum Master. Le Product Owner, lui, a la responsabilité de décrire chaque User Story sur le plan fonctionnel, en prenant le soin de préciser les besoins métier et les contraintes ; les éléments techniques ne doivent pas être abordés.
Seuls les membres de l’équipe de développement doivent prendre part au vote ; le Scrum Master et le Product Owner ne doivent donc pas y participer. En cas de doute sur la compréhension du périmètre de la User Story, les membres de l’équipe de développement sont invités à demander des précisions au Product Owner.
Premier round d’estimation
Une fois la User Story présentée, le Scrum Master active le mode isoloir et invite les membres de l’équipe de développement à écrire leur estimation sur un sticky. Quand le mode isoloir est activé, le contenu des objets nouvellement créés n’est pas visible des autres participants.
Une fois que tous les participants ont indiqué leur estimation, le Scrum Master désactive le mode isoloir et révèle le contenu des stickies. Toutes les estimations des membres de l’équipe apparaissent alors en même temps.
Les différents scénarios en fonction des résultats de l’estimation
En fonction des résultats, plusieurs scénarios peuvent se présenter.
Scénario 1 : Consensus parfait
Tous les participants ont noté la même estimation. Le Scrum Master valide alors le Story Point estimé et l’indique sur la User Story correspondante.
Scénario 2 : Consensus satisfaisant
Les participants ont indiqué des estimations différentes, mais proches, c’est-à-dire avec 1 seul rang d’écart entre la plus basse et la plus haute des estimations. Le Scrum Master conserve alors la valeur de Story Point la plus élevée.
Scénario 3 : Absence de consensus
Deux rangs séparent la plus basse et la plus haute des estimations. Le Scrum Master invite le participant ayant mis l’estimation la plus basse et celui ayant mis l’estimation la plus haute à partager leur point de vue. L’échange doit être bref et limité à 1 minute maximum.
Une fois l’échange terminé, le Scrum Master relance un round de Planning Poker afin de recueillir l’estimation des membres de l’équipe de développement, à la lumière des arguments qui ont été présentés.
A l’issue du 2ème round d’estimation, vous devez normalement vous trouvez dans le scénario 1 ou 2. Si ce n’est pas le cas, répétez l’exercice du scénario 3 jusqu’à parvenir à un consensus parfait ou satisfaisant.
Validation de l’estimation ou affinage de la User Story
Si la User Story possède une estimation acceptable, généralement inférieure ou égale à 8, la User Story est validée et considérée prête à être ajoutée au prochain Sprint Planning.
Dans le cas où le consensus mène à une estimation supérieure à 8, cela peut signifier que la User Story doit être découpée en deux ou plusieurs User Stories plus petites.
