Story points : le guide du fondateur qui paie la facture

L’équipe annonce 13 points pour refaire le paiement. Vous essayez de savoir si ça vaut ce que vous dépensez chaque mois. Ce que les story points mesurent vraiment, pourquoi personne ne vous les convertira en heures, et ce qu’il faut regarder à la place.

Trois sprints après le début du projet, un fondateur avec qui nous travaillons a interrompu la revue et posé la question que toute la salle contournait depuis le début. “L’équipe dit que refaire le paiement, c’est 13 points. Je paie cher tous les mois pour ça. Qu’est-ce que j’achète exactement ?”

Personne ne lui a donné de réponse nette. C’est courant. C’est aussi un échec.

Alors, nettement : un story point est une unité de taille relative, pas de temps. Il réunit trois choses dans un seul chiffre : la complexité du travail, son incertitude, et sa quantité. Sa seule fonction est de comparer un travail à un autre travail de la même équipe. Une story à 5 points est censée représenter environ cinq fois l’effort d’une story à 1 point, pour cette équipe, ce trimestre. Par construction, elle ne dit rien sur les heures.

Ce qui pose un problème, parce que les heures, c’est précisément ce que vous achetez.

Cette tension, c’est tout le sujet de cet article. Le canon agile dit de ne jamais convertir les story points en temps. Le canon a raison, et il est en même temps discrètement inutile à la seule personne dans la pièce qui doit signer la facture. Les deux sont vrais, et vous pouvez tenir les deux si vous comprenez à quoi l’instrument a été conçu.

Ce qu’un story point mesure réellement

Les story points sortent de l’Extreme Programming, à la fin des années 1990, et ils réglaient un problème précis : les développeurs sont notoirement mauvais pour estimer des heures, et nettement moins mauvais pour estimer des rapports. Demandez à un ingénieur “combien de temps ça va prendre ?” et vous obtenez un chiffre façonné par l’optimisme, par l’identité de celui qui demande, et par ce qu’il croit que vous voulez entendre. Demandez-lui “est-ce plus gros ou plus petit que ce qu’on a livré la semaine dernière ?” et vous obtenez quelque chose de plus proche de la vérité.

Toute l’astuce est là. Un point est une comparaison, ancrée dans du travail que l’équipe a déjà terminé.

Trois ingrédients entrent dans le chiffre :

• La complexité. Combien de pièces mobiles, combien d’inconnues dans la conception, combien d’endroits où ça peut casser. Intégrer un prestataire de paiement que l’équipe n’a jamais touché est complexe même si le code est court.
• L’incertitude. Quelle part de tout ça relève de la découverte ? Une story qui dépend d’une API tierce non documentée porte un risque qu’un champ de formulaire ne porte pas.
• Le volume. La quantité brute de travail. Quarante écrans quasi identiques peuvent être simples et rester gros.

Une story à 8 points, ce n’est pas “une story à 3 points, mais difficile”. C’est une story dont l’équipe, en la comparant à tout ce qu’elle a construit ensemble, estime qu’elle fait environ huit fois la taille de sa plus petite story de référence. Si votre équipe ne peut pas désigner une story terminée et dire “voilà notre 1”, ses points sont décoratifs.

C’est la première chose à vérifier quand on achète. Demandez quelle story finie leur sert d’ancre. Une équipe qui a une vraie réponse estime. Une équipe sans réponse devine, déguisée.

Pourquoi les story points vont 1, 2, 3, 5, 8, 13

La plupart des équipes estiment sur une suite de Fibonacci modifiée : 1, 2, 3, 5, 8, 13, 21. Les écarts s’élargissent à mesure que les nombres grandissent, et c’est voulu, pas un hasard d’arithmétique.

La précision s’effondre avec la taille. Une équipe sait réellement distinguer un 1 d’un 2. Elle ne sait pas distinguer un 20 d’un 21, et si vous lui en laissez la possibilité, elle passera quarante minutes à faire semblant. L’échelle qui s’écarte force l’estimation dans des cases honnêtes sur leur propre marge d’erreur.

L’échelle sert aussi d’alarme. Dès qu’une story atteint 13 ou 21, les équipes disciplinées ne l’estiment plus. Elles la découpent. Un 21 n’est pas une estimation, c’est l’aveu que le travail n’a pas encore été compris. Si vous voyez des 21 survivre jusque dans un sprint, il y a un fil à tirer, et cela veut presque toujours dire que les user stories ont été écrites trop grossièrement pour être construites.

Le 1, 3, 5, 8 par défaut de Jira, c’est la même idée avec un vocabulaire plus court. Rien dans l’outil ne change la logique.

Combien d’heures fait un story point ?

C’est la question la plus recherchée au sujet des story points, et la seule que tous les articles de la première page de Google refusent de traiter. Voici la réponse honnête, en trois temps.

