Les « story points » face au mouvement #NoEstimates : notre verdict

Aucun des deux camps ne l’emporte clairement. Évaluez afin de parvenir à une compréhension commune et d’identifier les désaccords ; n’évaluez pas dans le but de prédire une date — préférez plutôt établir des prévisions à partir du débit. Le chiffre en lui-même n’a pratiquement aucune valeur. C’est la discussion qui a permis d’y parvenir qui constitue la véritable richesse.

Le débat est présenté comme un choix binaire — des points ou pas de points — alors qu’il n’en est rien. Les deux camps ont raison sur certains points, et chacun bénéficie du soutien d’une autorité de poids. La position la plus utile est celle qui retient les arguments les plus solides de chaque camp et ne conserve que les éléments qui résistent à l’épreuve d’un véritable sprint.

Les arguments en faveur des « story points »

L’argument de Mike Cohn, qui incarne la position par excellence des partisans des « points », n’a jamais vraiment porté sur le chiffre en soi. Il s’agit plutôt du fait que l’acte même d’estimer de manière relative oblige une équipe à discuter de la complexité, à mettre au jour les hypothèses cachées et à s’accorder sur ce qu’implique réellement une story avant que quiconque n’écrive la moindre ligne de code. Les points permettent également d’éviter un problème spécifique : si l’on estime en jours, chaque chiffre fait l’objet de marchandages ; si l’on estime en une unité abstraite, ces marchandages n’ont plus de prise. Le hic, c’est que tout le monde perçoit le clin d’œil — « nous n’estimons pas le temps, mais seulement la complexité, afin de pouvoir planifier le sprint, qui dure deux semaines » — et l’abstraction ne protège l’équipe que tant que personne ne la reconvertit directement en date.

Steve McConnell apporte un contrepoids rigoureux aux détracteurs de l’estimation. Selon lui, la cause première des mauvaises estimations réside généralement dans un manque de compétences en matière d’estimation, et non dans l’estimation elle-même — et les estimateurs sérieux font la distinction entre trois éléments que le débat ne cesse de confondre : l’estimation (ce qui est probable), l’objectif (ce que l’entreprise souhaite) et l’engagement (ce que l’équipe promet). Si l’on confond ces éléments, l’estimation semble bien sûr inefficace. Si l’on les distingue clairement, elle remplit pleinement son rôle.

Les arguments en faveur de #NoEstimates

Passons maintenant à l’autre camp, au grand complet. L’objection d’Allen Holub est que les estimations sont toujours imprécises, souvent de manière flagrante, et que les « story points » avaient pour but de masquer la durée afin que les responsables cessent d’exercer une pression sur les délais — or, les équipes les reconvertissent directement en heures, reproduisant ainsi exactement les dysfonctionnements que ces points étaient censés éviter. L’échelle de Fibonacci ne vous sauve pas si chacun dispose en privé d’un tableau de conversion des points en heures.

L’affirmation la plus percutante, fondée sur les données, vient de Vasco Duarte : dans le cadre de projets concrets, le simple fait de compter les stories permet de prévoir les résultats à peu près aussi bien que d’additionner leurs points de story. Si cela s’applique à votre travail, les points ne sont qu’une pure formalité : vous avez effectué des calculs pour aboutir à la même réponse que celle que le simple comptage vous avait déjà donnée. Mesurez plutôt le débit et le temps de cycle ; une file d’attente qui s’allonge est un indicateur avancé que vous pouvez anticiper, tandis que la vélocité est un indicateur retardé.

Et puis, la remarque la plus percutante de tout ce débat. Ron Jeffries, à qui l’on attribue généralement l’invention des « story points », est revenu sur ses propos en 2019: « J’ai peut-être inventé les story points, et si c’est le cas, je m’en excuse aujourd’hui. » Son problème porte spécifiquement sur leur utilisation pour prédire la date d’achèvement du travail et pour comparer les équipes. Son alternative n’est pas de « cesser de planifier », mais de découper les stories en tranches suffisamment fines pour ne nécessiter qu’un seul test d’acceptation, idéalement moins d’une journée chacune, de sorte qu’il ne reste pratiquement plus rien à estimer.

Dans quels cas nous changerions d’avis

Nous adopterions pleinement l’approche #NoEstimates pour une équipe dont le travail est déjà divisé en petites tâches uniformes. Lorsqu’une story prend environ une journée, que l’on compte les prévisions de stories et que l’on additionne les points, et que la réunion d’estimation constitue une charge supplémentaire dont on peut se passer — McConnell le reconnaît d’ailleurs, citant le travail en cycles rapides, où la mission consiste simplement à « faire la prochaine chose la plus utile », comme un contexte dans lequel les estimations n’apportent pas grand-chose.

