Backlog & agile

Story points : le guide de l'estimation agile

Comprenez les story points : pourquoi des points et pas des jours, Fibonacci, planning poker pas à pas, vélocité, erreurs classiques et alternatives.

Par l’équipe RoadmapHero · Mis à jour le 1 juillet 2026 · 8 min de lecture

L'estimation en story points est la pratique agile la plus utilisée — et la plus détournée. Bien menée, elle donne à l'équipe des prévisions honnêtes sans le marchandage pathologique des deadlines. Mal menée — points convertis en heures, vélocités comparées entre équipes — elle devient un rituel bureaucratique qui ne mesure rien. Ce guide couvre la mécanique, la logique qui la sous-tend, et les modes d'échec à surveiller.

Pourquoi des points et pas des jours

L'humain est mauvais en estimation absolue (« combien de jours ? ») et étonnamment bon en estimation relative (« est-ce plus gros ou plus petit que ça ? »). Les story points exploitent la seconde compétence. Une story n'est pas estimée à « 4 jours » mais à « 5 points — à peu près la taille de la story des filtres de recherche du mois dernier ».

Trois autres raisons pour lesquelles les points battent les jours :

• Les points embarquent l'incertitude. Un story point agrège effort, complexité et inconnues dans un seul nombre. « 3 jours » fait semblant que les inconnues n'existent pas ; « 8 points » dit « gros, en partie parce qu'on n'est pas sûrs ».

• Les points ne dépendent pas de la personne. Un senior fait en un jour ce qu'un junior fait en trois, mais la story a la même taille. Les jours obligent à la question gênante « des jours de qui ? » ; les points l'évitent.

• Les points résistent à la négociation. Un manager peut faire plier « 4 jours » en « 3 jours » — la réalité tranchera plus tard. Faire passer un 8 à 5 ne change rien au travail, et tout le monde le voit.

La suite de Fibonacci expliquée

La plupart des équipes estiment sur une suite de Fibonacci modifiée : 1, 2, 3, 5, 8, 13, 21 (certaines ajoutent ½ et 40/100 comme signal « trop gros pour un sprint »). Les écarts croissants sont le cœur du dispositif : l'incertitude grandit avec la taille. On peut défendre la différence entre un 2 et un 3 ; personne ne peut défendre celle entre un 12 et un 13. L'échelle supprime une précision que vous n'avez pas.

Une calibration pratique, à adapter à votre équipe :

• 1 — trivial et parfaitement compris : changement de wording, flag de config.

• 2–3 — story de routine, terrain connu, zéro inconnue.

• 5 — une vraie story avec quelques pièces mobiles ; le cheval de trait du sprint.

• 8 — grosse ; au moins une inconnue réelle. Envisagez le découpage.

• 13 — le plafond pour un sprint ; découpez sauf impossibilité.

• 21+ — ce n'est pas une story, c'est un epic. À découper avant d'atteindre le haut du backlog.

Ancrez l'échelle avec des stories de référence : choisissez deux ou trois stories passées dont toute l'équipe se souvient et accordez-vous sur leur valeur. Chaque estimation future devient une comparaison avec ces ancres — c'est ce qui rend les points stables dans le temps et d'une session de refinement à l'autre.

Le planning poker pas à pas

1. Le PM présente la story — intention, critères d'acceptation, maquettes. Deux minutes, pas de solutionnisme.

2. Questions de clarification — l'équipe sonde le périmètre et les cas limites. Si les questions n'en finissent pas, la story n'est pas prête : retour au refinement.

3. Chacun choisit sa carte simultanément — cartes physiques ou appli, mais le simultané est non négociable : il empêche l'ancrage sur le chiffre du développeur senior.

4. Révélation, puis débat des extrêmes — le plus bas et le plus haut s'expliquent. C'est là que se crée la valeur : le 2 connaît un raccourci, ou le 13 se souvient de la mine legacy. Le débat fait émerger le savoir caché.

5. On revote une ou deux fois — la convergence est généralement rapide. Si un 5 et un 8 persistent, prenez le 8 et passez : inutile de brûler dix minutes pour trois points de précision.

