Que sont les « story points » ? Estimer l'effort, et non le temps

Les points de story mesurent l’effort relatif d’une tâche (sa taille, sa complexité et son degré d’incertitude, le tout résumé en un seul chiffre), et non le nombre d’heures qu’elle nécessitera. 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 fait environ le double de celle-là ») au lieu d’avancer une estimation de 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 estime en heures effectue en réalité deux estimations : celle à laquelle croit l’ingénieur senior, et celle que l’ingénieur junior note après avoir arrondi à la hausse pour paraître sérieux. Les gens ne sont pas fiables lorsqu’il s’agit de répondre à la question « Combien de temps cela va-t-il prendre ? », mais sont étonnamment doués pour répondre à la question « Est-ce plus important que ce que nous avons terminé lors du dernier sprint ? ». Les points d’histoire s’appuient sur cette dernière approche.

Le dimensionnement relatif permet à l’équipe de s’accorder sur le fait qu’un élément est plus important qu’un autre sans que personne ne s’engage sur un nombre d’heures, ce qui évite les biais d’ancrage et d’ancienneté que suscitent les estimations en heures. Le chiffre qui en résulte 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 conserver le caractère prévisionnel de l’estimation.
• 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.

Comment fonctionne l’estimation en points d’histoire

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 le travail est important, 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 obtenez la vélocité, le résultat que les points de prévision sont censés produire.

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

Pour une première estimation plus rapide et moins précise, certaines équipes classent l’ensemble du backlog en fonction des 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, ces deux personnes 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 sur 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 raffinement : 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 du travail qu’elle s’est engagée à réaliser, afin que l’indicateur de vélocité reflète la répartition effective 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 est inconnue ; par conséquent, un vote sur les points de story ne fait 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 story 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é. L’histoire 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 uniquement sur le développement et ajoutent l’assurance qualité (QA) séparément prennent trop d’engagements à chaque sprint, car la 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 feature 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 », cette gradation 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 raffinage, 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 large. Et parfois, le travail est véritablement de petite envergure (un trimestre de maintenance, une modification rédactionnelle nécessitant un avis juridique, un ajustement de configuration touchant l’environnement de production) ; dans ce cas, les points remplissent leur rôle 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 recalibre sa perception commune de l’ampleur des tâches et affine la manière dont elle les découpe. 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 : un chiffre qui rend compte de l’ampleur d’une tâche (en tenant compte à la fois de l’effort requis, de la complexité et du 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 en valeur absolue, 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 permettent également d’éviter 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 attribué 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 de la capacité. 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 d’histoire 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 son délai, car l’assurance qualité constitue le goulot d’étranglement dont personne n’a tenu compte.

Pourquoi devriez-vous éviter les articles à un seul point ?

Quelques-unes, ça va. Mais si la majeure partie du backlog est composée de « 1 », l’histoire de référence de l’équipe s’est éloignée de la réalité et l’échelle s’est effondrée, si bien que tout est perçu comme « minuscule » ou « plus grand ». Recalibrez-vous par rapport à une histoire de référence récente plutôt que de réduire l’échelle.

Peut-on 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, lorsqu’on s’en sert comme objectif, cela s’avère carrément néfaste : cela pousse les équipes à gonfler leurs estimations. Les story points constituent un outil de planification destiné aux prévisions d’une seule et même équipe, et non un indicateur de productivité destiné à la 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éajustent les estimations qui s’avèrent systématiquement erronées.
• Guide d’estimation agile : l’ensemble des techniques, du « planning poker » à la division des stories.
• Planning Poker gratuit pour les équipes agiles: évaluez ensemble la taille de votre backlog en temps réel.