Une estimation n'est pas un engagement

Cette semaine, au cours de réunions avec des équipes différentes, j'ai eu l'occasion de constater que la croyance qui consiste à considérer une estimation comme un engagement est tenace

Mardi j’animais une rétrospective. On m’a remonté des difficultés à estimer des histoires d’utilisateur en points. Puis une fois l’estimation faite, les doutes qui persistent sur la qualité de ces estimations :

Et si une pour une histoire que nous avons estimée à 3 points, on s’aperçoit que finalement elle vaut 5 points ?

Vendredi lors d’une revue de sprint, j’ai assisté à la présentation d’un tableau montrant la liste des tâches du sprint qui se finissait. Pour chaque tâche, l’orateur (le ScrumMaster) a présenté l’estimation en heures faite au début du sprint et le nombre d’heures effectivement passées sur la tâche, en essayant de justifier les écarts.

Ces deux cas sont pour moi symptomatiques d’une mauvaise compréhension de ce que sont l’estimation et la planification agiles. Une différence fondamentale par rapport à la gestion de projet classique, est que des ré-estimations y sont faites fréquemment. Et cela change tout. La première estimation n’est qu’une estimation parmi d’autres, c’est la dernière qui compte. On peut oublier les précédentes, une fois qu’on a produit un burndown chart.

Concernant l’estimation en points, j’ai déjà évoqué dans le billet histoires de points à quoi elle servait vraiment[1] et qu’il ne fallait pas lui donner plus d’importance que ça.

À propos de mon deuxième exemple sur la comparaison des heures passées avec les heures prévues pour les tâches du sprint, j’ai déjà dit ce que je pensais du relevé des heures.

Pour ces 2 projets, une vraie pratique de ré-estimation n’a pas été mise en place. Pour les estimations des histoires d’utilisateur en points, cela doit se faire une fois tous les sprints[2]. Pour les estimations en heures sur les tâches, cela se fait tous les jours, lors du scrum meeting.

Cette pratique de ré-estimation régulière permet :

  • de faciliter la première estimation, car on sait qu’on va ré-estimer fréquemment.
  • de se passer de la marge de protection parfois ajoutée arbitrairement[3] à une estimation par ceux qui craignent d’avoir des reproches en cas de dépassement du chiffre annoncé.
  • d’éviter qu’une personne qui a fini un travail “en avance” ne le fasse durer de peur d’être accusée de sur-estimation.
  • de diminuer le doute. Une estimation est toujours fausse, mais de moins en moins au fur et à mesure des ré-estimations.
  • d’éviter de perdre du temps à mesurer le réel consommé, à le comparer à la première estimation et à proposer une justification généralement sans intérêt de l’écart constaté.

J’ai d’ailleurs constaté que ce qui provoque le plus de changement dans une planification n’est pas dû à une mauvaise estimation initiale mais provient de la découverte d’un nouvel élément qu’il faut ajouter dans le plan :

  • une histoire d’utilisateur qui avait été oubliée pour le plan de release
  • une tâche à faire à laquelle on n’avait pas pensé et qu’on découvre au cours d’un sprint

Notes

[1] en résumé : à mesurer la vélocité moyenne permettant de planifier la release, ainsi qu’à aider à estimer la vélocité du prochain sprint

[2] je conseille de faire une réunion quelques jours avant la fin du sprint

[3] ne pas confondre cette marge arbitraire -je pense que c’est 10, j’ajoute 5 pour être tranquille- avec un buffer d’incertitude

Voir aussi :