6. Timeboxez l'ensemble — 5 minutes par story en moyenne. Une session qui estime 12 stories en une heure est en bonne santé.

Vélocité et prévisibilité

La vélocité est le nombre de points terminés par sprint. Après 3-4 sprints, une moyenne glissante se dessine — disons 34, 41, 37 → environ 37 — et ce chiffre devient discrètement votre meilleur outil de prévision :

• Capacité de sprint : embarquez environ 37 points au sprint planning, moins les absences connues.

• Prévision de release : une release cadrée à ~150 points restants est à environ 4 sprints — communiquez une fourchette (3,5 à 5), jamais une date gravée dans le marbre.

• Signal process : une vélocité en montagnes russes (22, 51, 18) révèle en général des interruptions non estimées, des stories trop grosses ou une équipe instable — des problèmes à corriger indépendamment de l'estimation. Reliez ce signal à la planification de capacité pour garder des engagements réalistes.

Ce que la vélocité n'est pas : une métrique de productivité. Elle mesure un débit dans une unité locale à l'équipe. Pousser une équipe à « augmenter sa vélocité » produit un seul résultat — l'inflation des points — et détruit la prévision.

Les erreurs qui cassent les story points

• La table de conversion points → temps. « 1 point = 4 heures » épinglé au wiki transforme les points en jours avec des étapes en plus. Toutes les pathologies de négociation reviennent aussitôt.

• Comparer les équipes à la vélocité. L'équipe A à 60 n'est pas plus rapide que l'équipe B à 30 : elles n'ont pas le même mètre étalon. La comparaison inter-équipes garantit le gaming.

• Négocier les points. Quand une partie prenante fait descendre un 8 à 5, le travail ne rétrécit pas — c'est la prévision qui casse. Les points appartiennent à ceux qui font le travail, point final.

• Estimer en solo. Une personne qui estime pour l'équipe saute la conversation, qui était la vraie valeur. Le chiffre n'est qu'un sous-produit.

• Re-noter les stories terminées. « C'était plus dur que prévu, passe-la à 13 » corrompt l'historique. Gardez l'estimation d'origine ; laissez l'écart instruire la prochaine estimation.

• Estimer les epics en points. Les epics méritent des tailles de t-shirt ou des fourchettes ; un total de points précis sur un chantier de 3 mois est une fiction. Voir notre guide epic vs user story vs tâche pour la bonne granularité à chaque niveau.

Alternatives : t-shirt sizing, #NoEstimates

Le t-shirt sizing (XS–XL)

Plus grossier et plus rapide que les points ; excellent pour les epics, la planification trimestrielle et le tri initial. Beaucoup d'équipes taillent les epics en t-shirts et les stories en points — les deux cohabitent très bien.

#NoEstimates

L'option radicale : découper toutes les stories à peu près à la même petite taille et simplement les compter. Le débit (stories par semaine) remplace la vélocité. Ça fonctionne réellement bien pour des équipes matures avec une forte discipline de découpage et un flux stable — c'est précisément pourquoi c'est un mauvais point de départ : la compétence de découpage qu'elle présuppose est la partie difficile. Chemin raisonnable : maîtrisez d'abord les points, et si vos stories convergent de toute façon vers des 2 et des 3, abandonnez la cérémonie et comptez.

Cycle time et prévision probabiliste

Les équipes orientées Kanban prévoient à partir des temps de cycle historiques (simulation de Monte-Carlo, par exemple), sans aucune réunion d'estimation. Puissant avec assez de données ; opaque pour les parties prenantes sans.

Estimation et coûts dans RoadmapHero

RoadmapHero porte les story points nativement sur les tickets, à côté des coûts estimés et réels — dimensionnement et budget vivent sur le même objet plutôt que dans deux tableurs. Les points alimentent la vue planning pour la capacité des sprints et cycles, et le critère effort du HeroScore fait peser explicitement les estimations dans la priorisation. Quand la réalité dérive, l'agent White Rabbit replanifie automatiquement les tickets en retard, et le ticket health montre où les estimations ratent de façon récurrente. La synchronisation bidirectionnelle avec Jira et Linear garde les points cohérents entre outils. Essai gratuit, tarifs transparents en euros, sans engagement.