La mort des story points (et ce qui vient ensuite)

Le culte du cargo de Fibonacci

Les story points sont devenus le culte du cargo de l'ingénierie moderne.

Les équipes attribuent religieusement des nombres de Fibonacci aux tickets. Elles débattent pour savoir si un 3 est vraiment un 5. Elles calculent la vélocité avec une précision décimale. Elles projettent les sprints futurs en fonction des moyennes historiques. Et puis elles se demandent pourquoi leurs prédictions ressemblent à de l'art abstrait.

Voici une vérité inconfortable : les story points ont été conçus pour un monde qui n'existe plus.

La prémisse originale était simple : les développeurs travaillent à des vitesses relativement constantes, donc mesurer la complexité relative (un 5 est environ deux fois plus difficile qu'un 3) devrait produire une vélocité prévisible au fil du temps. Établissez une base de référence, et vous pouvez prévoir avec une précision raisonnable.

Cette prémisse est maintenant brisée.

Pourquoi les story points meurent-ils?

Les story points supposent une unité stable : la même équipe, travaillant de la même manière, à peu près à la même vitesse. L'assistance IA a brisé cette hypothèse de trois façons — les estimations varient maintenant énormément par tâche, la vélocité ne prédit plus la livraison, et les bases de référence historiques ne se transfèrent plus.

Le problème de la variabilité de l'IA

Quand le même développeur peut être 10 fois plus rapide le lundi (avec Copilot, une spécification claire et une base de code familière) que le mardi (aux prises avec un système hérité, déboguant une hallucination IA et changeant de contexte entre trois projets) — que signifie exactement une « story de 5 points »?

Ça ne signifie rien. L'unité de mesure est devenue variable.

Prenons un exemple réel : un développeur estime une fonctionnalité CRUD à 5 points en fonction de la vélocité historique. Avec l'assistance IA, il la complète en 2 heures. La prochaine story de 5 points implique le débogage d'une condition de concurrence dans du code hérité, où l'IA est inutile, et ça prend 3 jours.

Les deux étaient « 5 points ». L'une a pris 2 heures, l'autre 24. Votre graphique de vélocité contient maintenant des points de données qui varient de 12 fois pour la même complexité estimée.

Le problème de la vélocité sans signification

Le rapport DORA de 2024 a révélé que les équipes adoptant des assistants de codage IA ont vu leur débit de livraison diminuer de 1,5 % et leur stabilité de livraison diminuer de 7,2 %¹ : plus d'activité, moins de valeur livrée. La vélocité mesure l'activité plutôt que les résultats, c'est pourquoi les équipes avec une vélocité élevée livrent souvent moins de valeur que les équipes avec une vélocité modérée.

Quand l'IA gonfle les métriques d'activité (plus de commits, plus de PR, plus de stories « complétées »), la vélocité devient du pur bruit. Le nombre augmente, mais personne ne sait ce qu'il signifie.

Le problème de la base de référence historique

L'estimation par story points repose sur la calibration : « Le sprint dernier, nous avons complété 40 points, donc engageons-nous pour 40 ce sprint. » Mais que se passe-t-il quand :

• La moitié de l'équipe vient d'adopter des assistants IA (la vélocité pourrait augmenter)?
• La base de code sur laquelle vous travaillez est inconnue de l'IA (la vélocité pourrait chuter)?
• Votre meilleur estimateur est parti et a emporté sa calibration avec lui?

Les bases de référence historiques supposent la cohérence. L'IA a détruit cette hypothèse.

Qu'est-ce qui remplace les story points?

La mort des story points ne signifie pas la mort de l'estimation. Trois approches fonctionnent à l'ère de l'IA : les expériences limitées dans le temps, les engagements de résultats et la ré-estimation continue.

Approche 1 : Expériences limitées dans le temps

Au lieu d'estimer combien de temps quelque chose prendra, engagez-vous sur ce que vous tenterez dans une période de temps fixe.

L'ancienne façon : « Cette fonctionnalité fait 8 points, ce qui signifie historiquement ~4 jours. »

La nouvelle façon : « Nous passerons 2 jours à explorer cette fonctionnalité. À la fin, nous saurons si nous pouvons la livrer ou si nous avons besoin de plus de temps. »

Cette approche reconnaît l'incertitude dès le départ. Vous ne prétendez pas prédire l'imprévisible — vous vous engagez à apprendre rapidement.

Approche 2 : Engagements de résultats

Au lieu d'estimer l'effort, engagez-vous sur un résultat à une date — et laissez l'équipe déterminer comment y arriver.

L'ancienne façon : « Cette épopée fait 40 points sur 8 stories, donc ça prendra 2 sprints. »

La nouvelle façon : « Nous livrerons l'authentification utilisateur d'ici vendredi. Voici la version minimale viable, voici les objectifs ambitieux, et voici ce que nous couperons si nécessaire. »

Cette approche se concentre sur ce qui compte (les résultats) plutôt que sur les indicateurs indirects (l'effort). Elle crée un alignement sur les priorités et fait ressortir les risques tôt : « Si nous ne pouvons pas faire fonctionner OAuth d'ici mercredi, nous livrerons avec email/mot de passe seulement. »

Approche 3 : Ré-estimation continue

Au lieu d'estimer une fois lors de la planification du sprint et de ne jamais revisiter, mettez à jour les estimations au fur et à mesure que vous apprenez.

L'ancienne façon : « Nous avons estimé 5 points lors de la planification, donc c'est l'estimation. »

La nouvelle façon : « Nous avons estimé 5 points lundi. Mercredi, nous savons que c'est en fait un 8. C'est une information précieuse — mettons à jour nos engagements. »

Cette approche traite l'estimation comme un outil de conversation continue plutôt qu'une prédiction ponctuelle. L'estimation évolue à mesure que les connaissances augmentent.

Comment Planning Poker évolue

Nous avons construit notre outil de Planning Poker pour soutenir ces approches — non pas parce que nous pensons que l'estimation traditionnelle est toujours fausse, mais parce que les équipes ont besoin de flexibilité.

Pour l'estimation traditionnelle

Oui, vous pouvez toujours attribuer des points Fibonacci. Certaines équipes et certains types de travail bénéficient encore de l'estimation relative. Bases de code stables, équipes expérimentées, domaines bien compris — les story points peuvent fonctionner ici.

Mais nous avons ajouté des garde-fous :

• Détection d'anomalies : Les métriques de sprint passent par une détection d'anomalies par z-score, donc quand la vélocité sort de sa plage normale, vous la voyez signalée au lieu d'être enfouie dans une moyenne.
• Suivi planifié versus complété : Les métriques de sprint comparent ce à quoi vous vous êtes engagé avec ce qui a réellement été livré, donc la dérive d'estimation apparaît sprint après sprint au lieu du bilan trimestriel.
• Tendances de résultats, pas de suivi d'outils : Nous ne suivons jamais qui a utilisé l'IA sur quoi. La comparaison sprint après sprint montre si vos estimations deviennent plus ou moins fiables, quelle qu'en soit la cause.

Pour les expériences limitées dans le temps

Au lieu d'attribuer des points, estimez en périodes limitées. L'échelle Temps (Heures) va de 1 heure à 40, et les échelles personnalisées vous permettent de définir vos propres points de contrôle :

• Spike de 2 heures
• Exploration d'une demi-journée
• Prototype d'1 jour

À la fin de la période limitée, l'équipe répond à une question simple : « Pouvons-nous livrer ceci, ou avons-nous besoin de plus de temps? » Cela crée des points de contrôle naturels sans fausse précision.

Pour les engagements de résultats

Les engagements de résultats n'ont pas besoin d'outils spéciaux. Définissez le résultat, fixez une date cible et décomposez en jalons avec des points de contrôle go/no-go. Là où les outils aident, c'est après : le suivi des actions et les scores de santé montrent si l'engagement a été livré et s'est maintenu.

La conversation est l'essentiel

Voici ce que la plupart des équipes ne comprennent pas à propos de l'estimation : l'estimation elle-même n'a pas d'importance. C'est la conversation qui compte.

Quand votre équipe débat pour savoir si quelque chose vaut 3 ou 5, la valeur ne réside pas dans l'atteinte du « bon » chiffre. La valeur réside dans la mise au jour de différentes hypothèses :

• « Je pense que c'est un 3 parce qu'on peut réutiliser le module d'authentification existant. »
• « Je pense que c'est un 5 parce que le module d'authentification existant ne gère pas nos nouvelles exigences. »

Cette conversation a révélé un risque. L'estimation est presque sans importance ; la compréhension partagée est tout.

C'est pourquoi les cérémonies d'estimation restent précieuses même quand les estimations elles-mêmes sont imprécises. L'objectif n'est pas la prédiction. L'objectif est l'alignement.

Communiquer le changement

Si vous êtes convaincu que les story points traditionnels ne fonctionnent pas, vous devrez communiquer cela aux parties prenantes qui s'attendent à des « tableaux de bord de vélocité ». Voici comment :

Pour la direction technique

Présentez-le en termes de prévisibilité, pas de processus. Les dirigeants se soucient de savoir quand les choses seront livrées. Expliquez que la vélocité est devenue peu fiable (montrez la variance), et que vous adoptez des pratiques qui amélioreront réellement la prévisibilité.

Montrez, ne dites pas. Menez une expérience parallèle : suivez la vélocité traditionnelle ET les engagements de résultats pendant deux mois. Laissez les données parler.

Pour les partenaires produit

Concentrez-vous sur ce qui les préoccupe : les dates de livraison. Les gestionnaires de produit ne se soucient pas des story points — ils se soucient de savoir quand les fonctionnalités seront prêtes. Les engagements basés sur les résultats leur donnent de meilleures informations : « On livrera d'ici vendredi » est plus utile que « On a complété 40 points. »

Faites-en une question de détection des risques. La ré-estimation continue fait ressortir les risques plus tôt. C'est ce dont le produit a besoin : un avertissement précoce, pas une fausse confiance.

Pour l'équipe

Reconnaissez le dysfonctionnement. Si les story points sont devenus un rituel vide, l'équipe le sait. L'admettre crée la confiance.

Rendez-le optionnel au départ. Laissez l'équipe expérimenter des alternatives sur quelques stories avant de s'engager dans une transition complète.

L'avenir de l'estimation

Voici où nous nous dirigeons :

Court terme : L'estimation devient adaptative. Les équipes utilisent différentes approches pour différents types de travail : story points pour le travail stable et bien compris ; boîtes de temps pour l'exploration ; engagements de résultats pour les fonctionnalités hautement prioritaires.

Moyen terme : L'IA assiste l'estimation elle-même. En se basant sur les tendances historiques, l'analyse de la complexité du code et des travaux similaires passés, l'IA peut suggérer des estimations — non pas comme vérité, mais comme contribution à la conversation.

Long terme : L'estimation devient moins nécessaire. À mesure que les cycles de déploiement se compriment et que les boucles de rétroaction se resserrent, le besoin de prédiction initiale diminue. Vous saurez si quelque chose est difficile en y travaillant pendant quelques heures, pas en débattant des points lors d'une réunion de planification.

Les story points nous ont bien servis pendant deux décennies. Ils étaient le bon outil pour leur époque. Mais les conditions qui les rendaient utiles ont fondamentalement changé, et nos pratiques doivent changer avec elles.

Ce que cela signifie pour votre équipe

Si vous ressentez un dysfonctionnement des story points, vous n'êtes pas seul. Voici par où commencer :

1. Mesurez la variance de votre vélocité. Si elle fluctue de plus de 25 % d'un sprint à l'autre, vos estimations ne sont pas prédictives ; elles sont du bruit.

2. Essayez une alternative. Choisissez quelques stories au prochain sprint et estimez-les avec des boîtes de temps plutôt que des points. Voyez comment ça se passe.

3. Concentrez-vous sur les résultats. Lors de la planification, demandez « Que voulons-nous qui soit vrai d'ici la fin du sprint ? » plutôt que « Combien de points pouvons-nous compléter ? »

4. Acceptez l'incertitude. La réponse honnête à « Combien de temps cela prendra-t-il ? » est souvent « Je ne sais pas encore — laisse-moi essayer pendant une journée et je t'en dirai plus. »

L'objectif n'a jamais été d'attribuer le bon chiffre. L'objectif était de livrer des logiciels de valeur. Si vos pratiques d'estimation nuisent à cet objectif, il est temps qu'elles évoluent.

Sources