Que sont les « story points » ? Une estimation de l'effort, et non du temps

Les points de story mesurent l’effort relatif d’une tâche (sa taille, sa complexité et son degré d’incertitude regroupés en un seul chiffre), et non le nombre d’heures qu’elle prendra. Vous évaluez la taille d’un élément du backlog par rapport à une story de référence que l’équipe a déjà livrée (« celle-ci est environ deux fois plus grande que celle-là ») au lieu d’estimer sa durée. C’est ce simple changement qui permet à l’estimation de résister à l’épreuve de la réalité.

Pourquoi mesurer l’effort plutôt que le temps ?

Une équipe qui établit ses estimations en heures en réalité en propose deux : celle à laquelle se fie l’ingénieur senior, et celle que l’ingénieur junior consigne après avoir arrondi le chiffre à la hausse pour donner l’impression d’être sérieux. On a du mal à se fier aux estimations du type « combien de temps cela va-t-il prendre ? », mais on est étonnamment doué pour juger si « cela représente un volume de travail supérieur à ce que nous avons terminé lors du dernier sprint ». Les points d’histoire s’appuient sur ce second critère.

Le dimensionnement relatif permet à l’équipe de s’accorder sur le fait qu’un élément est plus important qu’un autre sans que quiconque ne s’engage sur un nombre d’heures, ce qui permet d’éviter les biais d’ancrage et d’ancienneté que suscitent les estimations en heures. Le chiffre obtenu ne correspond pas à une durée, mais à une position sur une échelle commune.

Évaluer l’effort plutôt que le nombre d’heures permet d’éviter trois problèmes qui affectent systématiquement les estimations basées sur les heures :

• Une estimation n’est pas un engagement. L’expression « heures » incite les parties prenantes à considérer ces « 8 heures » comme une promesse ; les points permettent de considérer l’estimation comme une prévision.
• Une même tâche prend plus ou moins de temps selon les personnes. Un point reflète le travail accompli, et non la personne.
• La durée ne tient pas compte du risque. Une tâche courte mais incertaine peut s’avérer plus risquée qu’une tâche longue et bien maîtrisée ; c’est pourquoi les points prennent en compte cette incertitude.

L’échelle et la fonction des points

La plupart des équipes votent selon une échelle de type Fibonacci, 1, 2, 3, 5, 8, 13, lors d’une session de planning poker. Les écarts s’élargissent volontairement : plus la tâche est importante, moins on en sait réellement ; l’échelle cesse donc de prétendre qu’il est possible de distinguer un 9 d’un 10. Additionnez les points obtenus par une équipe à la fin de chaque sprint et vous obtiendrez la vélocité, le résultat que les points de prévision sont censés produire.

Si un élément dépasse environ la valeur 13, cela signifie généralement que l’échelle vous invite à le diviser en parties que l’équipe pourra comprendre et mener à bien en un seul sprint.

Pour une première estimation plus rapide et moins précise, certaines équipes classent l’ensemble du backlog selon les tailles de t-shirt et ne convertissent en points que le travail à court terme, une fois celui-ci affiné.

Lors d’une partie de « planning poker », tout le monde dévoile sa carte en même temps, ce qui évite que l’on se laisse influencer par la voix la plus forte ou par celle d’un supérieur hiérarchique. Lorsque les estimations haute et basse divergent, les deux personnes concernées expliquent leur raisonnement, et cette discussion, qui met en lumière les hypothèses et la complexité sous-jacente derrière le chiffre, a généralement plus de valeur que le chiffre lui-même. Le guide complet du planning poker présente les mécanismes de ce jeu.

Le principal facteur d’échec réside dans le fait que l’équipe commence à reconvertir les points en heures. Dès que ce tableau de conversion est publié sur le wiki, toutes les discussions relatives à l’estimation se réduisent à un débat sur la durée, et la notion d’effort relatif disparaît.

Quelle œuvre devriez-vous mettre en avant ?

Deux questions reviennent systématiquement lors de chaque réunion de précision : est-ce que cela rapporte des points, et si oui, combien ? L’échelle sert justement à déterminer le « combien ». Quant à la question « est-ce que cela rapporte des points ? », il existe une règle empirique : attribuez des points à tout ce que l’équipe livre dans le cadre de son travail engagé, afin que l’indicateur de vélocité reflète la répartition réelle de la capacité.

Bugs

