Estimation agile : pourquoi les story points sont une mauvaise idée
Estimation agile : pourquoi les story points sont une mauvaise idée
J'étais en coaching d'une équipe dans une grande institution financière. Lors du sprint planning, un développeur senior a dit "13" pour une story. Silence. Puis, progressivement, tous les autres ont voté 13 aussi. La story a été estimée à 13 points en 90 secondes.
Personne n'avait compris la story. Tout le monde avait suivi le senior.
La semaine suivante, le management a demandé à l'équipe d'augmenter sa vélocité de 20%. L'équipe a obligé, en estimant les stories plus bas. La vélocité a augmenté. La valeur livrée n'a pas changé.
Ron Jeffries, l'un des inventeurs du planning poker et des story points, a publié en 2019 un article titré "Story Points Revisited" dans lequel il regrette leur création. "I think story points are mostly harmful," écrit-il. Pas parce que la complexité ne mérite pas d'être estimée, mais parce que la façon dont la plupart des équipes utilisent les story points crée plus de problèmes qu'elle n'en résout.
Vingt-cinq ans de terrain m'ont donné le même constat.
Ce que les story points mesurent vraiment
Officiellement : la complexité relative d'une User Story, indépendante du temps.
En pratique : l'effort perçu, filtré par les dynamiques politiques de l'équipe.
La dérive se produit en 3 étapes invariables. L'équipe estime une story à 8 points parce qu'elle est complexe. Le management observe que l'équipe fait 30 story points par sprint. Le trimestre suivant, l'objectif est de "faire 35 story points par sprint."
À l'étape 3, les story points ne mesurent plus la complexité : ils mesurent une pression de production. Les développeurs le savent et ajustent leurs estimations en conséquence. La vélocité monte. La valeur livrée ne change pas.
Dans toute équipe qui utilise les story points depuis plus de 6 mois avec une pression sur la vélocité, des patterns de gaming émergent. L'inflation des estimations pour "se couvrir" : tout devient 5 ou 8, jamais 1 ou 2. La déflation pour "montrer de la vélocité" : accepter plus de stories au sprint planning qu'on ne peut en faire. Et la négociation politique lors du planning poker : le senior dit 13, tout le monde s'aligne sur 13.
Les 3 pathologies créées par les story points
Pathologie 1 : La durée des sessions de planning. Le planning poker crée des discussions de 20 à 45 minutes par story sur des questions d'estimation abstraite. Ces discussions ne créent pas de valeur : elles consomment du temps qui pourrait être utilisé à comprendre le métier ou à lever les ambiguïtés réelles. J'ai mesuré dans une équipe de 8 personnes : 180 minutes par sprint consacrées à l'estimation. Soit 78 heures-personne par trimestre pour produire un chiffre que personne ne croit.
Pathologie 2 : La comparaison entre équipes. "L'équipe A fait 40 points par sprint et l'équipe B en fait 25." Cette comparaison est absurde : les story points de deux équipes différentes ne mesurent pas la même chose. Mais le management qui a accès à ces données les compare inévitablement. J'ai vu cette comparaison détruire la collaboration entre deux équipes qui travaillaient pourtant sur la même base de code.
Pathologie 3 : La dette d'estimation. Quand le contexte change (nouvelle technologie, départ d'un senior, changement de stack), la calibration des story points devient invalide. L'équipe passe plusieurs sprints avec une vélocité erratique, et le management interprète ça comme un problème de productivité. C'est un problème de métrique inadaptée, pas de performance.
Votre planning poker est devenu une source de friction sans apporter de valeur réelle à la planification ?
La transition vers des alternatives aux story points nécessite un accompagnement pour ne pas perdre la confiance du business dans la planification. En 30 minutes, je définis avec vous la stratégie de transition adaptée à votre contexte et à votre management.
L'alternative 1 : le sizing T-shirt
Le sizing T-shirt remplace les valeurs numériques par des tailles (S, M, L, XL). L'avantage fondamental : il est impossible de faire de la fausse précision avec des tailles. "Ceci est une story M" ne peut pas être transformé en "notre vélocité est de 35 tailles-M par sprint."
La définition des tailles en termes de cycle time attendu (pas d'effort, de durée réelle) est ce qui rend la méthode concrète :
- S : terminable en moins d'un jour de développement
- M : terminable en 1 à 3 jours
- L : terminable en 1 semaine
- XL : trop grande pour un sprint, doit être découpée avant d'entrer en sprint planning
La règle est non-négociable : toute story XL ne peut pas entrer en sprint. Elle doit être découpée en stories S, M, ou L.
Ce que le business voit : le nombre de stories terminées par sprint et leur distribution par taille. Pas une vélocité abstraite, mais un throughput concret.
L'alternative 2 : le throughput et le mouvement #NoEstimates
Le mouvement #NoEstimates (Vasco Duarte, Woody Zuill) propose une approche encore plus radicale : arrêter d'estimer et mesurer la capacité à travers le throughput, c'est-à-dire le nombre de stories terminées par sprint, quelle que soit leur taille.
L'hypothèse fondamentale : si les stories sont suffisamment petites et uniformes (toutes inférieures ou égales à 3 jours), la loi des grands nombres s'applique. La variance se lisse sur 3 à 6 sprints et le throughput devient un prédicteur fiable de la capacité future.
Ce que le business entend : "Avec 15 stories par sprint en moyenne sur les 6 derniers sprints, il nous faudra environ 3 sprints pour terminer les 40 stories restantes de la fonctionnalité X." C'est plus précis qu'une prédiction basée sur des story points qui dérivent.
Le prérequis est strict : que les stories soient uniformément petites. C'est la condition que beaucoup d'équipes ne respectent pas, et c'est pourquoi elles ne peuvent pas adopter #NoEstimates directement. Le sizing T-shirt est souvent une étape intermédiaire nécessaire.
Comment faire la transition sans casser la confiance du business
Le business a souvent été "vendu" les story points comme un outil de prédictibilité. La transition doit être gérée avec transparence, pas imposée.
Sprints 1-2 : présenter les deux méthodes en parallèle. Continuer à estimer en story points tout en calculant le throughput. Montrer que les deux donnent les mêmes prédictions sur 3 sprints. Rassurer sur la continuité de la prédictibilité.
Sprints 3-4 : passer en sizing T-shirt uniquement. Montrer que la planification capacitaire reste fiable. Partager les données avec le management.
Sprints 5 et suivants : si l'équipe est prête et les stories sont uniformément petites, explorer le throughput comme seule métrique.
L'argument décisif : les données. Sur les 6 derniers mois, quelle est la corrélation entre la vélocité en points et la valeur livrée ? Dans la plupart des équipes, cette corrélation est faible. Ce fait, présenté objectivement, démontre que les story points ne mesurent pas ce qu'on prétend qu'ils mesurent.
Les métriques qui remplacent avantageusement la vélocité
Les recherches DORA (DevOps Research and Assessment) sont claires : les équipes avec les meilleures performances de delivery n'utilisent généralement pas les story points. Elles mesurent le flux.
Cycle Time : temps entre le début du développement et le merge. Mesure la fluidité du workflow.
Throughput : nombre de stories terminées par sprint. Mesure la capacité réelle de livraison.
Flow Efficiency : pourcentage du cycle time où la story est activement travaillée versus en attente. Révèle les goulots d'étranglement invisibles.
Work Item Age : âge des stories en cours. Un item vieux de 3 sprints est un signal d'alerte qui mérite investigation.
FAQ sur l'estimation agile
1. Peut-on abandonner les story points si le management les utilise pour les planifications budgétaires ?
Oui, avec une transition transparente. Le management a besoin de prédictibilité, pas de story points spécifiquement. Montrer que le throughput avec des intervalles de confiance basés sur 6 sprints de données est plus fiable pour les prédictions à 3-6 mois que la vélocité en points, qui dérive systématiquement. Proposer une période de validation en parallèle avant le switch complet.
2. Le sizing T-shirt n'est-il pas trop imprécis pour planifier ?
C'est exactement la bonne précision. L'estimation en story points donne une fausse précision : 8 points n'est pas plus précis que L, c'est juste plus abstraitement précis. Le sizing T-shirt force à accepter l'incertitude naturelle de l'estimation et à planifier avec des intervalles de confiance plutôt que des prédictions ponctuelles illusoires.
3. Comment gérer les stories très différentes en taille avec le sizing T-shirt ?
En appliquant la règle de découpage : toute story XL est découpée avant d'entrer en sprint. C'est le prérequis de la méthode. Un backlog sain contient essentiellement des stories S et M prêtes à développer. Si une story ne peut pas être découpée en stories M ou L, c'est un signal que la story est mal définie, pas que la méthode ne fonctionne pas.
4. Les story points sont-ils utiles pour l'estimation initiale d'un projet ?
Pour une estimation de haut niveau d'un nouveau projet (scope discovery, appel d'offres), les story points peuvent avoir leur utilité, pas pour le sprint planning quotidien, mais pour donner un ordre de grandeur du périmètre. Dans ce cas, utiliser des T-shirt sizes sur les epics ou features plutôt que sur les stories individuelles donne un résultat équivalent avec moins de friction.
5. Que faire quand les développeurs seniors refusent d'abandonner les story points ?
Ne pas forcer. Commencer par un pilote volontaire sur un sprint, en mesurant le temps passé en estimation et en comparant la qualité des prédictions. Le résultat de l'expérience parle mieux que l'argument de principe. Les développeurs qui résistent le plus au changement deviennent souvent les défenseurs les plus convaincus une fois qu'ils ont mesuré le gain de temps.
Ressource gratuite : Guide Lead Time -50% en 90 jours
Le guide complet pour réduire votre lead time en 90 jours inclut une section sur les métriques de flow (cycle time, throughput, WIP) qui remplacent avantageusement la vélocité en story points avec plus de précision prédictive.
