Comprendre les story points
Les story points mesurent la taille d’une user story par rapport aux autres. Un 5 isolé ne veut rien dire ; ce qui compte, c’est qu’il se situe entre le 3 et le 8 que l’équipe a déjà posés sur d’autres stories. On les trouve aujourd’hui dans beaucoup d’équipes Scrum et XP, au point d’être devenus presque synonymes d’estimation agile.
Ce que recouvre un point
Quand un développeur pose une carte, il pèse en réalité trois choses à la fois.
La quantité de travail. Un assistant de déclaration en cinq étapes demande plus de code qu’un simple export CSV, même si aucune étape n’est difficile.
La complexité. Certaines modifications tiennent en vingt lignes mais demandent une journée de réflexion : un calcul de TVA avec des taux différents selon le pays du client, une règle d’arrondi qui doit coller au centime près avec celle de l’expert-comptable.
L’incertitude. Une API partenaire mal documentée, une spécification qui tient en une phrase, un module écrit par un prestataire parti depuis longtemps : tout ce qu’on ne sait pas encore fait grimper l’estimation.
Personne ne calcule ces trois composantes à part. Chacun les combine à sa façon avant de choisir sa carte, de sorte qu’un même 8 peut recouvrir deux lectures très différentes de la story. Pour Inès, c’est le volume de tests à écrire ; pour Karim, c’est l’API du partenaire qui renvoie des erreurs sans explication. Ce genre de décalage ne se voit qu’en parlant, et c’est pour provoquer cet échange que le planning poker fait retourner les cartes ensemble.
Pourquoi pas des heures ?
Les heures parlent davantage aux personnes extérieures à l’équipe. Plusieurs raisons poussent pourtant les équipes agiles vers une échelle relative.
Comparer est plus facile que mesurer
Les équipes le constatent vite : décider laquelle de deux stories est la plus lourde prend quelques secondes et fait rarement débat, alors qu’un chiffrage en heures ouvre une discussion sur les hypothèses de chacun (qui s’en charge, avec quels tests, avec combien d’interruptions). Un jugement relatif s’appuie en plus sur du vécu : « c’est l’export comptable de mars, en un peu plus petit ».
Le chiffre ne dépend pas de la personne
Sur le moteur de calcul des cotisations, celui qui l’a conçu et une recrue arrivée le mois dernier n’annonceraient pas la même durée pour une même correction, et ils auraient raison tous les deux. Or, au moment de l’affinage, personne ne sait encore qui prendra le ticket. Les points contournent la difficulté : ils décrivent la story, pas la personne, et toute l’équipe peut s’aligner sur une même valeur.
Une estimation n’est pas une promesse
« Tu avais dit deux jours » : tout développeur a entendu cette phrase en daily. Une estimation en heures se change vite en engagement personnel, et celui qui la dépasse se sent pris en faute. Un chiffre en points désigne la taille du travail, ce qui permet d’annoncer plus facilement qu’un risque se confirme.
Choisir des stories de référence
Pour que « relatif » veuille dire quelque chose, il faut un étalon, et le plus sûr est de le prendre dans le travail déjà livré. Une équipe qui développe un site de prise de rendez-vous pour une mairie a retenu deux stories dont tout le monde se souvenait. La première, le bandeau qui prévient que le service état civil est fermé, a pris quelques heures sans la moindre surprise : elle vaut 2. La seconde, l’annulation d’un rendez-vous depuis le lien reçu par e-mail, a demandé un jeton sécurisé, une page de confirmation et la remise à disposition du créneau : elle vaut 5.
En séance, les développeurs citent ces deux tickets par leur nom. « C’est un bandeau, à peine plus » ou « on est au-dessus de l’annulation » se comprend instantanément, bien mieux qu’une définition abstraite du point. L’équipe a consigné les deux références dans le wiki du projet, avec un lien vers les tickets, et les présente à chaque nouvel arrivant avant sa première séance.
Vélocité et prévisions
La vélocité est la somme des points des stories terminées pendant un sprint, au sens de la définition de « terminé » de l’équipe. Une story encore en recette le dernier jour ne compte pas ce sprint-là ; ses points iront au sprint où elle sera vraiment finie.
Imaginons une équipe qui a bouclé ses quatre derniers sprints à 31, 26, 34 et 29 points. Aucun de ces chiffres ne permet à lui seul de prévoir le suivant ; ensemble, ils dessinent une fourchette de 26 à 34, centrée autour de 30. C’est avec elle que l’équipe fixe la charge du prochain sprint, en visant plutôt le milieu. Le Product Owner s’en sert pour ses échéances : environ 180 points restent avant la mise en production d’une nouvelle offre, soit six sprints au rythme moyen, sept si l’équipe tourne au bas de sa fourchette.
Qu’une somme d’estimations approximatives donne une série assez régulière peut surprendre. L’explication tient au nombre : sur une douzaine de stories, les surestimations et les sous-estimations se neutralisent en partie. Le mécanisme a ses conditions. Il suppose une équipe de composition à peu près stable et un travail de même nature d’un sprint à l’autre. Trois arrivées d’un coup, un sprint dévoré par des incidents de production ou une échelle qui glisse en silence suffisent à brouiller la série.
Pour savoir où la vélocité intervient entre l’affinage et le Sprint Planning, voyez la page Scrum poker.
Les idées reçues qui font des dégâts
« Un point, c’est une journée »
La demande revient souvent, en particulier de la part de ceux qui doivent chiffrer un budget. Si l’équipe l’accepte, les points deviennent des jours déguisés, et tous les défauts des estimations en heures reviennent avec. Pour répondre à la question « pour quand ? », mieux vaut projeter le reste du backlog avec la vélocité et donner une réponse en sprints, avec sa fourchette.
« On peut comparer les équipes »
Un directeur technique voit passer deux tableaux de bord : l’équipe Paiement boucle ses sprints à 45 points, l’équipe Catalogue à 22. La tentation de féliciter la première est forte, et elle repose sur un malentendu. Chaque équipe a construit son échelle à partir de ses propres stories de référence, si bien qu’un 3 chez les uns peut correspondre à un 8 chez les autres. Et si la comparaison devient un critère d’évaluation, les estimations s’alourdissent d’un sprint à l’autre, sans une ligne de code de plus.
« Une vélocité en hausse est forcément une bonne nouvelle »
Une vélocité qui passe de 30 à 42 en un sprint mérite une vérification avant d’être fêtée : si un travail de la taille du bandeau de la mairie a été noté 5, l’explication est trouvée. Pour annoncer une date, une série régulière vaut mieux qu’une courbe ascendante.
« Chaque story mérite un chiffre exact »
Chercher la précision sur une estimation se paie en temps de réunion. Une échelle aux marches espacées comme la suite de Fibonacci assume l’à-peu-près : l’équipe range la story dans la case la plus plausible et passe à la suivante.
Par où commencer
Pas besoin d’un grand chantier pour se lancer. Commencez par fixer vos deux stories de référence, comme dans l’exemple de la mairie, et adoptez le jeu le plus courant : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, plus « ? » et la carte café.
Pour la première séance, demandez au Product Owner une dizaine de stories dont il est sûr qu’elles arriveront bientôt. Une heure de vote sur des sujets bien compris apprend davantage à l’équipe que trois heures sur des idées qui auront changé d’ici là. Votez en planning poker ; une salle en ligne gratuite, sans inscription, fait l’affaire.
Ensuite, laissez tourner. La vélocité des premiers sprints fluctue beaucoup, et il faut en général trois ou quatre itérations avant qu’une fourchette crédible apparaisse. D’ici là, servez-vous-en comme d’un indice.
Les références, elles, s’usent. Le bandeau de la mairie paraissait parlant au lancement ; un an plus tard, l’équipe a automatisé ses déploiements, la moitié des développeurs n’étaient pas là à l’époque, et plus personne ne se souvient du ticket. Quand les références ne parlent plus aux nouveaux venus, choisissez-en d’autres parmi le travail récent et notez la date du changement, pour lire correctement l’historique de vélocité.