Banalités…

De nombreux ouvrages, articles et retours d’expérience nous éclairent sur la conduite d’une réunion d’évaluation du product backlog. Les différentes étapes de ce processus sont bien connues : la présentation de la user story, l’évaluation par les membres de l’équipe, le débat et enfin l’atteinte d’un consensus. En comparaison avec le poker, où les montants des blindes sont déterminés explicitement en début de chaque tour (5€ ou 10€ ont la même valeur pour tous les joueurs, sans ambiguïté), le planning poker exige une approche similaire, avec un jalon commun qui évite toute confusion. Cependant, la perception de la complexité d’une user story peut varier, notamment entre les membres juniors et seniors de l’équipe, ainsi qu’entre les seniors expérimentés et ceux récemment intégrés. La question clé qui se pose alors est : Comment établir un jalon ou une unité de mesure uniforme ? Pour y répondre, il est primordial de choisir une échelle de mesure appropriée et de déterminer un jalon en fonction de 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 répond aux critères suivants :

• Elle est connue de tous les membres de l’équipe.
• Elle a été réalisée, testée et déployée, donc son périmètre est bien défini.
• Sa taille est moyenne, ni trop petite ni trop grande.
• Si elle n’avait pas déjà été réalisée, chaque membre de l’équipe pourrait la réaliser sans difficulté.

Une fois sélectionnée, relisez la description technique de la user story et examinez son découpage en tâches, s’il est disponible. Sinon, établissez une analyse d’impact, que ce soit sous forme de mindmap, de schéma relationnel ou de diagramme de flux. Tout moyen visuel permettant de visualiser clairement le périmètre de la user story est utile. Une fois que tous les membres de l’équipe ont pris connaissance de ces informations, attribuez à la user story une valeur de milieu d’échelle (5, 8 ou M). Mettez toutes ces données par écrit et affichez le jalon sur votre tableau pour que toutes les parties prenantes y aient accès et puissent comprendre le niveau de complexité de la user story en cours de réalisation.

Lors de chaque réunion d’estimation, prenez le temps de relire le jalon et de vous en remémorer les détails. Affichez-le également dans la salle de réunion de planification pour que tous les membres de l’équipe l’aient sous les yeux. De plus, si un nouveau membre rejoint l’équipe, prenez le temps de lui faire une présentation complète de la user story, incluant une démo, la description, l’analyse d’impact et une revue brève du code. Même s’il ne participe pas activement à sa première réunion d’estimation, cela lui permettra de comprendre les différents niveaux de complexité des user stories travaillées par l’équipe.

Et pour la suite ?

Bien qu’il soit crucial de maintenir le jalon visible, une approche complémentaire consiste à sélectionner un échantillon de user stories précédemment terminées (“done”) afin d’élargir votre base de référence. Après plusieurs sprints, vous disposerez d’un panel étendu de user stories qui ont été évaluées et réalisées avec succès. Lors de la planification d’une nouvelle réunion d’estimation, prenez le temps de choisir deux ou trois user stories pour chaque nombre de la séquence de Fibonacci (1, 2, 3, 5, 8, 13, etc.). Cet éventail constituera un “jalon étendu”. Affichez ces cartes de user stories dans la salle où se déroulera la séance d’estimation, disposées en colonnes avec les estimations en tête.

Pendant la séance d’estimation, en cas de désaccord sur la complexité d’une user story, il sera facile de se référer à cette sélection pour comparer les différents niveaux de complexité. Cette pratique ne résout pas tous les conflits ; parfois, il est nécessaire de renvoyer la user story à l’analyse car elle n’est pas assez explicite. Si le client ne peut pas répondre aux questions de l’équipe, il pourrait être envisagé de réduire le périmètre de la user story ou de la diviser en plusieurs stories, afin de rendre l’estimation réalisable. Cette démarche pourrait conduire à prioriser la user story dans le backlog.

Evaluer un backlog complet

Dans le cas de l’évaluation d’un backlog comprenant de nombreuses User Stories, il peut être fastidieux de passer son temps à évaluer chaque story individuellement. C’est là qu’intervient le jalon étendu mentionné précédemment, qui peut grandement aider l’équipe confrontée à cette tâche.

Voici comment se déroule la préparation de l’évaluation :

1. L’espace où se déroulera l’évaluation doit être suffisamment grand pour que les membres puissent circuler aisément.
2. Le jalon étendu est disposé en haut d’un tableau ou d’un mur. Chaque étalon est accompagné de sa User Story de référence, ainsi que de sa valeur estimée.
3. Les User Stories à évaluer sont affichées ou disposées sur une table de manière individuelle.
4. Il est crucial que la création des jalons ait eu lieu en amont de la réunion d’estimation et que l’ensemble de l’équipe soit en accord avec ceux-ci.

Le déroulement de l’évaluation se fait en silence, sans débat :

1. Un membre de l’équipe présente les étalons à l’équipe afin que chacun puisse les avoir à l’esprit.
2. Les membres de l’équipe choisissent une User Story dans la liste et évaluent mentalement sa complexité en fonction des jalons précédemment présentés.
3. Le tour de table commence. À son tour, chaque membre lit la User Story qu’il a sélectionnée et la place en dessous du jalon de complexité qu’il estime approprié.
4. Si un membre de l’équipe n’est pas d’accord avec l’estimation, il a la possibilité de déplacer la User Story vers un autre étalon lors de son tour. La User Story que celui-ci avait pioché sera alors évaluée au prochain tour.
5. Si une User Story est déplacée à plusieurs reprises, elle est mise de côté et placée dans une pile à réévaluer. Cette pile fera ensuite l’objet d’une session de planning poker spécifique.

Ce processus se répète jusqu’à ce que toutes les User Stories soient affichées sur le tableau ou placées dans le pot “à réévaluer”.