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

Les « story points » permettent de mesurer l'effort relatif, la complexité et le degré d'incertitude d'un travail — et non le nombre d'heures. Comment évaluer l'ampleur d'un projet par rapport à une « story » de référence, et les questions qui posent problème aux équipes.

Les points d’histoire mesurent l’effort relatif d’une tâche — c’est-à-dire 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 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 estime en heures effectue en réalité deux estimations : 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 paraître sérieux. On ne peut pas se fier aux gens lorsqu’il s’agit de répondre à la question « Combien de temps cela va-t-il prendre ? », mais ils 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 seconde approche.

L’évaluation relative 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 permet d’éviter 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.

Le barème 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 délibérément : 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 obtenez la vélocité — c’est précisément ce que les points d’entrée de prévision sont censés produire.

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 transforment en débats 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 du travail qu’elle s’est engagée à réaliser, 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 comporte des critères d’acceptation (« le formulaire n’accepte plus les quantités négatives »), un périmètre défini et une taille raisonnable — vous pouvez 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 ; 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 évaluent 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 phase « 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 uniquement sur le développement et ajoutent l’assurance qualité (QA) séparément finissent par se surcharger à 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 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 » — ce serait 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, c’est un critère d’acceptation d’une story plus large. 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.

Le signe à 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.

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 sa complexité et de son degré d’incertitude — par rapport à une « story » de référence que l’équipe a déjà livré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 qu’en fonction du temps.

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

Oui, lorsqu’un bug a une cause connue et une solution claire, il s’agit d’un cas comme un 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 connaissez 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 plupart des tâches en attente sont notées « 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 : tout est désormais 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.

Lectures complémentaires