Premier temps : officiellement, aucune. Il n’y a pas de conversion, et Mike Cohn le répète depuis vingt ans. Un point n’est ni une heure, ni un jour, ni une demi-journée. Deux équipes de la même entreprise peuvent toutes deux boucler 30 points par sprint et avancer à des vitesses réelles complètement différentes, parce que leurs points sont calibrés sur des ancres différentes. Les points ne se transportent pas d’une équipe à l’autre, ni d’un trimestre à l’autre si l’équipe a changé.

Deuxième temps : votre équipe fait déjà la conversion dans sa tête. Évidemment. Tout développeur qui a un jour pointé une story s’est dit “ça fait à peu près une journée et demie”. Le calcul existe. Il est simplement informel, privé, et réajusté en permanence.

Troisième temps : il existe une conversion que vous pouvez calculer, et elle regarde en arrière. Prenez ce que l’équipe vous coûte réellement sur un sprint. Divisez par les points qu’elle a réellement terminés sur ce sprint. Vous obtenez un coût par point pour cette équipe, sur ce projet, sur cette période. Si un sprint de deux semaines vous coûte 20 000 euros et que l’équipe boucle régulièrement 40 points, votre taux effectif est de 500 euros le point, et cette refonte du paiement à 13 points est une décision à environ 6 500 euros.

Ce chiffre est utile. C’est celui qui vous permet de décider si la fonctionnalité mérite d’être construite, ce qui est votre travail, pas le leur. Et il survit au contact du réel, parce qu’il dérive de ce qui s’est passé et non de ce que quelqu’un espérait.

Mais il vient avec une règle, et cette règle porte tout le reste.

Dès que les story points deviennent un prix, ils cessent d’être une estimation

Faites la conversion. Ne la publiez pas.

À l’instant où une équipe apprend que ses points sont convertis en euros puis relus devant elle, les points cessent de mesurer la taille et se mettent à mesurer l’autoprotection. Les estimations gonflent, discrètement et universellement. Personne ne décide de le faire. Cela arrive, comme l’eau trouve la pente.

C’est la loi de Goodhart, dans la formulation plus tranchante qu’en a donnée l’anthropologue Marilyn Strathern : quand une mesure devient un objectif, elle cesse d’être une bonne mesure. Les story points y sont particulièrement fragiles, parce qu’ils sont auto-déclarés, invérifiables de l’extérieur, et estimés par les mêmes personnes dont ils mesurent la production. Il n’existe aucun audit indépendant pour dire si une story “était vraiment” un 5. L’inflation des points est indétectable par construction. Vous ne l’attraperez jamais, faute de quoi que ce soit à quoi la comparer.

Ron Jeffries, l’une des personnes qui ont mis les story points au monde, passe depuis des années son temps à expliquer qu’ils sont détournés exactement de cette façon. Son résumé, dans Story Points Revisited, vaut les quinze secondes de lecture : “J’ai peut-être inventé les story points et, si c’est le cas, je le regrette aujourd’hui.”

Gardez donc le coût par point pour vous, servez-vous-en pour vos propres arbitrages, et n’allez jamais l’agiter devant l’équipe en revue de sprint. Les fondateurs qui se trompent là-dessus finissent avec une équipe dont la courbe de vélocité est superbe et dont la date de livraison ne cesse de reculer. Ils ont optimisé le chiffre et perdu ce à quoi le chiffre servait.

À quoi ressemblent 1, 3, 5, 8 et 13 points dans un vrai projet

Les points ne se transportent pas, donc un tableau comme celui-ci est une esquisse, pas une norme. Mais les fondateurs continuent de réclamer un repère, et le refus de leur en donner un est exactement ce qui rend inutiles les articles existants sur le sujet. Voici une forme approximative, calibrée sur le travail que fait réellement une équipe produit en phase d’amorçage :

Deux choses à en retirer. D’abord, le saut de 5 à 8 à 13 est l’endroit où loge le risque, et c’est là que doit aller votre attention en planification de sprint. Ensuite, si les 13 de votre équipe ressemblent aux 3 d’une autre équipe, on ne vous surfacture pas. La calibration est simplement différente, et la seule comparaison qui compte est celle avec leur propre historique.

La vélocité est le chiffre à regarder, et voici comment le lire

La vélocité, c’est le total des points qu’une équipe termine sur un sprint. Moyennée sur les trois à cinq derniers sprints, c’est l’instrument de prévision le plus fiable dont vous disposez : les points restants dans le backlog, divisés par la vélocité, donnent les sprints restants.

Lisez-la pour sa stabilité, pas pour sa taille. Une équipe qui tourne à 32, 30, 34, 31 est une équipe sur laquelle vous pouvez caler une levée de fonds. Une équipe qui fait 45, 20, 50, 18 est une équipe dont les estimations ne veulent encore rien dire, et sa moyenne de 33 est un mensonge raconté avec de l’arithmétique. La variance est le signal. Poursuivez la variance, pas le plafond.

