Les Story Points Ne Sont Pas des Estimations de Temps (Et Pourquoi Ça Compte)
Tous les quelques mois, la même scène se rejoue. Un product manager entre dans une réunion de planification, l'équipe attribue des story points à un ensemble de tickets, puis quelqu'un sort une feuille de calcul convertissant ces points en heures pour pouvoir promettre une date de livraison aux parties prenantes.
Et comme ça, tout l'objectif des story points s'effondre.
J'ai vu ça arriver dans des startups, dans des scale-ups et dans des entreprises qui devraient mieux savoir. La cause profonde est toujours la même : une incompréhension fondamentale de ce que les story points sont censés mesurer — et une culture de management qui ne peut pas résister à tout traduire en calendrier.
Ce que Mesurent Vraiment les Story Points
Les story points sont une unité de complexité relative. Ils comparent l'effort d'un travail à un autre, en tenant compte de la complexité, de l'incertitude et du risque — pas des heures d'horloge.
Quand une équipe dit "c'est un 5 et ça c'est un 2," elle dit que la première tâche est environ 2,5 fois plus complexe que la seconde. Elle ne dit pas que la première tâche prend 5 heures ou 5 jours. Le nombre est relationnel, pas absolu.
Cette distinction compte parce que :
- Deux développeurs peuvent compléter la même story à 5 points en des quantités de temps très différentes. L'un connaît mieux le codebase. L'autre est plus rapide pour déboguer. La complexité du problème est la même pour les deux.
- Une story à 5 points ce sprint peut prendre plus de temps qu'une story à 5 points le sprint dernier. Les changements de contexte, les incidents de production, les changements d'équipe — tout cela affecte la durée mais pas la complexité.
- La complexité est estimable ; la durée ne l'est pas. Les ingénieurs sont raisonnablement bons pour comparer la difficulté de deux tâches. Ils sont mauvais pour prédire combien d'heures quelque chose va prendre. Les story points s'appuient sur la force et évitent la faiblesse.
Au moment où vous commencez à dire "1 point = une demi-journée," vous avez abandonné l'estimation relative et vous êtes retourné aux estimations de temps avec des étapes supplémentaires.
Pourquoi les Managers Convertissent les Points en Temps (Et les Dégâts que Ça Cause)
Je comprends. Si vous êtes product manager ou CEO, vous avez besoin de répondre à "quand est-ce que ce sera prêt ?" C'est une question légitime. Le problème c'est le raccourci : prendre des story points et diviser par une "vélocité" pour produire une date.
Voici ce qui se passe vraiment quand vous faites ça :
Les équipes commencent à jouer avec les chiffres. Si le management traite les points comme du temps, les ingénieurs apprennent à gonfler les estimations pour ne pas être pressurés pour "s'engager" sur trop de points. Ce qui était un 3 devient un 5. Ce qui était un 5 devient un 8. Les chiffres ne signifient plus rien.
La vélocité devient une métrique de performance. Au lieu d'être un outil de planification, la vélocité devient un tableau de bord. Les équipes qui "livrent" plus de points sont récompensées. Les équipes commencent à découper artificiellement les stories ou à gonfler les estimations pour paraître plus productives. Vous mesurez maintenant la mauvaise chose et incitez au mauvais comportement.
La confiance s'érode. Les ingénieurs se sentent surveillés plutôt que de confiance. Ils dépensent plus d'énergie à gérer les attentes qu'à résoudre les problèmes. La planification de sprint cesse d'être une conversation collaborative sur ce qui est réaliste et devient une négociation où les deux parties se positionnent.
La précision des estimations empire, pas mieux. L'ironie est cruelle : plus vous poussez fort pour des estimations de temps précises, moins vos estimations deviennent fiables. La pression introduit du biais. Le biais détruit le signal.
Des Alternatives qui Fonctionnent Vraiment
Si les story points sont mal utilisés dans votre équipe, vous avez des options. Certaines équipes s'en sortent mieux en passant complètement à une approche différente.
Le Dimensionnement en T-Shirt
Au lieu de nombres, utilisez S/M/L/XL. C'est délibérément imprécis, ce qui est le but. Ça force des conversations sur la taille relative sans l'illusion de précision mathématique. Un product owner peut regarder un roadmap de médiums et de larges et avoir une idée approximative de l'étendue sans que personne prétende qu'un L équivaut à exactement 3,5 jours.
Le Mouvement No-Estimates
Celui-là est plus radical : arrêtez d'estimer les stories individuelles complètement. Concentrez-vous plutôt sur la décomposition du travail en petits morceaux de taille similaire et mesurez le débit. Si votre équipe complète en moyenne 12 éléments par sprint et que le backlog a 36 éléments de taille similaire, vous pouvez prévoir "environ 3 sprints" sans jamais attribuer un nombre à une story individuelle.
Ça fonctionne mieux quand vous avez de la discipline dans la décomposition des stories. Si certaines stories sont minuscules et d'autres énormes, la prévision basée sur le débit s'effondre.
La Prévision par Temps de Cycle
C'est mon approche préférée pour les équipes qui ont au moins quelques mois de données historiques. Au lieu d'estimer vers l'avant, vous regardez en arrière pour voir combien de temps le travail prend vraiment.
Le temps de cycle est la durée depuis que le travail commence jusqu'à ce qu'il soit terminé. Si vous suivez ça par story ou ticket, vous pouvez calculer des percentiles :
- "85% de nos stories se terminent dans les 7 jours."
- "50% se terminent dans les 3 jours."
Maintenant quand quelqu'un demande "quand est-ce que ce sera prêt ?" vous donnez une réponse probabiliste : "D'après notre historique, il y a 85% de chances que ce soit prêt dans les 7 jours ouvrés." C'est plus honnête, plus défendable et plus utile que toute estimation basée sur des points.
Des outils comme Jira, Linear et Shortcut peuvent générer des données de temps de cycle. Vous n'avez besoin de rien de sophistiqué — une feuille de calcul suivant la date de début et la date d'achèvement par story vous donnera 80% de la valeur.
Quand l'Estimation Ajoute de la Valeur
Je ne suis pas anti-estimation. L'estimation est utile quand elle sert un objectif clair :
- Pour délimiter de grandes initiatives. Quand vous devez décider entre deux projets qui pourraient prendre 3 mois vs. 9 mois, l'estimation approximative aide à allouer les ressources et à définir les attentes. Le dimensionnement en t-shirt ou le story mapping fonctionnent bien ici.
- Pour identifier les inconnus. Si l'équipe ne peut pas s'accorder sur si quelque chose est un 3 ou un 13, ce désaccord est la valeur. Ça fait remonter des hypothèses différentes, des exigences manquantes et une complexité cachée. La conversation autour de l'estimation est plus précieuse que le nombre.
- Pour la planification de capacité. Savoir approximativement combien de travail rentre dans un sprint aide les équipes à éviter le sur-engagement. Mais ça ne fonctionne que si vous protégez les estimations d'être weaponisées en délais.
Quand l'Estimation Est Pure Perte
L'estimation n'ajoute aucune valeur quand :
- Chaque story a à peu près la même taille. Si votre équipe est devenue bonne pour décomposer le travail en petits morceaux, les estimations sont redondantes. Comptez juste les stories.
- Les estimations n'alimentent aucune décision. Si personne n'utilise les estimations pour prendre une décision de planification, vous dépensez 30 minutes par sprint sur un rituel qui ne produit rien.
- Les estimations sont utilisées pour blâmer, pas pour planifier. "Tu as dit que c'était un 3 et ça a pris une semaine." Si cette phrase a déjà été prononcée dans votre équipe, votre processus d'estimation fait plus de mal que de bien.
L'Objectif Réel : La Prévisibilité, Pas la Précision
Voici ce que la plupart des gens manquent : l'objectif de toute pratique d'estimation est la prévisibilité, pas la précision. Vous n'avez pas besoin de savoir que la Fonctionnalité X prendra exactement 14 jours. Vous avez besoin de savoir que votre équipe peut livrer de manière fiable un ensemble de fonctionnalités dans un trimestre. C'est un problème différent, et il se résout avec des métriques de flux, pas avec de meilleures devinettes.
Suivez le temps de cycle. Mesurez le débit. Surveillez les limites de travail en cours. Ce sont des indicateurs retardés qui reflètent la réalité, pas des indicateurs avancés qui reflètent l'espoir.
Les équipes avec lesquelles j'ai travaillé qui ont la plus haute prévisibilité de livraison ne sont pas celles qui ont les rituels d'estimation les plus sophistiqués. Ce sont celles qui gardent le travail petit, limitent le WIP et utilisent des données historiques pour prévoir. Pas besoin de planning poker.
Chez Conectia, les ingénieurs seniors que nous intégrons dans vos équipes comprennent ça. Ils ont travaillé dans suffisamment d'équipes pour savoir que le théâtre d'estimation fait perdre du temps à tout le monde, et ils apportent des habitudes pratiques — petites PRs, périmètre clair, débit cohérent — qui rendent votre livraison prévisible sans transformer la planification de sprint en négociation. C'est ce que font les ingénieurs expérimentés : ils font fonctionner le processus, pas seulement le code.
Fatigué du théâtre d'estimation qui ralentit votre équipe ? Parlez à un CTO — nos ingénieurs seniors LATAM apportent les habitudes de livraison qui font de la prévisibilité un sous-produit, pas une bataille.
