# Les story points : estimer le travail sans compter les heures

> Les story points disent la taille d’un travail par rapport aux autres, pas sa durée. Leur origine, comment les utiliser, et quand compter les stories à la place.

Source: https://priortasks.com/fr/guides/story-points/
Last updated: 2026-11-05

Les story points sont un nombre que l’équipe donne à un travail pour dire sa taille par rapport à d’autres travaux. Ils ne mesurent pas des heures. Un 5 est plus gros qu’un 3 et plus petit qu’un 8, et ce que signifie un 5 est fixé par l’équipe qui l’utilise.

## D’où ils viennent

Les story points viennent de l’Extreme Programming. Dans [Story Points Revisited](https://ronjeffries.com/articles/019-01ff/story-points/Index.html), Ron Jeffries, un pionnier de la méthode, raconte comment cela s’est passé. Les équipes XP estimaient d’abord les stories en temps. Puis elles ont utilisé des « jours idéaux », le temps qu’une paire mettrait sans interruption, multipliés par un facteur de charge d’environ trois pour obtenir un temps réel. Les parties prenantes trouvaient ces nombres de jours déroutants, et les équipes ont commencé à les appeler « points ». Jeffries dit qu’il a peut-être inventé le terme et que, si c’est le cas, il le regrette aujourd’hui. *Agile Estimating and Planning* (2005) de Mike Cohn a contribué à répandre la pratique.

Scrum n’exige pas les story points. Le [Guide Scrum](https://scrumguides.org/scrum-guide.html) ne les mentionne pas. Il dit que les développeurs qui feront le travail sont responsables de son estimation, et leur laisse la manière.

## Pourquoi on les utilise

Peu de recherches solides soutiennent les story points. Les raisons que donnent les équipes sont pratiques.

**Comparer est plus facile que prédire.** Il est difficile de dire « cela prend deux jours ». Il est plus simple de dire « c’est à peu près le double de cette autre story ». Une échelle relative permet à une équipe de s’accorder sans se disputer sur des heures.

**La conversion vient de votre propre historique.** Les gens sont optimistes sur leur propre temps. Dans une étude de 1994 de Roger Buehler, Dale Griffin et Michael Ross, des étudiants prévoyaient que leur mémoire de fin d’études prendrait 33,9 jours en moyenne ; il en a pris 55,5 (*Journal of Personality and Social Psychology*). Les points évitent de promettre des heures. Vous additionnez les points que votre équipe a réellement terminés lors des derniers sprints, et ce total, appelé vélocité, vous dit combien prendre la fois suivante.

**Ils couvrent tout le travail de l’équipe et le doute.** Une échelle de points inclut les tests, la relecture et l’inconnu. Plus le nombre est grand, moins il est certain.

Jeffries lui-même déplore aujourd’hui leur mauvais usage et préfère découper les stories jusqu’à ce que chacune soit petite. C’est une alternative légitime, et nous y revenons plus bas.

## Comment les utiliser

1. **Choisissez une story de référence.** Prenez une story terminée, convenez que c’est un 2 ou un 3, et dimensionnez les autres par rapport à elle.
2. **Dimensionnez l’ensemble du travail.** Incluez la conception, la réalisation, les tests et la relecture. Plus de travail, plus de complexité et plus d’incertitude poussent chacun le nombre vers le haut.
3. **Utilisez une échelle limitée.** Des nombres de type Fibonacci (1, 2, 3, 5, 8, 13) obligent à choisir entre « plus gros » et « plus petit » et mettent fin aux discussions sur 6 ou 7.
4. **Fixez un plafond.** Une story au-dessus de 13 est trop grosse pour être planifiée. Découpez-la.
5. **Ne comptez que les stories terminées.** À la fin du sprint, additionnez les points des stories finies. Une story presque finie ne rapporte encore rien.
6. **Planifiez avec la moyenne.** Prenez la moyenne de vos derniers sprints et servez-vous-en comme vélocité.

Voici comment une équipe pourrait voir les choses. « Ajouter une case “se souvenir de moi” » est un 2. « Réinitialiser un mot de passe par e-mail » est un 5, avec l’e-mail, l’expiration et les tests. « Exporter des rapports en PDF avec mise en page » est un 13 et doit probablement être découpé. Si les trois derniers sprints ont terminé 18, 22 et 20 points, l’équipe planifie environ 20.

Utilisez le [planning poker](https://priortasks.com/fr/guides/planning-poker/) pour vous accorder ensemble sur les nombres.

## Les erreurs à éviter

- **Transformer les points en heures.** « Un point, c’est une demi-journée » fait d’une échelle relative une mauvaise horloge.
- **Comparer la vélocité des équipes.** Les points de chaque équipe signifient autre chose. Un nombre plus grand ne veut pas dire que plus de travail a été fait.
- **Juger les personnes à la vélocité.** Quand les points deviennent un objectif, on dimensionne à la hausse pour l’atteindre.
- **Accorder des points partiels.** Comptez une story quand elle est terminée, pas avant.
- **Réestimer après coup.** Changer les nombres une fois le travail fini cache ce que vous apprenez.
- **Laisser chacun avoir sa propre échelle.** La valeur du nombre tient au fait que l’équipe le partage.

## Quand ce n’est pas le bon outil

- **Quand vos éléments ont à peu près la même taille.** Comptez les éléments. Jeffries préfère découper les stories en petits morceaux plutôt que de les dimensionner.
- **Pour des tâches personnelles.** Si vous avez besoin d’une durée, utilisez des minutes.
- **Quand un client paie à l’heure.** Il veut des heures : estimez des heures.
- **Quand les points n’apportent rien.** Jeffries dit de les abandonner s’ils n’aident pas, et de les garder si l’équipe les apprécie.
- **Pour une toute nouvelle équipe.** Sans sprints derrière vous, il n’y a pas de vélocité. Terminez quelques sprints et observez ce que vous achevez.

## Dans Prior

> [!pro] Les story points font partie de la boîte à outils Scrum
> Les projets Scrum et Scrumban demandent Pro sur l’offre du propriétaire du projet. Sans Pro, le projet fonctionne comme un Kanban : le pictogramme de priorité revient et les points sont masqués. Vos données sont conservées et reviennent quand le propriétaire passe à Pro. Voir [Offres et tarifs](https://priortasks.com/fr/docs/account/plans-and-pricing/).

Choisissez **Agile · Scrum** ou **Agile · Scrumban** sous **Type de projet** quand vous créez ou modifiez un projet. Les tâches de ce projet sont alors dimensionnées en points plutôt que par priorité.

- **Définissez les points.** Les détails de la tâche ont une ligne **Points d’effort**, une rangée de cartes : 0, ½, 1, 2, 3, 5, 8, 13 et 21, plus **Effacer**. Le compositeur de tâche a une pastille **Points** avec le même jeu. Une valeur hors du jeu, comme 4, obtient sa propre carte. Les points vont de 0 à 999 par pas de 0,5. L’astuce le dit : « La taille du travail, pas le temps qu’il prend. »
- **Voyez la taille.** Une pastille de points remplace le pictogramme P1 à P4 sur les cartes et les lignes : trois barres, dont une allumée jusqu’à 1 point, deux jusqu’à 3 et trois jusqu’à 13. Au-delà de 13, la pastille affiche un « ! » corail, car la story doit être découpée. Une tâche sans estimation montre des barres vides et affiche **Non estimé**. La priorité reste modifiable.
- **Estimez ensemble.** L’onglet **Planning Poker** inscrit la valeur convenue sur la tâche. Voir le guide du [planning poker](https://priortasks.com/fr/guides/planning-poker/).
- **Découpez ce qui est trop gros.** La table de poker propose **Découper la tâche**, et Prior AI propose les morceaux si votre compte a Pro. Voir [Découper une story](https://priortasks.com/fr/docs/agile/split-a-story/).

Dans un projet Scrum, les cycles deviennent des **Sprints**. Chaque carte de sprint affiche la progression, par exemple « 13 pts sur 21 terminés », et le nombre de tâches « non estimées », et l’éditeur de sprint montre les points que vous avez engagés. Le résumé **Vélocité** au-dessus des cartes est la moyenne des points terminés lors des trois derniers sprints finis, arrondie à une décimale. Tant qu’un sprint n’est pas terminé, il affiche « Terminez un sprint pour voir votre vélocité ».

Les points sont conservés quand vous remettez un projet en Kanban ou en Standard. Ils sont masqués, pas effacés. Ils voyagent aussi avec la synchronisation, l’export de données et les outils MCP, et une estimation numérique de Linear devient des story points à l’import. Pour la référence complète, voir [Story points](https://priortasks.com/fr/docs/agile/story-points/) et [Cycles et sprints](https://priortasks.com/fr/docs/agile/cycles-and-sprints/).