On va estimer, à quoi devons-nous faire attention?

Savoir ce qu’est une estimation

Je te conseille la lecture de cet excellent article sur ce que sont les estimations .
(Il est excellent car c’est moi qui l’ai rédigé ;))

Avoir un ticket de référence

La dérive des continents estimations.
Sans baseline, ou référence comparative, les estimations vont se décaler, de ce fait, la vélocité, le burndown chart et autres indicateurs ne seront plus fiables.

Ne pas convertir les estimations en jour-homme

Les jour-homme créent une complexité inutile et annulent complètement l’intérêt d’estimations relatives qui permettent à tout le monde travaillant à des vitesses différentes de se comprendre et de se mettre d’accord.

Ne pas estimer uniquement en fonction de la complexité

Si on estime uniquement la complexité, une story « simple » mais demandant beaucoup d’effort. (Par exemple une tâche à répéter un certain nombre de fois, des tests longs …). Cela va créer de fausses prédictions et un manque de visibilité sur la quantité / charge de travail à réaliser dans le backlog.

Voici un tableau comparatif « à la suédoise » de la notion de complexité par rapport à la notion d’effort.

Ticket	Remarque	Comp.	Effort
En tant que constructeur, je souhaite monter un tabouret MARIUS afin de poser mes fesses	3 visses à serrer	1	1
En tant que constructeur, je souhaite monter un tabouret SKOGSTA afin de poser mes fesses	Un rien plus complexe que le MARIUS	2	2
En tant que constructeur, je souhaite monter un lit NORDLI afin de pouvoir dormir	C’est bien plus compliqué qu’un tabouret et les tiroirs sont super dur à mettre en place	5	5
En tant que constructeur, je souhaite monter 10 tabourets SKOGSTA afin de poser mes fesses et celles de mes invités	Aussi complexe simple qu’un SKOGSTA . (Nous aurions également pu considérer l’expérience)	2	20

Ne pas considérer une estimation comme quelque chose de précis, gravé dans le marbre

Jamais l’équipe et/ou les parties prenantes ne peuvent considérer une estimation comme un contrat.
L’estimation est surtout valable au moment où elle a été faite, la solution évoluant au jour le jour, il est envisageable qu’un item soit impacté par la réalisation d’un autre qui n’existait pas au moment de l’estimation. (Si il existait déjà, il faut absolument lier les 2 tickets et marquer le dépendance).
Il n’y a pas que l’application qui évolue, les développeurs aussi, dans la plus part des cas, il considérera le ticket comme plus « simple » et tout le monde y gagnera.

Ne pas considérer les estimations comme une mesure de productivité des équipes, ou pire, des développeurs.

Dans ce cas, nous verrons très vite apparaitre des dérives telles que surestimation systématique, sous engagement dans le sprint pour être sûr de le terminer.

Certains développeurs feront des heures supplémentaires et seront donc moins alertes et moins qualitatifs. D’autres simplement bâcleront le travail pour tenir le délai, ce qui générera inévitablement de la dette technique

Les estimations ne sont en aucun cas à utiliser pour contrôler l’équipe et/ou un développeur en particulier

PiPo

Ne pas comparer les estimations de deux équipes

Il est tentant de comparer les performances des équipes en convertissant l’estimation en chiffre et en divisant le total d’un sprint par le nombre de jours de ce dernier (et de faire un prorata par développeur).
Hé bien, ça ne fonctionne pas, car une estimation pour l’équipe A n’est pas une estimation pour l’équipe B.

Faire attention aux changement dans l’équipe

• Si une personne sort de lʼéquipe, cette dernière aura moins de force de travail, donc, la vélocité va décroitre.
• Si une personne rejoint lʼéquipe, dans un premier temps, la vélocité va également décroitre
  (Lʼonboarding va occuper dʼautres membres de lʼéquipe, la nouvelle personne ne sera pas efficiente à 100% au début …)
  Sur le long terme, la vélocité devrait croitre et dépasser la vélocité initiale.
  Si ce n’est pas le cas, il faut absolument comprendre pourquoi.

Ne pas forcer à estimer

Jamais les développeurs ne doivent se forcer / être forcé à estimer un ticket.
Si un ticket ne peut être compris, il ne doit pas être estimé. Une fois que l’estimation existe, elle est utilisée par les autres membres de l’équipe, or, si elle n’est pas correcte, elle faussera les travaux de ses utilisateurs.

Ne pas estimer avec une seule personne

Durant une session d’estimation, avec plusieurs participants, nous arrivons de temps à autre à des résultats différents, ce qui permet d’ouvrir un débat et amène généralement des questions sur le travail à effectuer. Nous y gagnions en précisions.

En dehors de cela, avoir une équipe avec un seul développeur n’est pas prudent, imagine l’impact si ce dernier quitte le projet …