Qu'est-ce qu'un story point ?

L'unité de mesure mystérieuse de l'agilité. Ni heure, ni jour, ni kilogramme… et pourtant tout le monde en parle.

Qu'est-ce qu'un story point ?

Un story point est une unité relative que les équipes agiles utilisent pour estimer l'effort nécessaire à la réalisation d'une user story. Il combine trois facteurs : la complexité (la difficulté du travail), le volume (la quantité de travail) et l'incertitude (ce qu'on ignore encore). Un story point n'est pas une heure : une story à 2 points demande environ deux fois plus d'effort qu'une story à 1 point, mais personne ne s'engage sur une durée. La plupart des équipes piochent leurs valeurs dans une suite de Fibonacci modifiée (1, 2, 3, 5, 8, 13, 21), car les écarts croissants traduisent une incertitude croissante. Chaque équipe étalonne sa propre échelle sur une story de référence : 5 points chez l'une ne valent donc pas 5 points chez une autre. Nés dans les équipes Extreme Programming, les story points ont été popularisés par le livre de Mike Cohn Agile Estimating and Planning (2005). Additionnés sur un sprint, ils donnent la vélocité de l'équipe, qui sert à planifier les releases.

Les story points sont l'unité utilisée par la plupart des méthodes présentées dans notre guide des techniques d'estimation agile pour le sprint planning.

D'où viennent les story points ?

Les story points sont nés dans les équipes Extreme Programming (XP). Dans son article Story Points Revisited (2019), Ron Jeffries raconte que ces équipes estimaient d'abord en « jours idéaux », multipliés ensuite par un facteur de charge (souvent autour de trois) pour obtenir un temps calendaire. Les parties prenantes confondaient sans cesse jours idéaux et jours réels : l'équipe s'est donc mise à parler de « points ». Jeffries en plaisante aujourd'hui : il a peut-être inventé les story points et, si c'est le cas, il le regrette un peu.

Mike Cohn en a ensuite fait une pratique courante avec son livre Agile Estimating and Planning (Prentice Hall, 2005), qui associe story points, Planning Poker et vélocité.

À noter : Scrum n'impose pas les story points. Le Scrum Guide ne les mentionne jamais. Il précise seulement que les Developers qui feront le travail sont responsables de son dimensionnement. Les story points sont une façon répandue de le faire, pas un artefact Scrum officiel.

Que mesure vraiment un story point ?

Mike Cohn définit le story point comme l'effort nécessaire pour réaliser un élément du backlog, et détaille ce qui compose cet effort :

• Le volume : la quantité de travail. Mettre à jour 200 clés de traduction est simple, mais long.
• La complexité : la difficulté technique. Une nouvelle règle de tarification qui touche cinq services reste difficile, même si le code à modifier est court.
• L'incertitude : ce qu'on ne sait pas encore. Brancher un prestataire de paiement que l'équipe n'a jamais utilisé comporte un risque, quelle que soit la taille du code.

Ces trois facteurs se résument en un seul nombre. Le mot-clé, c'est « relatif » : on ne mesure pas une durée, on compare des tailles. Si une story A vaut 2 points et une story B en vaut 4, B devrait demander environ deux fois plus d'effort que A.

La plupart des équipes expriment ces points sur une échelle de Fibonacci, dont les écarts croissants reflètent l'incertitude des grosses stories.

Combien d'heures vaut un story point ?

Aucune réponse fixe, et c'est voulu. Dans Don't Equate Story Points to Hours, Mike Cohn montre que le lien entre points et heures est une distribution, pas un taux de conversion. Dans son exemple, un point représente environ 2 heures pour un développeur expérimenté, 8 heures pour un junior et 3,2 heures en moyenne pour l'équipe.

Figer « 1 point = 4 heures » détruirait ce qui fait l'intérêt des story points : deux personnes au rythme différent ne pourraient plus s'accorder sur une estimation. Notre comparatif story points vs jours-homme détaille ces arbitrages.

Comment estimer en story points ?