Nous baisserions la garde face aux « points » dans le cas inverse : une organisation où les estimations ne se transforment véritablement jamais en engagements et où personne ne compare les équipes. Dans ce cas, le danger contre lequel met en garde le camp anti-estimation n’existe pas, et les points ne sont qu’un simple sujet de conversation inoffensif. Le problème, c’est que ce type d’organisation est rare. L’utilisation des points à des fins stratégiques est la norme, ce qui explique pourquoi notre verdict penche dans ce sens.

L’aspect pratique

• Considérez le planning poker comme un outil permettant de détecter les divergences d’opinion, et non comme un outil de prédiction. Un 2 et un 13 attribués à la même tâche constituent un signal : cela signifie que l’équipe n’a pas une vision commune du travail à accomplir. Discutez jusqu’à ce que l’écart disparaisse ; c’est le consensus qui est l’objectif, et non le chiffre final.
• Les prévisions doivent être établies à partir du débit et de la durée du cycle, et non à partir de la somme des points. Velocity constitue une donnée de planification pour l’équipe, et ne constitue en aucun cas un engagement vis-à-vis de l’extérieur.
• Distinguez l’estimation de l’engagement, comme le dit Cohn. Une estimation n’est qu’une supposition ; dès qu’elle devient une promesse, c’est que quelqu’un en a modifié le sens sans en informer l’équipe.
• Si vous utilisez des points, veillez à ce qu’ils restent relatifs. Dès qu’ils correspondent à des heures, vous vous retrouvez à estimer la durée de manière détournée — avec toute la pression liée aux estimations en heures, à laquelle s’ajoute une couche de confusion.
• Divisez le projet en parties plutôt que d’en déterminer la taille. Jeffries a raison de dire que la majeure partie de ce qui fait l’objet du débat perd de son importance lorsque les parties sont suffisamment petites pour que l’estimation n’ait pratiquement plus d’importance.

Le chiffre n’a aucune valeur ; c’est la discussion qui a permis d’y parvenir qui importe. Cette simple phrase résout l’essentiel du débat — et elle permet à une session de planning poker de rester véritablement utile, sans prétendre pouvoir prédire l’avenir.

Foire aux questions

Faut-il utiliser les « story points » ou la méthode #NoEstimates ?

Utilisez la méthode qui favorise le dialogue autour de l’estimation, et cessez de considérer ce chiffre comme une prévision. Les points d’histoire sont utiles pour détecter les divergences : un écart important sur une histoire signifie que l’équipe n’en a pas une compréhension commune. L’approche #NoEstimates est la bonne solution lorsque vos stories sont déjà découpées en petites parties homogènes, car dans ce cas, leur comptage permet à la fois d’établir des prévisions et de totaliser les points. Dans tous les cas, prévoyez les livraisons en fonction du débit, et séparez l’estimation de l’engagement.

L’inventeur des « story points » s’en est-il vraiment désolidarisé ?

Ron Jeffries, à qui l’on attribue généralement la création des « story points », a écrit en 2019 : « J’ai peut-être inventé les story points, et si c’est le cas, je m’en excuse aujourd’hui. » Ce qu’il conteste, c’est leur utilisation pour prévoir les dates d’achèvement et pour comparer ou noter les équipes. L’alternative qu’il recommande n’est pas « l’absence de planification », mais le découpage des stories en éléments suffisamment petits pour ne nécessiter qu’un seul test d’acceptation.

Comment peut-on établir un planning de livraison sans estimer chaque feature ?

Mesurez le débit — c’est-à-dire le nombre de stories que l’équipe réalise effectivement chaque semaine — et estimez le volume de travail restant en fonction de ce rythme. Vasco Duarte a constaté que le comptage des stories permettait de faire des prévisions aussi précises que l’addition des points de story ; ainsi, une fois que les stories ont été découpées en morceaux de taille similaire, les points n’apportent guère d’informations supplémentaires par rapport à ce que le comptage vous donne déjà.

Lectures complémentaires

• Que sont les « story points » ? — ce que mesurent ces points, et ce qu’ils ne mesurent pas.
• Points de scénario vs heures — pourquoi la conversion des points en heures est le point de discorde qui oppose réellement les deux camps.
• La vitesse est-elle un indicateur utile ? — l’autre aspect de ce débat : que se passe-t-il lorsque la prévision devient un objectif ?
• Le théâtre agile : le mode de défaillance de la prestation — l’estimation comme rituel de type « cargo cult », et comment distinguer une véritable estimation d’une simple mise en scène.
• Planning Poker gratuit — un outil de discussion, et non un outil de prévision.