1/ Penser que 1 point = 1 heure

Bien sûr c'est tentant de détourner la "Suite de Fibonacci" comme ceci :
1 point = 1heure, 2 points = 2 heures, 8 points = 1 journée...
Mais soit vous faites vos estimations en points soit vous faites vos estimations en jour/homme mais vous ne mélangez pas les choux et les carottes.

2/ Chercher un ratio entre les points et les jours/homme

La scène : l'équipe estime la backlog en point et le manager (ou chef de projet) veut mettre cela dans son MS Project pour sortir un joli diagramme de Gantt mais bien sur MS Project ne sait compter qu'en jour/homme alors une petit règle de 3 et hop vos 6 itérations se retrouvent planifiées comme par connerie magie.
Une autre façon pour "embrouiller" votre manager est d'utiliser les tailles de T-Shirt (Cf : Réunion d'estimation : Enlevez vos t-shirts) là vous serez certain que cela ne rentrera pas dans un Gantt !

3/ Ne pas avoir 2 ou 3 repères pour les estimations

L'objectif des estimations en points est de faire de l'estimation par similitude et donc de comparer vos users stories avec d'autres Users Stories.
La meilleur façon pour le faire est d'avoir 3 Users stories de référence.
Vous comprenez pourquoi ne pas avoir de Users stories de référence est un non-sens.

4/ Changer de repères à chaque itération

Toutes les raisons sont bonnes pour changer les Users stories de référence :

  • l'équipe a été trop rapide,
  • l'équipe a été trop lente,
  • les nouvelles stories du backlog ne sont pas comparables avec nos stories de référence...

Mais changer de repère à chaque itération ne vous permet pas d'avoir une stabilité dans vos estimations.

5/ Confondre estimation et exactimation

ou confondre estimation et engagement Il n'existe que 2 façons de ne pas se tromper sur un chiffrage :

  • Attendre la fin du développement :-)
  • Avoir déjà réalisé ce même développement dans les mêmes conditions (équipe, client, technologie et fonctionnalité)

Autant dire que cela n'arrive jamais.
Maintenant, soit vous accepter un chiffre qui est surement faux mais qui a été donné plus ou moins rapidement, soit vous patientez que le développement soit terminé.

6/ Prendre toujours la plus grosse estimation

Vous trouverez cet exemple dans les centres de service qui se sont engagés à un nombre de point par itération.
C'est la technique numéro 1 que j'expliquais dans un autre billet : Ma vélocité est plus grosse que la tienne

7/ Ne pas équilibrer le temps de parole de chacun

Dans toutes les équipes, il y a des introvertis et des extravertis, des timides et des bavards. L'objectif de l'estimation à plusieurs est d'avoir l'avis de tous les développeurs du projet et non pas uniquement les 2 ou 3 grandes gueules de l'équipe.

8/ Arrêter d'estimer quand on a atteint la vélocité

STOP, c'est bon on est FULL, on a fait 40 points à la dernière itération, et là on vient d'estimer plusieurs Users Stories pour un total de 41 points.
on fera les autres US à la prochaine itération.

Sans commentaire...

9/ Passer plus de temps à expliquer la Users Stories qu'à l'estimer

L'une des difficultés du PO est de présenter les US aux développeurs, la qualité rédactionnelle des US est un facteur important mais l'ordre dans lequel sont présenté les US aussi.
Si vous avez besoin de 10 minutes d'explication du contexte de votre US pour avoir une estimation en 30 secondes, Cher PO vous étonnez pas que ce qui est développé ne correspond pas à ce que vous avez rédigé.

10/ S'obstiner à estimer des Users Stories que l'on ne comprend pas

Après 3 heures de planning poker le seul objectif des participants à cette réunion est de quitter la salle (ce qui peut se comprendre !).
Alors le PO présente ces US et les développeurs ne font plus l'effort de comprendre mais juste l'effort de sortir le même chiffre pour en finir.


J'espère pour vous (et vos projets) que vous ne vous êtes pas reconnus dans un seul de ces cas.

J'espère aussi que le développeur de l'équipe de Benjamin Guimberteau s'est réveillé depuis :-)
planning-poker-scrum.jpg