Un bug dont la cause est connue et pour lequel il existe une solution claire constitue une story. Elle dispose de critères d’acceptation (« le formulaire n’accepte plus les quantités négatives »), d’un périmètre défini et d’une taille raisonnable ; veuillez donc la soumettre au vote comme n’importe quelle autre story. Le traitement des bugs et celui des fonctionnalités se disputent la même capacité, et la vélocité doit refléter cette situation.

L’exception concerne le bug dont la nature est « nous ne savons pas encore ce qu’il recèle » : enquêter sur la corruption des données, déterminer pourquoi p99 a doublé, les clients continuent de le signaler et nous ne parvenons pas à le reproduire. La correction n’est pas chiffrée car la cause n’est pas connue ; un vote sur les points d’histoire ne fait donc que mesurer ce que l’équipe espère découvrir. Intégrez ces éléments dans un cycle d’investigation à durée fixe : consacrez un jour ou deux à l’examen du problème, puis revenez avec une véritable histoire correspondant à ce que vous aurez découvert.

Tests et assurance qualité

Les points de story permettent d’évaluer l’ampleur du travail entre le moment où « la story entre dans le sprint » et celui où « la story est prête à être livrée », ce qui inclut l’ensemble des activités d’assurance qualité que l’équipe effectue dans le cadre de la définition de « terminé » : tests automatisés, vérifications manuelles, contrôles d’accessibilité, revue de sécurité. La story n’est pas terminée lorsque la pull request est fusionnée ; elle est terminée lorsqu’elle répond à la définition de « terminé ».

Les équipes qui se concentrent exclusivement sur le développement et ajoutent le contrôle qualité (QA) séparément prennent trop d’engagements à chaque sprint, car le QA constitue le goulot d’étranglement que personne n’a pris en compte. Si une équipe d’assurance qualité distincte est chargée des tests, la story supporte tout de même le coût, du côté des développeurs, lié à la collaboration avec cette équipe : préparation de la version, rédaction du plan de test, réponse aux questions. Cette partie n’est pas gratuite, elle est donc prise en compte dans l’estimation.

Pourquoi il est rare que l’on souhaite un article à un seul point

Les notes sont relatives ; ainsi, un « 1 » n’a de sens qu’à côté d’un « 2 », d’un « 3 » ou d’un « 8 ». Lorsqu’une équipe enchaîne sans cesse des performances notées « 1 », ce gradient disparaît : tout ce qui est insignifiant vaut un « 1 », tout ce qui est un peu plus important vaut un « 2 » ou un « 3 », et l’échelle s’est réduite à un simple tirage au sort.

La solution ne consiste pas à interdire les « 1 » (c’est là une application aveugle de la règle). Il s’agit plutôt de se demander pourquoi tant de travail se concentre en bas de l’échelle. Généralement, l’histoire de référence a dérivé : l’équipe a gagné en rapidité, et le « 1 » d’origine est désormais plus petit que tout ce qu’elle livre ; il faut donc choisir une référence plus récente dont l’équipe se souvient et réancrer l’échelle. Parfois, l’équipe décompose excessivement les stories lors du raffinement, en isolant chaque critère d’acceptation pour en faire une story à part entière : « mettre à jour le texte du bouton » n’est pas une story, mais un critère d’acceptation d’une story plus vaste. Et parfois, le travail est véritablement de petite envergure (une tâche de maintenance trimestrielle, une modification de texte nécessitant un avis juridique, un ajustement de configuration touchant l’environnement de production) ; dans ce cas, les points remplissent leur fonction et il n’y a rien à corriger.

L’indicateur à surveiller n’est pas « jamais de 1 ». C’est le fait que les 1 constituent la majeure partie du backlog. Un ou deux par sprint, cela ne pose pas de problème. Si une histoire sur deux est notée 1, cela signifie que la question de l’étalonnage n’a pas été posée depuis trop longtemps.

Les points d’histoire et la rétrospective

L’estimation est l’un des éléments les plus couramment examinés par une équipe lors de sa rétrospective de sprint. Lorsque les tâches sont systématiquement sous-estimées ou surestimées, lorsque la vélocité fluctue de manière excessive ou lorsque des tâches « terminées » sont sans cesse réouvertes, c’est lors de la rétrospective que l’équipe réajuste sa perception commune de l’ampleur des tâches et affine la manière dont elle découpe le travail. C’est grâce à cette boucle de rétroaction que la précision des estimations s’améliore, et non en redoublant d’efforts dès le départ.

Foire aux questions

Que sont les « story points » dans la méthode agile ?

