Estimation agile

Estimation en points

Estimation agile

C’est un graphique qui illustre ce premier article qui parle d’estimation, publié dès 2006. Il est appelé burndown chart. On voit ici qu’il descend avec des points gagnés pendant une itération.

Des points ? Comme c’est mystérieux !

Le texte de 2006

Je n’ai jamais été un fan des techniques d’estimation des coûts classiques (CoCoMo), ni d’ailleurs des estimations en général. Estimer le nombre de lignes de code ou le temps qu’on va passer sur une tâche qui se déroulera (peut-être) dans plusieurs mois, c’est le plus souvent du temps perdu. De plus c’est trop souvent perçu comme un engagement plutôt qu’une hypothèse à réévaluer.

En revanche je suis un grand supporter de l’estimation agile par les “story points”. J’ai découvert cette technique dans le livre de Mike Cohn, Agile Estimating and Planning. Depuis, je l’ai utilisée et fait pratiquer sur 3 projets et j’en suis très satisfait. Bien sûr, elle nécessite d’avoir au préalable une liste de user stories.

Elle demande aussi de l’accompagnement auprès des équipes lors des séances d’estimation (collective) pour choisir la meilleure façon de procéder et lever les inhibitions au démarrage. Elle donne alors des résultats spectaculaires. Les équipes s’habituent vite à estimer de façon relative, ce qui limite les ré-estimations. On arrive facilement à calculer la vélocité (le nombre de points gagnés par itération). On obtient la mesure de l’avancement du projet (le nombre de points restant à faire).

Le management a une excellente visibilité grâce à un graphe de tendance (qui s’appelle dans Scrum le Burndown Chart), comme celui-ci, obtenu sur un projet client que je coache, qui est remis à jour après chaque itération.

Avec une simple règle de 3, on peut savoir combien d’itérations sont nécessaires pour finir le projet.

Les commentaires de l’époque

Freddy Mallet

Je n’ai jamais travaillé avec des points. Je me dis qu’au bout d’un moment implicitement dans l’esprit de l’équipe 1 point équivaut à une charge temporelle du style 1 journée ou 1/2 journée et que ça revient finalement à travailler en jour idéal.

Au vue de ton expérience Claude, qu’en est-il sur le long terme ?

Ma réponse à Freddy :

En fait non. C’est seulement la première fois que l’équipe a tendance à estimer en jours. Pour lancer le travail d’estimation en équipe, je prends en général une user story déjà réalisée (développement partant d’un existant) ou alors bien connue (si développement nouveau) de taille moyenne et je la fixe arbitrairement à 2 ou 3 points. Après on procède par comparaison et on oublie vite les jours.

D’ailleurs je viens de faire le calcul -a posteriori- pour un projet que je coache : un point a nécessité en moyenne 2,5 jours de travail. Sur un autre, c’est plutôt autour de 1,5.

En revanche, il est préférable de disposer des estimations avant la revue de planification de début de sprint. Sinon pour les user stories sélectionnées dans le sprint courant, l’équipe fait à une heure d’intervalle l’estimation (en points), puis l’estimation en heures des tâches associées à la story et là, ça perturbe.

Gianfranco

Nouveau dans le monde de l’agilite, je n’ai jamais travaille ni avec les ideal days ni avec les story points mais je dois avouer qu’instinctivement j’adopterais volontier la version Story Point - Velocity plutot que la version Ideal Days - Load Factor. J’aime bien l’idee que l’estimation temporelle soit derivee et non pas un point de depart. Comment faites-vous en general, partez-vous d’une Story evaluee a X points puis les autres en decoule? ou bien par example commencez-vous par une premiere categorisation des user stories, chaque categorie ayant une representante d’apres laquelle les autres dans la meme categories seront evaluees? Il me semble difficile d’evaluer l’ensemble sur la base d’une seule representante mediane. Je pense que c’est vraiment une question de feeling de l’equipe et qu’avec la technique des iterations frequentes les deux techniques devraient donner des resultats similaires. Je travaille actuellement dans une societe russe a St Petersbourg ou il utilisent la version ideal days et disent en etre satisfait.

Ma réponse à Gianfranco :

Comme c’est une estimation relative, le nombre de points donnés à une user story n’a pas d’importance. La seule chose qui compte, c’est qu’une user story qui vaut 2 points doit apparaître 2 fois plus longue à réaliser qu’une user story à 1 point.

J’utilise comme liste de points possibles la suite de Fibonacci : 1, 2, 3, 5, 8 et 13. La toute première fois il suffit donc d’avoir à l’esprit ce domaine de variation.

Ce que j’en pense en 2021

À noter qu’à l’époque je n’utilisais pas sprint mais itération et que je ne disais pas encore planning poker mais séance d’estimation collective. J’ai aussi écrit “finir le projet” alors que maintenant je n’utiliserais plus la notion de projet qui a une fin.

Je commençais en exprimant ma réticence vis à vis les estimations dans le développement de logiciel. C’était tout à fait sincère. J’étais plutôt enthousiaste pour les estimations en points. J’avais lu en 2005 le fameux livre de Mike Cohn (que je cite) ; sa clarté m’avait convaincu d’essayer. Et je dois dire que mes premières expériences se sont bien passées ce qui m’a poussé à défendre les estimations en points pendant une dizaine d’années.

Aujourd’hui je suis plus réservé sur l’intérêt des estimations et l’usage de la vélocité après avoir constaté des dérives souvent dues à des pressions exercées sur l’équipe. J’ai aussi été sensible au mouvement noEstimates qui a émergé vers 2015.

Voir aussi