La face cachée du planning poker

      Commentaires fermés sur La face cachée du planning poker

_DSC3700Banalités…

De nombreux ouvrages, articles et retours d’expériences nous apprennent comment mener une réunion d’évaluation du product backlog.  Il est assez simple de comprendre les différentes étapes qui rythme ce jeu d’évaluation : la présentation de la user story, l’évaluation par les membres de l’équipe, le débat et enfin le consensus. Si l’on fait un parallèle avec le poker, au début de chaque tour, les montants des blindes sont déterminés et ils sont explicites.  5€ ou 10€ a la même valeur pour chacun des participants.  Il n’existe aucune ambiguïté. Pour le planning poker, c’est la même chose, il faut pouvoir donner aux participants un jalon identique qui ne permet aucune ambiguïté.  Si l’équipe est composée de membres seniors et juniors, ils n’auront pas la même perception de la complexité d’une user story.  Le même problème de perception apparaît entre un senior avec plusieurs années d’expériences dans l’équipe et un senior fraichement arrivé dans l’équipe. La question qui se pose est : Comment trouver un jalon ou comment définir une monnaie unique? Dans un premier temps, il s’agit ici de pouvoir choisir une échelle de mesure et de déterminer un jalon par rapport à cette échelle.

Observons les différentes échelles les plus utilisées :

  • La suite de Fibionacci (modifiée): la plus connue, elle est généralement utilisée pour les jeux de cartes que l’on trouve sur le marché : 1, 2, 3, 5, 8, 13, 20, 40, 100, ?
  • Une séquence de nombre.  Ex. : 1, 2, 4,  8, 16, 32, 64.
  • Une séquence de “taille de polo” : XS, S, M, L, XL, XXL

La suite choisie n’a pas d’importance, seule le résultat est important… Ce qu’il faut garder à l’esprit est de toujours utiliser la même échelle lors de chaque réunion d’évaluation.  Cette échelle va permettre d’obtenir un backlog produit uniforme mais aussi de calculer la vélocité de l’équipe de façon constante.

L’échelle choisie, définissez le jalon de référence :

Choisissez une user story qui doit répondre à quelque critères:

  • elle doit être connue de chacun des membres de l’équipe,
  • elle doit avoir été réalisée, testée et déployée (son périmètre est connu),
  • elle doit être de taille moyenne, ni trop petite ni trop grosse,
  • si elle n’avait pas déjà été réalisée, elle devrait pouvoir être réalisée sans problème par chacun des membres de l’équipe,

Relisez la description technique, le découpage en tâche si il est toujours disponible ou établissez une analyse d’impact (mindmap, schéma relationnel, diagramme de flux, …).  Tout ce qui peut vous permettre de visualiser le périmètre de votre jalon.  Quand tous les membres en ont prit connaissance, attribuez lui une valeur de milieu d’échelle (5, 8 ou M). Mettez le tout par écrit et afficher le jalon sur votre board afin que les parties prenantes puissent y avoir accès, le lire et comprendre le niveau de complexité des user stories en cours de réalisation. A chaque réunion d’estimation, prenez le temps de relire votre jalon et de vous le remémorez.  Afficher le dans la salle de réunion de planification pour que les membres de l’équipe l’aient sous les yeux.  De même, si vous intégrez un nouveau membre à l’équipe, n’hésitez pas à lui faire une présentation complète du jalon, une démo, la description, l’analyse d’impact et une revue brève du code.  Même si il ne participe pas activement durant sa première réunion d’estimation, il pourra se rendre compte des différents niveaux de complexités des user stories.

Et pour la suite ?

Bien qu’il soit important de conserver le jalon visible, il pourrait être intéressant de sélectionner un échantillon de user stories précédemment « done » afin d’élargir une base de référence. Après quelques sprints, vous posséder un panel étendu de user stores ayant été évaluées et réalisées. Si une nouvelle réunion d’estimation est planifiée, prenez le temps de sélectionner deux ou trois user stories pour chaque nombres de la séquence (1, 2, 3, 5, 8, 13,…). Cet éventail servira comme « jalon étendu». Afficher dans la salle ou se déroulera la séance d’estimation les cartes de user stories en colonnes avec en entête l’estimation.

Durant la séance d’estimation, s’il y a une polémique sur la complexité d’une story, il sera facile de se reporter à cette sélection afin de comparer les différents niveaux de complexité. Une telle pratique ne règle pas tous les conflits, il est parfois nécessaire de renvoyer la story à l’analyse parce qu’elle n’est pas assez explicite. Si le client n’est pas capable de répondre aux questionnements de l’équipe, il aura peut-être envie de diminuer le périmètre ou de splitter la story afin de rendre l’estimation de la story réalisable pour qu’en définitive, elle se retrouve priorisé dans le backlog.

Jalon Pocker