Les user stories s’accumulent dans votre product backlog, et il est grand temps de passer à la phase estimation, afin d’estimer l’effort nécessaire pour réaliser chacune de ces user story.
C’est une phase indispensable qui vous permet par la suite de mieux planifier vos sprints.
Mais comment estimer correctement les user stories ? Quelle méthode d’estimation choisir ? On fait le point dans cet article.
Pour aller + loin : Dans cet article, je pars du principe que vous connaissez les concepts des story points. Si ce n’est pas le cas, je vous invite à lire mon guide sur le sujet.
Pourquoi les estimations en jours/homme sont vouées à l’échec
Il s’agit d’évaluer le temps nécessaire pour la réalisation de chaque tâche ou fonctionnalité en jour/homme.
Pour faire simple : Non. Évitez les estimations jours/homme comme la peste.
Il s’agit d’un réflexe de l’ancien monde des méthodologies de gestion de projet traditionnelles de vouloir tout chiffrer. Mais ce réflexe, il vous faut l’abandonner. Et vite.
Le problème, c’est que même s’il s’agit d’une estimation « à la louche », si vous me dites 5 jours/homme, j’entends ce sera terminé en 5 jours et je prends ça comme un engagement.
On fonctionne tous ainsi.
L’autre gros problème que je vois, c’est que résonner en jour/homme sous-entend que les collaborateurs sont interchangeables : si Jean remplace Robert, il mettre aussi 5jour/homme, parce que c’est dans le planning.
Sauf que voilà… On n’avance pas tous à la même vitesse. En fonction de nos compétences, notre expérience, notre motivation, notre niveau d’énergie ce jour-là, on travaille tous à des vitesses différentes. Et les estimations en jour/homme n’en tiennent pas compte.
Pire, on s’imagine avec ce type d’estimation que si 2 personnes peuvent faire un travail en 50 jours/homme, il suffit de doubler le nombre de l’équipe et de les passer à 4 pour que le travail soit effectué en 25 jours/homme. Sauf que non, toujours pas.
Il existe des délais incompressibles sur les projets, et doubler ou tripler la taille de l’équipe n’y fera rien : il y a toujours un délai minimal pour la réalisation d’une action.
Ce n’est pas parce qu’une femme peut faire un bébé en 9 mois, que 9 femmes peuvent le faire en 1 mois.
Pour mieux comprendre pourquoi les estimations temporelles ne fonctionnent pas, je vous invite à dévorer cet article du coach agile sur les estimations pour travaux complexes.
4 unités de mesure pour les story points
Pour estimer vos user stories, vous pouvez être tenté par l’une de ces méthodes. Laissez-moi vous expliquer les tenants et aboutissants pour chacune d’entre elles.
1 ) Suite linéaire
Le principe est simple. Vous prenez une suite de chiffre linéaire (le plus souvent 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10), et vous attribuez vos points d’effort en planning poker en fonction.
Bien qu’elle soit un peu utilisée, j’y vois plusieurs inconvénients majeurs :
- C’est tentant de faire 1 point = 1 heure.
Après tout, on peut changer le nom de l’unité, mais le principe reste le même : est-ce plutôt 1 point ou 5 point ? On résonne toujours de la même manière lors de l’estimation, et on fera tous la conversion Points –> Temps pour pouvoir répondre. - L’écart est uniforme entre les valeurs.
C’est compliqué de trancher sur une estimation entre 4, 5, et 6 jours. Vu qu’il est nécessaire d’obtenir le consensus de l’équipe, cela peut entraîner de longs et coûteux débats pour choisir quel est LE point d’effort qui va bien, alors que les écarts sont minimes entre les différentes valeurs. ça apporte donc plus de confusion qu’autre chose. - L’estimation est toute aussi imprécise qu’avec les estimations jours/homme.
L’estimation en jours/homme se base également sur une échelle linéaire. Au final, on a changé le nom mais ce sera tout aussi imprécis et les mêmes biais d’estimations réapparaîtront.
Je vous déconseille donc fortement l’utilisation des suites linéaires.
2 ) Suite de Fibonacci et ses variantes
La suite de Fibonacci est clairement l’unité de mesure la plus utilisée par les équipes agiles. Mais pourquoi au juste ?
La suite de Fibonacci est une suite d’entiers dans laquelle chaque terme est la somme des deux termes qui le précèdent.
Elle n’est pas totalement exponentielle mais s’en rapproche. Cela veut dire que les écarts sont de plus en plus importants entre 2 valeurs. Et ça, c’est intéressant pour des estimations.
On n’hésite plus entre les valeurs 4, 5 ou 6, mais entre les valeurs 3, 5, ou 8. L’écart est plus important et cela permet de mieux appuyer sur le volume du travail à effectuer, la complexité, les risques et l’incertitude associés.
En utilisant la suite de Fibonacci, on accepte et reconnaît le caractère imprécis des estimations. On ne cherche plus à estimer de manière exacte l’effort nécessaire pour accomplir un travail comme avec les méthodes linéaires. On cherche plutôt à avoir un aperçu.
De la même manière, avec les échelles linéaires, on est tenté d’interroger quelques experts seulement. Mais ce n’est pas parce que eux passeraient 10 jours sur telle fonctionnalité que d’autres personnes en feraient de même.
La suite de Fibonacci permet ainsi d’avoir une idée de ce que le travail représente pour l’équipe. Un effort important n’est pas facilement quantifiable, on sait seulement qu’il sera important.
Représentation de la suite de Fibonacci
On utilise généralement un sous-ensemble de la suite de Fibonacci, que l’on peut voir en rouge sur l’image ci-dessus : 1 – 2 – 3 – 5 – 8 – 13 – 21.
Généralement, lorsqu’on estime une user story au-dessus de 21, on considère que c’est le signe qu’il faut la redécouper en unités plus petites.
Si vous choisissez la suite de Fibonacci comme unité de mesure, je vous conseille d’éliminer le 2 de la suite, pour éviter les débats sans fin entre les points 1, 2 et 3.
Cela vous donnerait donc : 1 – 3 – 5 – 8 – 13 – 21.
Pour aller + loin : Pour avoir plus d’arguments mathématiques sur le pourquoi du comment de la suite de Fibonacci, je vous invite à consulter cet article d’Alex Yakyma (en anglais).
3 ) Tailles de tshirt
Certaines organisations préfèrent utiliser les tailles de tshirt plutôt que la suite de Fibonacci ou l’une de ses variantes.
On retrouve alors les tailles suivantes : XS – S – M – L – XL.
On s’affranchit ainsi des chiffres qui peuvent poser des problèmes à certains pour se concentrer sur l’importance de l’effort à fournir pour réaliser le travail à estimer.
Cette unité de mesure fonctionne également très bien, comme la suite de Fibonacci.
Et si vous souhaitez passer de l’une à l’autre, voici un petit tableau de correspondance :
| Suite de Fibonacci | Taille de tshirt |
|---|---|
| 1 | XS |
| 3 | S |
| 5 | M |
| 8 | L |
| 13 | XL |
| 21 | XXL |
Pourquoi les estimations relatives sont-elles si importantes ?
Les estimations agiles sont dites relatives, en opposition aux estimations absolues, qui sont pratiquées traditionnellement dans les méthodologies classiques de gestion de projet.
Mais pourquoi ces estimations relatives sont-elles si importantes ?
- Elles s’expriment en points plutôt qu’en temps.
Nous avons énormément de mal à devoir estimer le temps nécessaire à la réalisation d’une tâche complexe. C’est d’ailleurs pour ça que des chantiers de construction prennent des années de retard : parce qu’on est mauvais sur les estimations initiales et que l’on sous-estime énormément de choses. En estimant en points, on s’affranchit de ce biais : le point reflète la complexité, le risque et l’incertitude liés à cette tâche. - Les recherches montrent que nous sommes meilleurs pour faire des estimations relatives.
Voici quelques publications sur le sujet : Improving subjective estimates using paired comparisons en 2001, Software-effort estimation : an exploratory study of expert performance en 1991 et A causal model for software cost estimating error en 1998. Et oui, ce sujet des estimations ne date pas d’hier ;-). - Les estimations sont effectuées par ceux qui vont réaliser le travail.
Qui est mieux placé que celui qui fait pour estimer ? Personne. - Les estimations sont effectuées de manière collective.
Les résultats basés sur les groupes sont toujours plus précis que les estimations individuelles. Cela s’explique par le fait qu’un individu peut passer à côté d’un pan du travail que son collègue peut mettre en évidence. Ensemble, on est donc plus forts.
Exemple d’estimations absolues, qui peuvent varier en fonction de l’individu, de son expérience, de ses compétences, etc…
Avec une estimation relative, tout le monde tombe d’accord, le consensus de groupe est atteint.
Pour aller + loin : Découvrez dans cet article les différentes méthodes d’estimation agile.
Les projets contraintes par des estimations sont voués à l’échec
Les projets contraints par des estimations sont voués à l’échec.
Frédéric Leguédois
Ce n’est pas moi qui le dit, mais Frédéric Leguédois, un dieu (ou presque) parmi les agilistes.
Si vous n’avez pas encore assisté à sa conférence « Cessons les estimations », je vous invite fortement à y aller, c’est du 100% mind-blowing.
Cette philosophie née des débats entre deux agilistes experts, Woody Zuill et Neil Killick, tente de moderniser l’approche des estimations.
Plutôt que de faire des estimations coûteuses en temps et par nature forcément imprécises, le mouvement no estimate préfère se concentrer sur la valeur apportée au client, qui est au cœur de l’agilité.
Pour mesurer l’avancement d’un projet agile, on ne se base donc plus sur la vélocité de l’équipe ou le nombre de points de complexité réalisés au fur et à mesure des sprints, mais uniquement sur le nombre de user stories terminées.
Pour aller + loin : Vous vous intéressez au #noestimates ? Je vous invite fortement à lire ce retour d’expérience d’une équipe d’Octo après avoir pratiqué la philosophie no estimate pendant plus d’un an.