Trois choses corrompent silencieusement une courbe de vélocité, et les trois méritent une question :

• Le report. Des points comptés quand une story à moitié faite bascule sur le sprint suivant. Si le travail inachevé marque des points, la vélocité cesse de vouloir dire “livré”.
• La ré-estimation. Une story qui valait 5 au sprint précédent et qui vaut 8 aujourd’hui, sans que le périmètre ait bougé.
• La comparaison entre équipes. Deux squads, deux calibrations. Jamais sur le même graphique.

Quatre questions à poser en planification quand on n’est pas technique

Vous n’avez pas besoin de comprendre le code pour auditer l’estimation. Vous avez besoin de savoir si l’estimation est réelle. Ces quatre questions font ce travail, et aucune n’exige de savoir ce qu’est un index de base de données.

1. “Quelle est votre story de référence pour un 1 ?” S’ils ne peuvent nommer aucun travail terminé, l’échelle n’est pas ancrée et tous les chiffres qui en découlent sont inventés.
2. “Quelle est l’incertitude sur celle-ci, et qu’est-ce qui la ferait grossir ?” Une bonne équipe répond immédiatement et précisément : “si cette API ne gère pas les remboursements partiels, ça double”. Une équipe qui répond “ça devrait aller” n’a pas regardé.
3. “Combien avait-on estimé une story comparable la dernière fois, et combien a-t-elle coûté ?” C’est le seul contrôle de calibration qui existe. Les équipes qui le suivent s’améliorent. Celles qui ne le suivent pas dérivent.
4. “Quelle est la plus petite version de ça qu’un client pourrait utiliser ?” Ce n’est pas une question de points, mais c’est la question la plus précieuse de la pièce. Un 8 contient presque toujours un 3 qui aurait suffi.

Quand les story points sont le mauvais instrument

Les story points supposent une équipe qui dure, un backlog stable, et une relation où vous achetez de la capacité dans la durée. Si ce n’est pas votre montage, c’est le mauvais outil et vous devriez cesser d’en réclamer.

Si vous avez signé un contrat au forfait, à périmètre et prix fixes, les points ne vous concernent pas. Vous avez acheté un résultat, pas un taux, et la méthode d’estimation interne du prestataire est son problème. Si vous êtes en régie, les points sont utiles mais ne constituent pas le contrat, et la différence entre ces deux montages pèse bien plus lourd sur votre budget que n’importe quelle estimation.

Et si un prestataire vous chiffre une proposition en story points, avant que la moindre équipe ait construit quoi que ce soit avec vous, ce chiffre est décoratif. Il n’existe aucun historique commun pour l’ancrer. Les points n’existent pas tant qu’une équipe n’a pas terminé du travail ensemble, et un point venu d’une équipe avec laquelle vous n’avez jamais travaillé est un chiffre sans dénominateur.

Questions fréquentes

Combien d’heures font 5 story points ?
Il n’existe aucune conversion officielle, et tout prestataire qui vous en donne une sans nuance vous dit ce que vous voulez entendre. En pratique : divisez le coût d’un sprint par les points que ce sprint a livrés, et vous obtenez un coût par point pour cette équipe. Servez-vous-en pour vos décisions, laissez-le hors de l’ordre du jour de la revue.

1 story point équivaut-il à 1 jour ?
Non, et les équipes qui laissent cette équivalence s’installer se retrouvent en général avec une échelle qui n’est plus que des “jours” déguisés. Quand cela arrive, vous avez perdu la comparaison relative qui rendait les points utiles, et gardé tout le surcoût.

Pourquoi les story points sont-ils 1, 3, 5, 8 ?
Parce que la précision de l’estimation se dégrade à mesure que le travail grossit. Les écarts qui s’élargissent empêchent l’équipe de débattre de différences qu’elle ne perçoit pas, et poussent le travail gros et mal compris dans une case qui dit “découpez ça”.

Que valent 5 story points en Agile ?
Environ cinq fois la taille de la plus petite story de référence de l’équipe, complexité, incertitude et volume confondus. Sur la plupart des équipes produit en phase d’amorçage, cela ressemble à un flux autonome avec ses propres états et permissions. Sur votre équipe, c’est ce que dit l’historique de votre équipe.

Puis-je comparer notre vélocité à celle d’une autre entreprise ?
Non. Les points sont calibrés par équipe. Une entreprise à 60 points par sprint n’est pas deux fois plus rapide qu’une entreprise à 30. C’est une autre règle graduée, et la comparaison ne vous apprend rien, sinon que quelqu’un dans la conversation cherche à la gagner.