Dans beaucoup d’équipes agiles, le planning poker suit un rituel bien rodé: on retourne les cartes, on constate que trois personnes ont voté 3 et deux ont voté 5, puis on passe dix minutes à déterminer si la story est “vraiment” un 3 ou un 5. La discussion est rarement inutile en soi, car elle révèle parfois des divergences de compréhension sur le périmètre de la tâche. Mais la question mérite d’être posée: cette distinction entre 3 et 5 améliore-t-elle réellement la capacité de l’équipe à livrer de manière prévisible?
À quoi sert réellement une estimation?
L’estimation en contexte agile remplit deux fonctions distinctes que les équipes confondent presque systématiquement. La première est le dialogue technique: en estimant ensemble, les membres de l’équipe confrontent leur compréhension d’une user story (description d’un besoin utilisateur formulée du point de vue de ce dernier). Quand un développeur vote 2 et un autre vote 8, l’écart signale un malentendu qu’il faut résoudre avant de commencer le travail. Cette fonction est précieuse et justifie à elle seule le temps consacré à l’estimation.
La seconde fonction est la prévision: en additionnant les points estimés et en les comparant à la vélocité historique (nombre de points livrés par sprint en moyenne), l’équipe et ses parties prenantes peuvent projeter une date de livraison ou un périmètre réaliste pour une échéance donnée. Cette fonction exige des estimations numériques et additives.
Le problème survient quand on utilise un seul outil pour servir ces deux fonctions. Les story points (unité arbitraire de taille relative) sont conçus pour la prévision, mais on les charge aussi de la fonction de dialogue. Les tailles de t-shirt (S, M, L, XL) sont naturellement adaptées au dialogue, mais elles ne s’additionnent pas. Clarifier cette distinction permet de faire un choix éclairé plutôt que de suivre la mode du moment.
Pourquoi les story points glissent vers les heures
Le reproche le plus fréquent adressé aux story points est qu’ils se transforment en jours déguisés. Ce glissement n’est pas un accident: il est inhérent à l’usage de chiffres dans un contexte professionnel où le temps est la métrique dominante. Dès qu’un chef de projet entend “cette story fait 8 points”, son réflexe est de chercher combien de jours cela représente.
Ron Jeffries, co-créateur d’Extreme Programming, a exprimé publiquement ses regrets sur la manière dont les story points ont été récupérés par le management. Comparaisons inter-équipes, pression à augmenter la vélocité, suivi estimé vs. réel: autant de détournements qui transforment un outil de conversation en instrument de contrôle. Sa recommandation actuelle est de privilégier le découpage en tranches de travail les plus petites possibles plutôt que l’estimation détaillée.
Le t-shirt sizing comme outil de recentrage
L’estimation par tailles de t-shirt élimine les chiffres et avec eux la tentation de la conversion en temps. Quand une équipe classe une story en “L”, elle exprime un ordre de grandeur relatif sans fournir de matière à des calculs de productivité. Le Scrum Guide ne prescrit d’ailleurs aucun format d’estimation spécifique, ce qui laisse aux équipes la liberté de choisir l’outil le plus adapté à leur contexte.
L’avantage le plus tangible est le gain de temps en session d’estimation. Avec quatre ou cinq catégories au lieu de huit à dix valeurs numériques, les désaccords se résolvent plus vite. La question “M ou L?” se tranche en une minute là où “3 ou 5?” peut mobiliser un quart d’heure, parce que les chiffres créent une illusion de précision que les participants se sentent obligés de défendre.
La proposition de Mike Crittenden, ingénieur et auteur technique, va plus loin: il suggère de mesurer la vélocité en nombre de tickets terminés plutôt qu’en points. Son argument repose sur une observation empirique selon laquelle les courbes “tickets par sprint” et “points par sprint” suivent des trajectoires quasi-identiques sur la durée d’un projet. Si cette corrélation se vérifie, les points n’ajoutent pas de valeur prédictive et représentent un coût d’estimation sans bénéfice proportionnel.
Les conditions pour que le changement fonctionne
Abandonner les story points au profit du t-shirt sizing n’est pas un geste anodin et suppose de résoudre plusieurs problèmes concrets.
Le premier est la communication avec les parties prenantes. Un sponsor habitué à entendre “il reste 60 points de travail, soit environ trois sprints” aura besoin d’un substitut. La vélocité en tickets peut remplir ce rôle, à condition que les tickets soient de taille raisonnablement homogène. Cette homogénéité ne se décrète pas: elle résulte d’un travail de raffinement du backlog (liste ordonnée des éléments de travail à réaliser) qui exige de la rigueur dans le découpage des user stories. En pratique, cela signifie qu’un Product Owner ou un Scrum Master doit investir du temps en amont de chaque sprint pour vérifier que chaque élément du backlog représente un incrément livrable en un à trois jours. Sans ce travail préalable, compter les tickets produit une métrique aussi trompeuse que les points qu’elle est censée remplacer.
Le second problème est la tentation du contournement. Certaines équipes associent des valeurs numériques cachées aux tailles (M=5, L=8) pour retrouver la capacité d’addition. Ce détour réintroduit exactement les biais qu’on cherchait à éliminer et ajoute une couche d’abstraction inutile. Si l’équipe a besoin de chiffres additifs, mieux vaut conserver les story points en travaillant sur la discipline d’usage plutôt que de déguiser un système numérique en catégories nominales.
Le troisième est la période de transition elle-même. Une équipe qui abandonne les story points perd temporairement son historique de vélocité, ce qui complique les prévisions à moyen terme pendant plusieurs sprints. Il est préférable de faire coexister les deux systèmes pendant quatre à six itérations, le temps d’accumuler suffisamment de données en tickets terminés pour que la nouvelle métrique devienne fiable.
Un choix qui dépend de la maturité du backlog
En pratique, le format d’estimation le plus adapté dépend de la qualité du backlog. Une équipe qui découpe systématiquement ses stories en tranches livrables en un à trois jours peut se permettre de compter les tickets et d’utiliser les tailles de t-shirt uniquement comme outil de dialogue. Une équipe dont le backlog contient des stories allant de quelques heures à plusieurs semaines a besoin d’une échelle numérique pour que la vélocité ait un sens, et les story points restent alors l’option la moins mauvaise.
La question n’est donc pas “quel format est objectivement supérieur?” mais plutôt “quel est l’état de notre backlog et qu’attendons-nous de nos estimations?”. La réponse honnête à ces deux questions guide le choix mieux que n’importe quel article de blog, y compris celui-ci.