1. Choisir des stories de référence. Cohn conseille de partir de deux stories bien connues de l'équipe, idéalement un 2 et un 5, plutôt que d'une seule story à 1 point : un 1 ne laisse aucune place aux éléments plus petits, et il cite des travaux de Magne Jørgensen selon lesquels une petite référence tend à tirer les estimations vers le bas (source).
2. Comparer plutôt que calculer. Pour chaque nouvelle story : plus grosse ou plus petite que le 2 ? Plus proche du 5 ou d'un 8 ?
3. Voter en même temps. Avec le Planning Poker, chacun choisit sa carte en secret et tout le monde révèle ensemble, ce qui évite que la voix la plus expérimentée oriente les autres.
4. Discuter des écarts. Un 2 et un 13 sur la même story signifient que l'équipe ne la comprend pas de la même façon. Cette discussion vaut plus que le chiffre.

Notre guide pour estimer un ticket agile couvre la préparation en amont.

Qu'est-ce que la vélocité, et quel lien avec les story points ?

La vélocité, c'est le nombre de story points qu'une équipe termine par sprint. Seules les stories vraiment terminées comptent : pas de points partiels pour une story finie à 90 %. En moyenne sur plusieurs sprints, la vélocité indique ce que l'équipe peut raisonnablement embarquer au sprint suivant et combien de sprints un backlog va demander. Avec 20 points par sprint en moyenne, une release de 100 points est à environ cinq sprints. Notre guide de la vélocité en Scrum détaille le calcul et la prévision en fourchette.

La vélocité est un outil de planification, pas une note de performance. Voir le guide Atlassian sur les métriques agiles pour approfondir.

Ron Jeffries est catégorique : comparer des équipes sur leur vélocité est néfaste. Chaque équipe étalonne sa propre échelle, donc une équipe à 40 points n'est pas « deux fois plus productive » qu'une équipe à 20.

Quelles sont les erreurs les plus courantes ?

• Convertir les points en jours. « C'est un 5 parce que ça prendra 5 jours » ramène les points à des heures, avec tous les problèmes vus plus haut.
• Comparer les équipes entre elles. Les points n'ont de sens qu'au sein de l'équipe qui les a produits.
• Faire de la vélocité un objectif. Si elle doit absolument augmenter, les estimations gonflent et l'indicateur ne veut plus rien dire.
• Estimer seul. L'estimation d'un unique expert cache les angles morts qu'un vote collectif fait apparaître.
• Garder des stories géantes. Un 21 est généralement le signal qu'il faut découper avant le sprint planning.

Questions fréquentes

Un story point correspond-il à une journée de travail ? Non. Un story point n'a pas de durée fixe. Mike Cohn montre que le nombre d'heures derrière un point varie d'une personne à l'autre et forme une distribution. Une équipe qui assimile un point à une journée estime en jours déguisés et perd l'intérêt des story points : une estimation indépendante de qui réalise le travail.

Peut-on comparer les story points de deux équipes ? Non. Chaque équipe étalonne ses story points sur ses propres stories de référence : un 5 chez l'une peut valoir un 3 ou un 8 chez l'autre. Comparer leurs vélocités n'a donc aucun sens, et Ron Jeffries juge même la pratique néfaste. Une équipe se compare uniquement à ses propres sprints passés.

Qui estime les story points en Scrum ? Ce sont les développeurs qui réaliseront la story qui l'estiment en story points. Le Scrum Guide précise que les Developers qui font le travail sont responsables de son dimensionnement. Le Product Owner explique le besoin et répond aux questions, mais ne vote généralement pas, pour ne pas orienter l'estimation de l'équipe.

Quelle est la valeur maximale d'une story en story points ? Il n'existe pas de maximum officiel, mais une règle courante fixe à 13 la limite d'une story qui entre en sprint. Une story estimée à 21 points ou plus cache en général trop d'incertitude : mieux vaut la découper en stories plus petites avant que l'équipe ne s'engage dessus.

Sources

• Mike Cohn, What Are Story Points?, Mountain Goat Software
• Mike Cohn, Don't Equate Story Points to Hours, Mountain Goat Software
• Mike Cohn, The Best Way to Establish a Baseline When Playing Planning Poker, Mountain Goat Software
• Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005
• Ron Jeffries, Story Points Revisited, 2019
• Ken Schwaber et Jeff Sutherland, The Scrum Guide, 2020

Passez aux story points

Prêt à estimer vos prochaines stories ? Créez une session Planning Poker gratuite, partagez le lien et laissez votre équipe voter en story points en même temps. Sans inscription. Découvrez toutes les fonctionnalités, de l'échelle de Fibonacci à l'export CSV et PDF.