Publié par

Il y a 6 ans -

Temps de lecture 4 minutes

Les bénéfices cachés du planning poker

Quand il s’agit d’adresser la délicate question des estimations, nombre d’équipes agiles utilisent le planning poker. Il fait partie intégrante du cycle de vie d’une équipe pratiquant Scrum, à l’occasion du sprint planning. Parfois même, il est utilisé pour donner une première estimation d’un backlog « complet », bien qu’on puisse lui préférer une autre technique au meilleur rapport temps consacré / disponibilité de l’estimation (la magic estimation). Même dans un système Kanban, il peut être encore utilisé. Bref, la technique semble être devenue classique.

Vous êtes-vous déjà demandé quels sont tous les gains obtenus à l’issue d’un planning poker ?

Bref rappel historique : le planning poker est une pratique issue de XP popularisée par Mike Cohn dans son livre Agile Estimating and Planning. C’est en fait une dérivation de la technique wideband delphi.

Prenons une équipe de développement Scrum. Elle est constituée d’un Product Owner, d’un Scrum Master et des développeurs. Des équipes débutantes dans la méthode posent régulièrement la question : qui sont les participants au planning poker ? La réponse est claire : tout le monde. Même le Product Owner ? Surtout le Product Owner. Même le développeur junior ? Tout le monde !

Comment cela se déroule ? Dans un premier temps, le Product Owner peut donner une vision d’ensemble des quelques User Stories qu’il voudrait voir estimer. Il les présente dans les grandes lignes.

Si ce n’est pas le premier planning poker de cette équipe, le Scrum Master rappelle quelles sont la ou les Stories de référence. Pour rappel, c’est une technique d’estimation par comparaison et les premiers temps il est bon de rappeler quelle est la référence de l’équipe. Avec le temps, cette référence est « acquise » et cela n’est plus nécessaire.

Ensuite, le Product Owner présente en détail la première story et l’équipe peut poser toutes les questions qu’elle souhaite.

Et voilà un premier bénéfice collatéral du planning poker : tenir une discussion autour d’un incrément du backlog. À ce stade, le besoin s’éclaircit. La vision du Product Owner sur une fonctionnalité donnée est partagée avec l’ensemble de l’équipe. On obtient alors un alignement de l’équipe, la compréhension mutuelle du travail à faire. Une fois que tout le monde a bien compris de quoi il s’agissait, le Scrum Master peut alors déclencher le vote des développeurs. Chacun dispose de son jeu de cartes (taille de t-shirt, fibonacci, bref votre échelle d’estimations préférée). Le vote se fait en secret, chacun de son côté. Et les estimations personnelles sont ensuite partagées. Un second gain est alors obtenu : par la nature même de cette approche, la voix de chacun compte. Que ce soit un équipier aguerri ou le plus junior possible, elle participe au processus d’estimation de l’effort, du travail à fournir. L’engagement collectif sera alors plus simple à obtenir.

Si tout le monde propose la même estimation, c’est fini. Si tel n’est pas le cas (souvent ?), la discussion s’engage. Un Scrum Master expérimenté facilite la session en maîtrisant l’ordre des participants. Il faut « sentir » quand il est nécessaire de laisser d’abord la parole aux plus juniors, ou aux personnes peut-être plus introverties, ou encore à l’estimation la plus grosse. Cela peut entraîner un complément de discussion sur le besoin, mais cela sert aussi à confronter les approches d’implémentation de l’US. Et c’est à mon sens un autre bénéfice du planning poker : utilisé à bon escient, c’est un premier pas vers la conception collaborative et émergente. Que faire si le second tour ne permet pas le consensus ? Il y a plusieurs écoles pour adresser ce cas. Certains ont tendance à prendre systématiquement l’estimation la plus grosse, par exemple. Personnellement, j’essaie de ménager l’équilibre entre estimations les plus pessimistes et la plus optimistes : en pratique, une fois l’une une fois l’autre. Quelque soit votre approche, ce ne sont que des estimations de toute manière :-)

Le planning poker est présenté comme une technique d’estimation. C’est vrai, mais en forçant un peu le trait les estimations ne sont qu’un bénéfice secondaire de l’exercice. Estimer via le planning poker permet surtout :

  • d’éclaircir et partager de manière itérative et incrémentale les fonctionnalités du produit que nous développons ;
  • de le faire de manière collaborative et avec un cérémonial qui permet à tous de s’exprimer ;
  • tout en promouvant le design logiciel collaboratif et émergent.

Publié par

Publié par Ludovic Pérot

Ancien ingénieur de développement, j'ai eu l'occasion de travailler en eXtreme Programming et suis de facto très sensible aux bonnes pratiques d'ingénierie logicielle. Depuis 2008, j'ai alternativement assumé les rôles de Product Owner ou de Scrum Master sur différents projets. C'est ce qui me permet maintenant d'accompagner des équipes dans leur transition agile.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.