Les « story points » constituent une unité d’estimation relative : il s’agit d’un chiffre qui rend compte de l’ampleur d’une tâche (en tenant compte à la fois de l’effort requis, de sa complexité et de son degré d’incertitude) par rapport à une « story » de référence que l’équipe a déjà réalisée. Ils ne constituent délibérément pas une mesure du temps. L’équipe évalue chaque élément par rapport aux autres plutôt que par rapport au temps.

Pourquoi utiliser des « story points » plutôt que des heures ?

Les gens ont du mal à estimer le temps absolu, mais sont doués pour juger si une chose est plus importante qu’une autre, et les points d’histoire s’appuient sur cette force. Ils évitent également le piège consistant à considérer une estimation comme un engagement, tiennent compte du fait qu’une même tâche prend plus ou moins de temps selon les personnes, et intègrent la complexité et le risque, et pas seulement la durée. Au fil de quelques sprints, la vélocité d’une équipe exprimée en points devient une prévision plus fiable que la simple addition des estimations en heures.

Comment évaluez-vous les points d’histoire ?

La plupart des équipes utilisent le « planning poker ». Une personne présente un élément du backlog, l’équipe en discute, puis chacun choisit en privé une valeur sur une échelle commune, généralement une suite de type Fibonacci (1, 2, 3, 5, 8, 13). Tout le monde dévoile son choix en même temps ; lorsque les estimations divergent fortement, les personnes ayant donné les valeurs les plus élevées et les plus basses expliquent leur raisonnement, puis l’équipe procède à un nouveau vote jusqu’à ce que les avis convergent. La discussion qui met en lumière les complexités cachées est souvent plus précieuse que le chiffre lui-même.

Les bogues devraient-ils avoir des points d’histoire ?

Oui, lorsque le bug a une cause connue et une solution claire : il s’agit d’une tâche comme une autre, et le signaler permet de garantir que la vélocité reflète fidèlement l’affectation des capacités. L’exception concerne les bugs exploratoires dont vous ne pouvez pas encore évaluer l’ampleur ; placez-les dans une piste d’investigation à durée déterminée et évaluez l’ampleur de la solution réelle une fois que vous en connaîtrez la cause.

Les points de story incluent-ils les tests ?

Oui. Les points évaluent toutes les étapes entre le moment où une fonctionnalité est intégrée au sprint et celui où elle est prête à être livrée, ce qui inclut les tests et l’assurance qualité effectués par l’équipe dans le cadre de sa définition du « terminé ». Si l’on attribue des points uniquement au travail de développement, le sprint dépasse systématiquement les délais, car l’assurance qualité constitue le goulot d’étranglement dont personne n’a tenu compte.

Pourquoi devriez-vous éviter les articles qui ne traitent que d’un seul point ?

Quelques-unes, ça va. Mais si la plupart des tâches en attente sont notées « 1 », cela signifie que l’histoire de référence de l’équipe s’est éloignée de la réalité et que l’échelle s’est effondrée, de sorte que tout est désormais perçu comme « minuscule » ou « plus grand ». Il convient de recalibrer l’échelle en vous basant sur une histoire de référence récente plutôt que de réduire l’échelle.

Pouvez-vous comparer les points de story entre les équipes ?

Non. Un « story point » est calibré en fonction de la perception qu’a une équipe de la taille relative d’une tâche ; ainsi, un « 5 » pour une équipe n’est pas équivalent à un « 5 » pour une autre. Comparer la vélocité ou le total des points entre les équipes n’a aucun sens et, utilisé comme objectif, cela s’avère carrément néfaste : cela pousse les équipes à gonfler leurs estimations. Les points de story constituent un outil de planification destiné aux prévisions d’une seule et même équipe, et non un indicateur de productivité à des fins de comparaison.

Lectures complémentaires

• Pourquoi les points de story utilisent la suite de Fibonacci: pourquoi les écarts s’agrandissent à mesure que les nombres augmentent.
• Points de scénario vs heures : le piège de la conversion, et comment réagir lorsqu’une personne a besoin d’une estimation.
• Velocity : intégrer les points d’inflexion dans une prévision sans les altérer.
• Techniques d’estimation agiles : quelle méthode utiliser dans quelle situation, et en quoi chacune d’entre elles présente des limites.
• Rétrospective de sprint : moment où les équipes réévaluent les estimations qui s’avèrent systématiquement erronées.
• Guide d’estimation agile : l’ensemble des techniques, du « planning poker » au fractionnement des stories.
• Planning Poker gratuit pour les équipes agiles : évaluez ensemble la taille de votre backlog en temps réel.