Le meilleur moyen d'établir une référence lorsqu'on joue au Planning Poker

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Mike Cohn
Source : The Best Way to Establish a Baseline When Playing Planning Poker
Date : 31/05/2016


Traducteur : Fabrice Aimetti
Date : 19/07/2017


Traduction :

the-best-way-to-establish-a-baseline-when-playing-planning-poker-quote.png

Le Planning Poker repose sur une estimation relative pendant laquelle chaque élément à estimer est comparé à un ou plusieurs éléments précédemment estimés. C'est le rapport entre les éléments qui compte. Un élément estimé à 10 unités de travail (généralement, des points de story) est estimé prendre deux fois plus de temps pour le finir qu'un élément de cinq unités de travail.

L'avantage de l'estimation relative est qu'elle devient de plus en plus facile au fur et à mesure que l'équipe estime davantage d'éléments.

Estimer un nouvel élément consiste à regarder les éléments précédemment estimés et à trouver quelque chose ayant nécessité une quantité de travail similaire. C'est plus facile lorsque l'équipe a déjà estimé 100 éléments que lorsqu'elle en a uniquement estimé 10.

Mais, l'estimation relative, à l'image de ce qui fait dans le Planning Poker, souffre d'un problème de démarrage : comment une équipe fait-elle pour sélectionner les estimations initiales qui vont lui permettre de comparer ?

Ma recommandation est que, lorqu'une équipe commence à jouer au Planning Poker, ses membres identifient deux valeurs qui vont établir sa référence. Ils le font sans jouer au Planning Poker. Ils le font simplement en discutant. Une fois la référence établie, les membres de l'équipe peuvent utiliser le Planning Poker pour estimer les autres éléments.

Idéalement, l'équipe est capable d'identifier une story à deux points et une story à cinq points.Il est prouvé que les humains estiment de manière plus fiable lorsqu'ils restent dans le même ordre de grandeur.

Identifier un élément du backlog produit à deux points et un autre élément à cinq points prépare bien ce travail de répartition au sein du même ordre de grandeur.

Si trouver un deux et un cinq se révèle difficile, recherchez plutôt un deux et un huit, ou un trois et un huit. Tout ce qui se répartit dans un intervalle entre 1 et 10 fonctionnera car c'est là où nous estimons correctement.

Evitez de commencer avec une story de un point

J'évite de commencer avec une story de 1 point. Elle ne laisse pas d'espace pour quelque chose de plus petit sans devoir passer par les fractions, et c'est plus difficile de travailler ensuite avec.

De plus, comparer toutes les stories suivantes à une story de 1 point se révèle difficile. Dire qu'un élément du backlog produit prendra deux ou trois plus de temps qu'un autre semble intuitivement plus facile et plus juste que de dire qu'il prendra 10 fois plus de temps.

J'en ai parlé dans mon livre de 2005 "Agile Estimating and Planning" (aujourd'hui c'est aussi une formation vidéo). En 2013, cela a été confirmé par Magne Jørgensen du Simula Research Lab. Jørgensen, un chercheur de renom qui a conduit des expériences impliquant 62 développeurs. Il a découvert que "utiliser une petite user story en tant que référence avait tendance à générer des estimations tros petites pour les autres stories, dû à un effet d'assimilation" (NdT : réduction de la différence perçue entre un stimulus et un autre stimulus, le premier stimulus servant comme point d’ancrage au second ; les stimuli sont dès lors jugés plus semblables qu’ils ne sont en réalité).

Pourquoi utiliser deux valeurs pour la référence ?

Etablir une référence avec deux valeurs permet aux premières stories d'être comparées à ces deux autres éléments. C'est ce que l'on appelle la triangulation et qui permet de réaliser des estimations plus cohérentes.

Si une équipe a établi une référence avec des stories de deux et cinq points, ses membres peuvent valider une estimation de trois points en se demandant si cela prend plus longtemps que deux ou moins de temps que cinq.

N'établissez pas une nouvelle référence pour chaque projet

Certaines équipes établissent une nouvelle référence au début de chaque projet. Etant donné que cela provoque une perte de tout l'historique des données de vélocité, je ne recommande pas de le faire tant que deux choses restent vraies :

  • Les membres de l'équipe développant le nouveau système sont ceux qui ont été largement impliqués dans le système précédent. L'équipe n'a pas besoin de rester entièrement la même, mais tant que la moitié de l'équipe reste la même, vous ferez bien de conserver la même référence.
  • L'équipe construit un système relativement similaire. Si une équipe passe du développement d'un site web au développement d'un firmware (NdT : logiciel embarqué) par exemple, elle doit établir une nouvelle référence. Mais si le système à construire est relativement similaire, aussi bien dans le domaine que dans la technologie, n'établissez pas de nouvelle référence.


A chaque fois que c'est possible, conservez la valeur des données historiques en maintenant une référence cohérente pour l'équipe de sprint en sprint.

Comment établissez-vous votre référence ?

Comment estimez-vous votre référence et vos estimations initiales pour une nouvelle équipe ? Je vous invite à partager vos réflexions en laissant un commentaire.