Le bon moment pour le Planning Poker
Le Planning Poker est une méthode d'estimation basée sur le consensus. C'est pourquoi je recommande de l'utiliser pour les éléments qui nécessitent un consensus – donc plutôt pour les Product Backlog Items que pour les tâches d'un Sprint Backlog. Dans cet article, je reviens sur le Planning Poker et j'explique quand il convient de le pratiquer.
Raisons d'estimer les User Stories
L'estimation des User Stories dans un Product Backlog a deux raisons :
1.) Le Product Backlog peut être priorisé. Imagine deux Product Backlog Items que le Product Owner considère comme équivalents. L'item avec le coût le plus bas sera alors traité en premier. Les évaluations des items dépendent donc de leurs coûts et peuvent ainsi être utilisées pour la priorisation.
2.) L'entreprise peut faire des prévisions à plus long terme. L'ampleur du travail doit être connue pour que le Product Owner puisse dire quand et combien pourra être livré.
Quand devrait-on jouer au Planning Poker ?
À l'aide des points mentionnés ci-dessus, on peut déterminer quand une équipe devrait faire des estimations. Cela devrait se faire suffisamment tôt pour que ces deux conditions puissent être remplies. En revanche, cela ne devrait pas se faire plus tôt que strictement nécessaire.
En pratique, il y a deux situations dans lesquelles une équipe devrait jouer au Planning Poker.
Un bon moment pour le Planning Poker est par exemple après un atelier d'écriture de stories, au cours duquel de nombreux Product Backlog Items ont été créés. Ces ateliers devraient être organisés environ une fois par trimestre.
Ainsi, le Product Owner et l'équipe peuvent définir un objectif plus large (qu'on ne peut pas atteindre en un seul sprint) et créer les User Stories nécessaires pour l'atteindre.
En général, un atelier d'écriture de stories trimestriel génère entre 20 et 50 Product Backlog Items. Si on peut estimer environ 20 items par heure, l'estimation prend au total peut-être deux heures par trimestre.
Par ailleurs, le Planning Poker peut aussi être réalisé une fois par sprint. Certaines équipes le font pendant la réunion régulière de Product Backlog Grooming. C'est tout à fait acceptable – tant que tous les membres de l'équipe y participent.
Si tous les membres de l'équipe ne sont pas impliqués, on peut aussi organiser le Planning Poker après un Daily Standup vers la fin d'un sprint. Si une équipe fait ses estimations trop tôt pendant un sprint, il se peut qu'on doive tout recommencer pour des stories ajoutées ultérieurement.
Mais l'estimation ne devrait pas non plus avoir lieu trop tard. Sinon, le Product Owner ne pourra pas prendre en compte ces items lors de la définition des éléments pour le prochain sprint.
Quand ne devrait-on pas jouer au Planning Poker ?
Il y a un moment qui n'est pas favorable au Planning Poker : au début d'un Sprint Planning Meeting. À ce stade, il est en effet trop tard pour que le Product Owner puisse s'orienter sur les nouvelles estimations pour définir ses priorités.
Il existe peut-être des Product Owners capables de réorganiser les priorités en très peu de temps. Mais avoir plus de temps, c'est toujours mieux.
Un autre problème est qu'une équipe passe presque toujours trop de temps à estimer lorsqu'un Sprint Planning commence par du Planning Poker. Je pense que c'est parce que les membres de l'équipe commencent alors à réfléchir directement aux détails de leurs User Stories.
Or, lors du Planning Poker, ils devraient en fait donner une estimation moins détaillée de leurs User Stories. Il est difficile de fournir une estimation aussi grossière dans une réunion où l'on est censé évaluer les Tasks de manière beaucoup plus précise.
Cela entraîne des discussions inutilement nombreuses. Et cela conduit à ce que l'équipe mette beaucoup plus de temps que si les deux activités étaient menées séparément.
Avec ces lignes directrices, tu devrais être en mesure de trouver le bon moment pour le Planning Poker.
Ce texte provient du blog de Mike Cohn et a été traduit par nos soins.
