Mon article en bref
Un story point est une unité de mesure relative qui exprime l’effort nécessaire pour réaliser une user story : sa complexité, son volume et son incertitude — jamais une durée. C’est l’outil d’estimation le plus répandu dans les équipes Scrum, et aussi le plus mal utilisé.
Voici les points essentiels à retenir :
- Définition : une unité sans dimension, qui n’a de sens que par comparaison avec les autres items du backlog.
- Ce qu’elle mesure : complexité + volume de travail + incertitude, les trois en même temps.
- Échelle : la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21) domine, parce que l’écart grandit avec l’imprécision.
- Méthode : on choisit une story de référence, puis on estime en équipe, généralement en planning poker.
- Vélocité : le nombre de points terminés par sprint. Elle sert à prévoir, pas à mesurer une performance.
- Conversion en jours-homme : techniquement possible, mais elle détruit l’intérêt de la méthode.
Un story point est une unité de mesure utilisée en agile pour estimer l’effort que représente une user story, sans jamais l’exprimer en heures ni en jours. Contrairement à une estimation classique, il ne décrit pas une durée mais une taille relative : une story à 5 points demande environ cinq fois plus d’effort qu’une story à 1 point, quelle que soit la personne qui la prendra en charge.
C’est cette bascule — de la durée vers la taille — qui rend la méthode puissante, et c’est aussi ce qui la rend contre-intuitive. Voyons en détail ce qu’un story point mesure réellement, comment l’estimer en équipe avec la suite de Fibonacci, comment en tirer une vélocité exploitable, et pourquoi la conversion en jours-homme est le piège le plus courant.
Sommaire
Qu’est-ce qu’un story point ? Définition en agile
Le story point, ou point de story, est une unité de mesure sans dimension qui exprime la taille d’un élément du backlog produit. Elle n’a aucune valeur absolue : un point ne vaut ni une heure, ni une demi-journée, ni un quelconque montant fixe. Sa seule signification vient de la comparaison avec les autres items du backlog de la même équipe.
Cette absence de dimension est délibérée. Elle règle un problème que l’estimation en temps ne sait pas résoudre : la même tâche ne prend pas la même durée selon qui s’en occupe. Un développeur qui connaît le module ira trois fois plus vite qu’un arrivant. En estimant la taille plutôt que la durée, l’estimation cesse de dépendre de la personne assignée.
Les trois dimensions qu’un point recouvre
Un story point n’est pas un simple indicateur de « grosseur ». Il agrège trois dimensions que l’équipe évalue simultanément :
- La complexité — la difficulté technique ou fonctionnelle. Une story peut être courte à écrire et redoutablement complexe à concevoir.
- Le volume de travail — la quantité brute de choses à faire. Dupliquer un formulaire sur douze écrans n’est pas complexe, mais c’est long.
- L’incertitude — ce que l’équipe ne sait pas encore. Une dépendance externe, une techno jamais utilisée, un besoin flou font monter l’estimation même si le travail semble modeste.
C’est la raison pour laquelle deux stories de durée comparable peuvent recevoir des points très différents. Celle dont les critères d’acceptation sont flous porte une incertitude que l’autre n’a pas.
Ce que le Guide Scrum dit — et ne dit pas
Point souvent ignoré, y compris par des équipes expérimentées : le Guide Scrum ne prescrit nulle part les story points. Le Guide Scrum 2020 indique que les Developers sont responsables du dimensionnement des éléments du Product Backlog, sans imposer aucune unité. Les story points sont une pratique largement adoptée, popularisée notamment par Mike Cohn et les premières équipes Extreme Programming — pas une règle du framework.
💡 À retenir — une équipe qui estime en t-shirt sizing, en journées idéales ou qui ne chiffre pas du tout ses items ne fait pas « mal » du Scrum. Elle a choisi une autre convention de dimensionnement, ce que le framework autorise explicitement.
Pourquoi estimer en story points plutôt qu’en heures ?
L’estimation en heures ou en jours-homme échoue pour une raison structurelle : elle demande à une équipe de prédire une durée alors qu’elle ne maîtrise ni les interruptions, ni les réunions, ni les imprévus techniques. Le résultat est connu — des estimations optimistes, systématiquement dépassées, puis une pression sur les personnes plutôt que sur le périmètre.
Les points déplacent la question. On ne demande plus « combien de temps ça prendra », mais « est-ce plus gros que cette story-là, que nous avons déjà livrée ». Or les humains sont bien meilleurs pour comparer que pour prédire dans l’absolu, et c’est tout le pari de la méthode.
Une équipe se trompe systématiquement en prédisant des durées, mais reste remarquablement fiable pour dire qu’une story est deux fois plus grosse qu’une autre.
Trois bénéfices concrets en découlent :
- Une estimation collective — le chiffre n’appartient plus à la personne qui prendra la story, mais à l’équipe qui s’accorde sur une taille.
- Un chiffrage beaucoup plus rapide — comparer va plus vite que décomposer en tâches et additionner des heures.
- Un engagement dépersonnalisé — ce n’est plus « je te promets 12 heures », c’est « cette story est de cette taille-là ».
| Critère | Story points | Estimation en heures |
|---|---|---|
| Nature de la mesure | Taille relative | Durée absolue |
| Dépend de la personne | Non | Oui |
| Prend en compte l’incertitude | Oui, explicitement | Rarement |
| Vitesse d’estimation | Rapide (comparaison) | Lente (décomposition) |
| Comparable entre équipes | Non | En théorie oui |
| Usage principal | Prévoir un horizon | Planifier une tâche précise |
La dernière ligne mérite d’être soulignée : les points d’une équipe ne sont pas comparables à ceux d’une autre. Une équipe qui livre 40 points par sprint n’est pas « meilleure » qu’une équipe à 20 points, elle a simplement calibré son échelle autrement. Comparer les vélocités de deux équipes est l’un des détournements les plus fréquents de l’outil.
Comment estimer en story points ?
L’estimation en points suit une séquence assez stable, quelle que soit l’équipe. Elle se déroule pendant le backlog refinement, en amont du sprint planning, et jamais par une seule personne.
Étape 1 : choisir une story de référence
Tout part d’un étalon. L’équipe sélectionne une story déjà livrée, bien comprise de tous, plutôt petite, et lui attribue une valeur basse — souvent 2 ou 3 plutôt que 1, pour garder de la marge vers le bas. Toutes les estimations suivantes se feront par comparaison à cet étalon.
Étape 2 : utiliser la suite de Fibonacci
L’échelle la plus répandue est une suite de Fibonacci adaptée : 1, 2, 3, 5, 8, 13, 21. Son intérêt n’est pas mathématique mais psychologique : l’écart entre deux valeurs grandit à mesure que la taille augmente, ce qui reflète exactement la façon dont notre précision se dégrade. Distinguer une story de 1 point d’une story de 2 est facile ; prétendre distinguer 20 de 21 est illusoire, et l’échelle vous en empêche.
Une valeur haute — 13, 21 — n’est d’ailleurs pas vraiment une estimation : c’est un signal. Elle indique que l’item est trop gros ou trop flou pour entrer dans un sprint, et qu’il faut le découper. À ce stade, on parle plutôt d’une epic que d’une user story prête.
Étape 3 : estimer en équipe, en planning poker
La technique dominante reste le planning poker : chacun choisit sa carte en silence, tout le monde la retourne en même temps, et l’on discute les écarts. Le mécanisme du dévoilement simultané est essentiel — il empêche l’ancrage sur le premier chiffre énoncé, et surtout sur celui du profil le plus senior.
L’écart entre deux cartes est en réalité plus utile que le chiffre final. Quand un développeur annonce 2 et un autre 13, la valeur du moment n’est pas la moyenne : c’est la conversation qui révèle que l’un a vu une dépendance que l’autre ignorait.
En vidéo : les story points expliqués pas à pas (chaîne Agitips).
Combien de story points par sprint ? Vélocité et capacité
La vélocité est le nombre de story points réellement terminés — au sens de la definition of done — sur un sprint. C’est le seul chiffre qui donne de la valeur prédictive aux points : une fois la vélocité moyenne connue sur trois à cinq sprints, l’équipe peut estimer combien de sprints un lot de backlog représente.
Il n’existe aucun « bon » nombre de points par sprint. La valeur dépend de l’échelle choisie, de la taille de l’équipe et de la durée du sprint. Ce qui compte, c’est la stabilité de la série, pas son niveau. Une vélocité qui oscille entre 18 et 22 est bien plus exploitable qu’une vélocité qui monte de 15 à 45 en trois sprints.
Calculateur de capacité de sprint
Combien de sprints pour votre backlog ?
Estimation indicative à partir de votre vélocité moyenne observée.
Une vélocité n’est fiable qu’après 3 à 5 sprints, et cette projection suppose un périmètre stable. Traitez-la comme un ordre de grandeur, jamais comme un engagement de date.
Trois dérives à éviter
- Faire de la vélocité un objectif — dès qu’elle devient une cible, l’équipe gonfle ses estimations. Le chiffre monte, la valeur livrée non.
- Comparer les équipes entre elles — les échelles sont propres à chaque équipe, la comparaison n’a aucun sens.
- Compter les stories partiellement terminées — un item non « done » vaut zéro point dans le sprint. Sinon la vélocité perd toute valeur prédictive.
Peut-on convertir des story points en jours-homme ?
C’est la question qui revient dans toutes les organisations habituées à raisonner en jours-homme, souvent portée par le contrôle de gestion ou par un client au forfait. La réponse honnête est nuancée : c’est arithmétiquement possible, et méthodologiquement contre-productif.
Possible, parce qu’une vélocité stable donne mécaniquement un ratio. Une équipe de 5 personnes qui livre 20 points sur un sprint de 2 semaines a consommé environ 50 jours-homme, soit 2,5 jours-homme par point. Ce ratio existe, il est observable.
Contre-productif, parce que l’afficher fait disparaître tout ce qui justifiait la méthode. Dès que l’équipe sait qu’un point vaut 2,5 jours, elle recommence à estimer des durées — avec une étape de conversion en plus. L’incertitude, qui était intégrée au point, redevient invisible. Et le ratio, valable en moyenne sur un trimestre, devient faux appliqué à une story isolée.
⚠️ Important — si un engagement contractuel exige des jours-homme, mieux vaut assumer une estimation en jours-homme dès le départ, avec une marge explicite, plutôt que d’entretenir une double comptabilité qui affaiblit les deux systèmes.
Le compromis que j’ai vu fonctionner consiste à ne jamais communiquer un ratio par point, mais à répondre en horizon de sprints : « ce périmètre représente 4 à 6 sprints ». L’interlocuteur obtient sa projection de calendrier, et l’équipe conserve une échelle qui intègre l’incertitude. Pour aller plus loin sur le cadre général, l’article sur la méthode Scrum et celui sur les artefacts Scrum replacent l’estimation dans l’ensemble du dispositif. Mike Cohn, qui a largement contribué à diffuser la pratique, développe le même raisonnement dans ses écrits sur les story points.
FAQ — Tout savoir sur les story points
Story points, c’est quoi exactement ?
Un story point est une unité de mesure relative qui exprime l’effort nécessaire pour réaliser un élément du backlog, en combinant sa complexité, son volume de travail et son incertitude. Il ne correspond à aucune durée fixe et n’a de sens que comparé aux autres items estimés par la même équipe.
Combien de jours représente un story point ?
Aucun nombre de jours par défaut. Une équipe peut observer a posteriori un ratio moyen à partir de sa vélocité, mais ce ratio lui est propre, varie dans le temps et n’est pas applicable à une story isolée. Publier une équivalence en jours annule l’intérêt de l’estimation relative.
Pourquoi utiliser la suite de Fibonacci pour les story points ?
Parce que les écarts entre valeurs s’élargissent à mesure que la taille augmente, ce qui correspond à la perte de précision de l’estimation. La suite empêche les débats stériles sur des différences que personne ne sait réellement percevoir, comme 20 contre 21.
Qui estime les story points dans une équipe Scrum ?
Les Developers, c’est-à-dire les personnes qui réaliseront le travail. Le Product Owner apporte le contexte métier et répond aux questions, mais il n’attribue pas les points. Ni le Scrum Master ni le management ne décident de l’estimation.
Combien de story points une équipe doit-elle livrer par sprint ?
Il n’existe pas de valeur cible. Le nombre dépend de l’échelle de l’équipe, de son effectif et de la durée du sprint. Ce qui importe est la régularité de la vélocité sur plusieurs sprints, car c’est elle qui permet de prévoir un horizon de livraison.
Les story points sont-ils obligatoires en Scrum ?
Non. Le Guide Scrum 2020 demande que les éléments du Product Backlog soient dimensionnés, sans imposer d’unité. Les story points sont la convention la plus répandue, mais le t-shirt sizing ou les journées idéales sont des alternatives parfaitement conformes au framework.
Quelle différence entre story points et planning poker ?
Le story point est l’unité de mesure, le planning poker est la technique d’animation qui permet à l’équipe de s’accorder sur cette mesure. On peut estimer en points sans planning poker, par exemple en affinity estimation, en regroupant les stories par taille comparable.
