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.

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

Commentaires

1. Le lundi 19 février 2007, 16:26 par Matthieu

Ce point de vue est intéressant, mais j'ai du mal à voir comment une entreprise peut fonctionner sans un minimum d'engagement de ses employés...
Si ceux-ci ne s'engagent pas sur leurs estimations, à quoi s'engagent-ils ?

Et si dans une équipe quelqu'un avance anormalement lentement sur les tâches qu'on lui confie, comment gérer ça sans s'intéresser à son consommé, ni contester ses estimations ?

2. Le lundi 19 février 2007, 17:18 par Stéphane Boisson

Matthieu:
Pour moi c'est l'équipe entière qui estime, pas un dévelopeur de l'équipe..
C'est donc l'équipe entière qui s'engage a livrer un logiciel fonctionnel à la fin de l'itération.
Si un développeur rencontre un obstacle, il doit apparaitre lors du point quotidien.
Et lors de la revue d'équipe qu'il faut aborder le sujet si cela est plus profond.

Il y aussi l'idée d'instaurer un climat de confiance, de ne pas chercher à trouver un coupable, mais bien faire passer le message que l'on apprend de ses erreurs..

3. Le lundi 19 février 2007, 20:23 par claude aubry
Si ceux-ci ne s'engagent pas sur leurs estimations, à quoi s'engagent-ils ?

L'équipe s'engage collectivement à obtenir un résultat à la fin du sprint, c'est plus fort que de s'engager seul sur une estimation.

Et si dans une équipe quelqu'un avance anormalement lentement sur les tâches qu'on lui confie, comment gérer ça sans s'intéresser à son consommé, ni contester ses estimations ?

Comme le dit Stéphane, il faut d'abord donner confiance, il n'y a pas de raison que chacun ne fasse pas de son mieux pour participer à l'effort collectif. Les scrums quotidiens sont généralement suffisants pour motiver les récalcitrants légers et les rétrospectives s'attaquent aux problèmes plus profonds.

4. Le mardi 20 février 2007, 10:24 par Matthieu

En effet j'oubliais cette notion de responsabilité collective, qui à vrai dire est assez abstraite pour moi, et le restera tant que je n'aurai pas vécu ce type de fonctionnement.
Une petite précision cependant : lors des scrums quotidiens, lorsque chacun communique le reste à faire sur ses tâches en cours, s'agit-il d'une estimation individuelle ou collective ?

5. Le mardi 20 février 2007, 10:26 par Camille Bloch

C'est ce qu'on appelle "l'esprit d'équipe". Mais dans des équipes hétérogènes, cette façon de faire est difficile à faire accepter. Surtout lorsque des membres de l'équipe sont issues de SSII qui cultivent la performance individuelle....