Planning poker

Le planning poker est une façon ludique de produire des estimations sur l'effort de développement de fonctionnalités. Cette pratique est surtout utilisée en informatique, en eXtreme Programming (XP), en Scrum et dans les méthodes agiles en général pour évaluer les scénarios utilisateurs (user stories) du carnet de produit (product backlog). La méthode a été décrite pour la première fois par James Grenning[1],[2] en 2002 et popularisée par Mike Cohn dans le livre Agile Estimating and Planning[3].

Utilisation

L'avantage principal du planning poker est de permettre à tous de s'exprimer librement. L'estimation serait meilleure parce que plusieurs personnes l'auront validée[4] : des participants avec des niveaux d'expérience et d'expertise différents. De plus, cette technique favorise les échanges entre le responsable de produits et l'équipe de développement.

L'estimation se fait en unités d'œuvre intitulées points de récits ou "journées idéales" (Ideal Day).

Les points de récits permettent d'obtenir une véritable mesure relative de l'effort : les scénarios sont comparés entre eux. L'équivalent en jours-hommes est propre à chacun, selon ses compétences, son expérience et sa connaissance du domaine. L'avantage d'utiliser des points réside surtout dans le fait que l'échelle utilisée restera stable tout au long du projet. Peu importe la vitesse (vélocité) à laquelle l'équipe de développement accomplira ces tâches, nul besoin de réviser les estimations : c'est le rapport entre le temps réel et les points qui évoluera.

Les avantages de l'estimation en "journées idéales" (ou heures idéale en cas de fine granularité des tâches) sont parfaitement identiques à ceux des points de récits. Par contre, l'estimation en journées idéales est plus aisée à concrétiser dans l'esprit des acteurs qui sont généralement plus à l'aise avec la notion de "journée" qu'avec un "point de récit" de taille variable pour chaque projet, qui peut aussi bien représenter quelques heures que quelques jours, et qui devra devenir une unité de référence.

La suite de Fibonacci est utilisée pour les évaluations. Comme nous cherchons un dimensionnement de l'effort, le message est clair : plus le scénario est gros, moins l'évaluation est précise. Le paquet de cartes utilisé pour le planning poker doit donc comporter les valeurs suivantes : 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144. Certains simplifient les grandes valeurs en les transformant en 20, 40, 100... puisqu'il s'agit d'être globalement bon plutôt que précisément erroné. On y ajoute généralement les valeurs 0 et 1/2.

S'agissant d'une estimation relative collaborative, il est préconisé de commencer par un atelier de définition du fini afin que chacun des acteurs se réfère à une définition partagée (et affichée) lorsqu'il estime l'effort de développement d'un scénario. Il est également préconisé de se mettre d'accord sur un scénario de référence, traditionnellement équivalent à la valeur 1 (ou 2).

Déroulement
  1. Les participants s'installent autour d'une table, placés de façon que tout le monde puisse se voir.
  2. Le responsable de produit explique à l'équipe un scénario utilisateur (user story).
  3. Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de le considérer comme "terminé".
  4. Chacun des participants évalue l'effort de développement de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table devant lui.
  5. Au signal du facilitateur, les cartes sont retournées en même temps.
  6. S'il n'y a pas unanimité, la discussion reprend.
  7. On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.

Une procédure optimisée consiste, après la première "donne", à demander aux deux acteurs ayant produit les évaluations extrêmes d'expliquer leurs points de vue respectifs. Ces explications achevées et comprises de tous, une nouvelle estimation est produite et c'est alors la moyenne arithmétique de ces estimations qui est prise en compte.

Références
  1. « Wingman Software | Planning Poker - The Original Paper », sur wingman-sw.com (consulté le )
  2. « Planning Poker ou Comment éviter la paralysie lors de la planification de version », sur wikiagile.cesi.fr (consulté le )
  3. (en) Mike Cohn, « Agile Estimating and Planning », Mountain Goat Software, (consulté le )
  4. (en) Bryan L. Bonner, Sheli D. Sillito et Michael R. Baumann, « Collective estimation: Accuracy, expertise, and extroversion as sources of intra-group influence », Organizational Behavior and Human Decision Processes, vol. 103, no 1,‎ , p. 121–133 (ISSN 0749-5978, lire en ligne, consulté le )
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.