Pourquoi les Points de Story n'ont-ils pas de sens ?
Auteur : Garrett James Cassar
Source : Why Story Points don’t make sense
Date : 14/03/2024
Traducteur : Fabrice Aimetti
Date : 10/09/2024
Traduction :
C'est l'heure des aveux.
Tout au long de ma carrière, j'ai nourri quelques idées hérétiques, « non agiles » et non saines. Mais aucune ne semble aussi hérétique que celle-ci.
Mais je vais quand même le dire.
L'utilisation des points de story n'a pas de sens.
Beaucoup de gens lisent cela et pensent que ce que je veux dire, c'est « Je pense que l'estimation des stories n'a pas de sens ». Ce n'est pas le cas. Lisez mon article.
Pourquoi les points de story n'ont-ils pas de sens ?
C'est assez simple en fait. On ne peut pas les additionner.
Certes, je n'ai pas mené d'étude approfondie à ce sujet.
Mais je dispose de preuves anecdotiques cohérentes pour affirmer que ce n'est pas possible.
Une de mes anciennes équipes avait l'habitude d'estimer en points dans une fourchette de 0,5 (pour les très petites choses) à 3 (pour les très grandes choses).
Lorsque l'on interroge l'équipe sur le temps de développement nécessaire pour chaque point, les résultats sont généralement assez concluants.
0,5 - Peu de temps, deux heures au maximum. 1 - Quatre heures à une journée. 2 - Trois jours peut-être ? Quatre ? 3 - La plus grande partie d'un sprint de deux semaines, si ce n'est plus.
Interrogez votre propre équipe à ce sujet.
Le tracé de ces estimations ressemble à ceci.
Axe X - Temps de développement en jours, Axe Y - Note de complexité
Ce n'est pas un graphique linéaire, c'est un graphique exponentiel, et on ne peut pas additionner des nombres exponentiels.
La question « Combien de points pouvons-nous brûler au cours de ce sprint ? » n'a donc aucun sens. (Vélocité du sprint incluse)
Exemple :
Disons que nous pouvons brûler 15 points par sprint. Et nous avons 3 développeurs dans l'équipe.
Si les 15 points sont constitués uniquement de stories de 0,5 point.
15 points au total / 0,5 points par ticket jira = 30 tickets Jiras 0,2 effort en jours * 30 tickets jiras = 6 jours de travail pour les développeurs. 6 / 3 développeurs = 2 jours
Nous calculons que nous terminons l'ensemble du travail des sprints en 2 jours.
À l'autre extrême, supposons que nous ayons 15 points de travail pour des stories de 3 points seulement.
15 points au total / 3 points par ticket jira = 5 tickets Jiras 10 efforts en jours * 5 tickets jiras = 50 jours de travail pour les développeurs. 50 / 3 développeurs = 16,66 jours
Nous avons terminé l'ensemble du travail prévu pour les sprints en 16,66 jours.
Avec notre petite équipe de 3 personnes, cela représente une marge d'erreur de plus de 800 %.
En supposant que tous les développeurs aient exactement la même vélocité et que l'estimation soit faite parfaitement. La question « Combien de points pouvons-nous brûler » durant une période donnée n'a toujours pas de sens.
Pire encore, si vous utilisez la vélocité en points de story pour obtenir une promotion ou un bonus, le piège devient alors évident.
Comment remédier à cela ?
Utiliser l'extrémité supérieure de la suite de Fibonacci
Les points de story sont généralement estimés à partir de la suite de Fibonacci, ce qui est probablement voulu pour tenir compte de ce phénomène.
0.5 -> 3 1 -> 5 2 -> 8 3 -> 13
Axe X - Temps de développement en jours, Axe Y - Note de complexité
Cela ne résout pas vraiment le problème, mais le dilue.
Si l'on voulait vraiment utiliser un concept mathématique pour décrire cet écart, il faudrait utiliser les logarithmes, l'inverse des exponentielles. Mais qui a le temps pour cela ?
N'utilisez pas de chiffres du tout
En utilisant des tailles de t-shirt au lieu de points de stories, nous écartons l'idée qu'ils puissent être additionnés.
0,5 -> XS 1 -> S 2 -> M 3 -> L
Nous pouvons calculer la vélocité. C'est un peu plus compliqué, mais c'est précis.
En établissant un lien entre la taille et le temps qu'un développeur de niveau moyen devrait y consacrer, on peut obtenir toutes les tailles des stories terminées, les multiplier par leur facteur et les additionner.
Exemple :
XS = 0,2 jour S = 0,5 jour M = 3 jours L = 10 jours
Lors du dernier sprint, nous avons brûlé :
6 XS = (6 * 0.2) = 1.2 jours 4 S = (4 * 0,5) = 2 jours 3 Ms = (3 * 3) = 9 jours 1 L = (1 * 10) = 10 jours
Cela représente environ 23,2 jours de travail pour les développeurs. Il reste donc 6,8 jours de travail pour les revues de code, les réunions et les sorties au pub. Génial.
Conclusion
Il ne faut jamais essayer de calculer la vélocité en additionnant les points de story. Les mathématiques ne fonctionnent tout simplement pas.
Cela peut rendre vos estimations très éloignées de la réalité, encourager les développeurs malins à jouer avec le système, et rendre les delivery managers soit extrêmement déçus, soit extrêmement heureux, selon le sprint.
Je pense qu'il est préférable de leur procurer un sentiment de déception plus constant mais moins intense.
