L'estimation de la taille des User Stories est une activité récurrente pour les équipes Agile. L'atelier le plus commun pour réaliser ce travail est le Planning Poker. Dans cet article, j'explique le pourquoi de ce format, la manière dont il se déroule et les principales situations que vous pouvez rencontrer.


Le Planning Poker est une activité d’estimation de la taille des User Stories. Elle se déroule bien sûr avec l’équipe. Il est important qu’elle soit timeboxée.

Quand réaliser un Planning Poker ?

Cette activité peut être organisée au sein d’un Backlog Refinement, d’un Sprint Planning mais elle peut aussi avoir lieu n’importe quand, dès que l’équipe a besoin d’estimer la taille d’une User Story.

Pourquoi choisir le format du Planning Poker ?

Le fait de faire cette activité apporte plusieurs avantages :

  • un effet sagesse du groupe,
  • une meilleure précision par l’apport mutuel d’expériences,
  • une précision sur ce qui est inclus dans la User Story et ce qui ne l’est pas,
  • un partage des informations par tous les membres de l’équipe de développement.

La préparation du Planning Poker

Pour mener cette activité, vous aurez besoin d’un jeu de cartes. Vous pouvez en acheter un sur Internet ou télécharger des cartes prêtes à être imprimées sur Internet. Vous devez fournir un jeu de cartes par membre d’équipe.

Pour les cartes, il y a deux variantes :

  • l’utilisation de tailles de T-shirt (XS, S, M, L, XL),
  • l’utilisation de Story Points, basés sur la suite de Fibonacci, mais modifiée.

L’intérêt de la suite de Fibonacci est de souligner le fait que les différences de taille ne sont pas linéaires. C’est censé refléter le fait par exemple qu’une User Story de taille 8 est à peu près le double d’une User Story de taille 5, mais pas exactement, tout comme le sont les estimations.

Le déroulement d'une session de Planning Poker

Voyons maintenant comment se déroule une session de Planning Poker.

Distribuer un jeu de carte à chaque membre de l’équipe de développement.

Prendre la première User Story du Product Backlog.

La lire à haute voix, l’expliquer et décrire les critères d’acceptance.

Placer la User Story sur la table.

Demander aux participants s’ils ont assez d’informations pour estimer sa taille.

Chaque participant choisit une carte et la place face contre la table afin d’éviter le « biais de conformité », qui consiste à s’influencer mutuellement. Cacher la carte que l’on choisis est vraiment un point très important. Cela permet de mettre en lumière les différences de choix, qui peuvent s’expliquer par le fait que certains membres de l’équipe peuvent ne pas avoir pensé à certains aspects de la User Story. Le biais de conformité empêcherait de détecter ces critères oubliés.

Une fois que tous les participants ont choisi une carte, le Scrum Master décompte de 3 à 1. A 1, les participants retournent leurs cartes pour montrer la valeur qu’ils ont choisie.

  • Si tous les participants choisissent la même taille, alors cette valeur devient la taille de la User Story.
  • Si les tailles sont proches les unes des autres, alors vous pouvez retenir la valeur la plus élevée au titre de la marge d’erreur.
  • Si par contre il y a un écart important, demander aux participants qui ont choisi la ou les valeurs extrêmes d’expliquer les raisons de son choix. Faire alors réestimer la taille de cette User Story.
  • Si au bout de trois tentatives, aucun consensus ne peut être trouvé, le Product Owner peut proposer d’affiner cette User Story, pour être soumise à nouveau au Planning Poker plus tard.
  • Si malgré cette affinage le problème persiste, la solution peut être d’introduire la notion de Spike User Story.

Inscrire la taille de la User Story sur la carte.

La mettre de côté.

Passer à la User Story suivante et resuivre le process.

Les Epic User Stories

Une fois que nous avons étudié la manière dont se passe l’estimation de la taille des User Stories se pose la question de connaître sa fréquence. La question liée est de déterminer le niveau de détail idéal du Backlog. Pour cela, lisez mon article sur la règle du 20/30/50 du Product Backlog.

Si aucun consensus ne peut être atteint sur une User Story, alors vous devez peut-être la considérer comme un Spike. Un Spike est une User Story dans laquelle l’incertitude ne peut pas être levée par l’équipe. On parle bien entendu d’un niveau d’incertitude très élevé, pas un simple flou. Pour lever cette incertitude, l’équipe doit investiguer, récolter plus d’informations aussi bien techniques que business. Cette tâche d’investigation fait l’objet d’une User Story à part entière, que l’on appellera une Spike User Story. Ce type d’activité doit être timeboxé. Si le temps imparti était insuffisant pour obtenir les informations nécessaires, il est nécessaire de négocier un délai supplémentaire avec le Product Owner et l’équipe.


Il ne vous reste plus qu'à mettre en pratique le Planning Poker. Les premières mises en application nécessitent bien sûr pas mal d'explications, mais l'équipe de développement se rode rapidement à cette méthode, qui est plutôt ludique.


Pensées pour mieux produire

Soyez prévenu dès que mon livre "Pensées pour mieux produire" sera disponible à la vente !

DevOps, Agile, Scrum, Kanban, XP, SAFe, LeSS, Lean Startup, Lean UX, Design Thinking, Craftmanship, Management 3.0, ...

 

Bruno Delb

Agile Coach and DevOps, with an experience in the Medical Device software domain, Management 3.0, Agile games and development (especially on mobile) are my passion.

Search

Ads