L’estimation en story points

Un story point regroupe trois choses : la quantité de travail, la complexité technique et l’incertitude qui entoure le sujet. Une migration fastidieuse mais parfaitement comprise et une petite fonctionnalité réellement inédite peuvent toutes deux valoir 5, pour des raisons différentes.

Les points ne sont volontairement pas des heures. Le jour où une équipe décide qu’un point vaut quatre heures, les points deviennent une unité de temps moins bonne que les heures et tout le bénéfice disparaît. L’estimation relative fonctionne parce que l’être humain compare bien mieux qu’il ne prédit. Demandez à quelqu’un si cette user story est plus grosse que celle-là, il aura généralement raison. Demandez-lui combien d’heures elle prendra, il aura généralement tort.

C’est aussi ce qui protège l’équipe. Un point ne dépend ni de la personne qui prendra le ticket, ni de ses interruptions de la semaine. Il décrit le travail, pas la personne, et cela rend la conversation d’estimation nettement moins tendue.

Choisissez une user story déjà terminée, dont tout le monde se souvient, et qui a paru petite sans être triviale. Appelez-la 2, ou 3. C’est votre point d’ancrage pour le trimestre.

À partir de là, estimer devient comparer plutôt qu’inventer. Est-ce plus gros que la référence ? À peu près le double ? Chaque nouvelle personne dans l’équipe reçoit l’explication de la user story de référence dès le premier jour, ce qui est beaucoup plus rapide que d’essayer de lui enseigner dans l’abstrait ce que « un 5 » représente.

Réétalonnez quand la composition de l’équipe change franchement, ou quand vous constatez que la référence ne ressemble plus au travail en cours. Ne réétalonnez jamais discrètement au milieu d’un sprint : vous casseriez la seule série de chiffres comparables dont vous disposez.

Affinez avant d’estimer. Une user story qui n’a pas de critères d’acceptation lisibles ne s’estime pas : le chiffre obtenu mesurerait l’imagination de l’équipe, pas le travail. Une session d’affinage productive répond à trois questions : qu’est-ce qui est demandé, comment saura-t-on que c’est fini, et qu’est-ce qui reste inconnu.

Estimez ensuite en équipe complète, en une manche de poker planning par user story. La présence des personnes qui feront réellement le travail n’est pas négociable ; celle des autres l’est. Visez deux minutes par user story et une quinzaine de user stories par session au maximum.

Enfin, notez ce qui a été dit, pas seulement le chiffre. Six semaines plus tard, personne ne se souviendra pourquoi cette user story valait 8, et l’équipe rejouera la même discussion.

La vélocité est le nombre de points terminés par sprint, moyenné sur les trois à cinq derniers. Son usage légitime est la prévision : à environ 30 points par sprint, un backlog de 120 points représente à peu près quatre sprints de travail.

Elle se dérègle dès qu’elle devient un objectif. Les points sont estimés par les personnes dont on mesure la performance : une équipe à qui l’on demande d’augmenter sa vélocité augmentera ses estimations. Le chiffre monte, rien ne sort plus vite, et vous avez perdu l’outil de prévision par-dessus le marché. Comparez une équipe à son propre historique, jamais à une autre équipe.

Une vélocité irrégulière n’est pas forcément un problème. Regardez-la sur un trimestre : c’est la tendance qui éclaire la feuille de route, pas le sprint isolé où trois personnes étaient en congé.

La question revient toujours, et elle est légitime : une direction a besoin de dates, pas de points. La bonne réponse n’est pas de refuser, c’est de séparer les deux exercices. L’équipe estime en points, parce que c’est ce qu’elle sait faire de manière fiable. La conversion en délai se fait ensuite, à partir de la vélocité observée, et elle relève de la prévision, pas de l’estimation.

Concrètement : « ce lot représente 90 points, nous en terminons entre 25 et 35 par sprint, donc trois à quatre sprints ». La fourchette est le point important. Elle transmet honnêtement l’incertitude, là où une date unique promet une précision que personne ne possède.

Si le sujet exige un engagement ferme, ce n’est plus une question d’estimation mais de périmètre : fixez la date et rendez le contenu négociable, ou fixez le contenu et rendez la date négociable. Les deux à la fois ne tiennent jamais.

Estimer dans le vide. Si la user story n’a pas été affinée, l’estimation revient à tirer à pile ou face. Affinez d’abord, estimez ensuite.

S’ancrer sur le premier chiffre prononcé. C’est exactement ce que la révélation simultanée empêche, et c’est la raison pour laquelle estimer dans un document partagé donne de moins bons chiffres qu’estimer avec des cartes.

Faire la moyenne d’un vote partagé. Un 2 et un 13 ne font pas un 7,5. Ils font une conversation. Discutez, puis revotez.

Convertir les points en jours. Dès qu’un tableau de conversion circule, l’équipe estime des durées avec un vocabulaire de tailles, et hérite des inconvénients des deux.

Tout estimer. Une estimation coûte du temps de réunion et ne rapporte que là où le chiffre change une décision. Sur une correction d’une heure ou une tâche répétée chaque sprint, le débat coûte plus cher que l’écart qu’il permet de corriger, et il pousse l’équipe à finir la session sans avoir discuté les sujets qui en avaient besoin. Certaines équipes ne dimensionnent plus que les éléments porteurs de risque : c’est un choix légitime, pas un manque de rigueur.

Menez l’estimation elle-même en poker planning, avec la suite de Fibonacci une fois que votre backlog est assez affiné pour que les chiffres veuillent dire quelque chose.