Les Story Points sont l'unité d'estimation la plus utilisée dans les équipes agiles et Scrum. Ils permettent d'évaluer l'effort d'une User Story de manière relative, en tenant compte de la complexité, du volume de travail et de l'incertitude. Ce guide est conçu pour devenir la référence francophone sur les Story Points : définition, avantages sur l'estimation en heures, échelle de Fibonacci, Planning Poker, erreurs fréquentes et pièges du PSM I.
Qu'est-ce qu'un Story Point ?
Un Story Point est une unité relative d'estimation utilisée pour mesurer l'effort nécessaire à la réalisation d'une User Story ou d'un Product Backlog Item. Contrairement à une estimation en heures, un Story Point ne mesure pas une durée, mais un effort combiné.
Un Story Point agrège trois dimensions :
- La complexité — algorithmes, dépendances, cas particuliers.
- La quantité de travail — le volume brut à produire.
- L'incertitude / le risque — inconnu technique, dépendances externes.
Pourquoi Scrum (et l'agilité) utilise les Story Points
L'estimation en heures est intuitive… mais trompeuse. Un développeur senior mettra 2h là où un junior en mettra 6. Les interruptions, les réunions, la fatigue font varier la durée réelle du simple au triple. Les Story Points contournent ce problème :
- ils décrivent la taille du travail, pas la durée ;
- ils sont indépendants de la personne qui fait le travail ;
- ils s'appuient sur la vélocité pour prévoir empiriquement ;
- ils obligent l'équipe à discuter ce qui rend une story complexe.
Les avantages de l'estimation relative
L'être humain est très mauvais pour estimer en absolu (« combien de temps pour développer ce module ? ») mais bon pour comparer (« est-ce plus gros que la story A que nous avons faite la semaine dernière ? »). C'est le fondement de l'estimation relative.
| Critère | Estimation en heures | Estimation relative (Story Points) |
|---|---|---|
| Dépend de la personne | Oui (senior vs junior) | Non |
| Influencée par les interruptions | Oui | Non |
| Se prête à la vélocité | Difficilement | Naturellement |
| Rapidité d'estimation | Lente | Rapide |
| Discussion collective | Rare | Systématique (Planning Poker) |
| Contrat vs conversation | Souvent perçu comme contrat | Reste une prévision |
Story Points vs heures
« Combien vaut 1 Story Point en heures ? » — c'est la question la plus fréquente… et la plus dangereuse. Convertir points en heures détruit l'intérêt de l'estimation relative.
| Aspect | Heures | Story Points |
|---|---|---|
| Nature | Durée absolue | Effort relatif |
| Universalité | Universelles (1h = 1h) | Spécifiques à l'équipe |
| Sensibilité aux compétences | Forte | Nulle |
| Prévisibilité | Faible (aléas quotidiens) | Bonne (vélocité empirique) |
| Effet sur le débat d'équipe | Débat sur le « qui » | Débat sur le « quoi » |
| Risque de contrat implicite | Élevé | Faible |
L'échelle de Fibonacci
La suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34…) est l'échelle la plus répandue pour les Story Points. Chaque terme est la somme des deux précédents, ce qui produit des écarts croissants. Cette propriété est un choix conscient : plus une story est grosse, plus notre capacité à l'estimer précisément décroît.
Change de config, texte, correction mineure.
Petit formulaire, ajout d'un champ, règle simple.
Écran CRUD standard, sans dépendance.
Fonctionnalité classique, quelques dépendances.
Intégration tierce, plusieurs cas d'erreur.
Story à découper — beaucoup d'inconnues.
Presque toujours un Epic à découper.
L'écart croît volontairement : au-delà de 8, l'incertitude devient trop grande pour une estimation fiable — la story doit être découpée.
Certaines équipes ajoutent 0 (rien à faire), ½ (quasi-trivial) et ? (« je ne peux pas estimer, il me faut plus d'informations »). C'est parfaitement valide.
Le Planning Poker
Le Planning Poker, formalisé par Mike Cohn en 2005, est la technique d'estimation collective la plus utilisée en Scrum. Chaque Developer choisit sa carte Fibonacci simultanément et à l'insu des autres, puis toutes les cartes sont révélées en même temps.
- Le Product Owner présente la User Story.
- Les Developers posent des questions pour clarifier.
- Chacun choisit sa carte Fibonacci en secret.
- Révélation simultanée — pas d'effet d'ancrage.
- Les écarts (min ↔ max) sont discutés.
- Un nouveau tour est joué jusqu'au consensus.
Story : « En tant qu'admin, je veux inviter des utilisateurs par email en masse, afin d'ouvrir un accès rapidement. »
« Je vois juste un CRUD simple. »
« Il faut intégrer le SSO SAML, c'est compliqué. »
« 5 me semble raisonnable si le SSO existe déjà. »
« Idem, dépend du niveau de tests exigé. »
Comment estimer une User Story
- Choisir une story de référence déjà réalisée, à laquelle l'équipe attribue par convention 2, 3 ou 5 points.
- Pour chaque nouvelle story, se demander : « Est-elle plus grosse ou plus petite que la référence, et de combien ? »
- Ne pas estimer en isolation — utiliser le Planning Poker.
- Si une story dépasse 13 points, la découper — inutile de débattre entre 21 et 34.
- Ne jamais convertir en heures publiquement.
Cliquez sur chaque story pour révéler l'estimation typique d'une équipe expérimentée (référence : story de 3 points ≈ un écran CRUD simple).
Ajouter un champ « téléphone » au profil
Filtre multi-critères sur la liste des factures
Intégrer un paiement Apple Pay
Refondre entièrement le module d'authentification
Rappel : les valeurs ne sont valables que relativement à la référence de votre équipe. 5 points chez vous ≠ 5 points ailleurs.
Exemples concrets d'estimation
| Story Points | Nature typique | Exemple |
|---|---|---|
| 1 | Trivial, aucune inconnue | Corriger une faute de frappe sur un email transactionnel |
| 2 | Très simple | Ajouter un champ optionnel « téléphone » au profil utilisateur |
| 3 | Standard sans dépendance | Écran de liste avec pagination |
| 5 | Fonctionnalité classique | Filtre multi-critères sur un tableau |
| 8 | Intégration tierce | Ajouter le paiement Apple Pay |
| 13 | Beaucoup d'inconnues | Refonte du parcours d'onboarding |
| 21 | Trop gros — à découper | Refondre entièrement le module d'authentification |
Les erreurs fréquentes
- Convertir points en heures — détruit l'estimation relative.
- Laisser le PO ou le SM estimer — c'est le rôle exclusif des Developers.
- Estimer story par story sans référence — sans point d'ancrage, les valeurs dérivent.
- Comparer les vélocités entre équipes — pousse à l'inflation des estimations.
- Faire de la vélocité un objectif de performance — l'équipe apprend à « gonfler » ses estimations.
- Ne pas ré-estimer quand la connaissance change — le refinement doit rester vivant.
- Estimer en Sprint Planning au lieu du refinement — mange le timebox.
- Débattre entre 12 et 13 points — au-delà de 8, la story doit être découpée.
- Ignorer les tests et la Definition of Done dans l'estimation — la story ne sera jamais « Done ».
- Additionner les Story Points pour prévoir une date exacte — c'est une prévision, pas un engagement.
Les Story Points dans Scrum
Le Scrum Guide 2020 ne mentionne ni les Story Points, ni Fibonacci, ni le Planning Poker. Scrum définit un cadre minimaliste : rôles, événements, artefacts, engagements. L'estimation est considérée comme une pratique complémentaire, laissée à l'équipe.
Ce que Scrum dit néanmoins :
- Les Product Backlog Items doivent être ordonnés et transparents.
- La taille (« size ») des PBI est un attribut typique — le format (points, heures, T-shirt…) n'est pas imposé.
- Les Developers sont responsables de la taille des éléments.
- Le raffinement se fait pendant le Product Backlog Refinement.
Story Points et PSM I : les pièges les plus fréquents
Questions type examen PSM I
Ressources et maillage
Pour aller plus loin
Pages à venir dans le cluster « Estimation Agile » (bientôt disponibles) : Planning Poker — guide complet et variantes ; Velocity — calcul, usages, anti-patterns ; Relative Estimation — techniques et bonnes pratiques ; Fibonacci Scrum — pourquoi cette échelle ; Story Points vs heures — comparatif détaillé ; Estimation Agile — panorama des techniques.