T-shirt sizing agile : estimer l'effort en équipe

Votre équipe a 30 éléments du backlog à estimer, un créneau de 60 minutes et une décision de feuille de route qui dépend du résultat. Débattre pour savoir si une story vaut 5 ou 8 n'entre pas dans ce cadre. Le t-shirt sizing agile est un moyen plus rapide d'aboutir à une vision partagée de l'effort, et il est plus précis que sa simplicité ne le laisse penser.

Ce qu'est le t-shirt sizing agile

Le t-shirt sizing attribue à chaque élément de travail une étiquette de taille (XS, S, M, L, XL, parfois XXL) au lieu d'une estimation en heures ou en jours. Le groupe saisit à la fois l'effort, la complexité et l'incertitude. Personne ne devrait lire le résultat comme une prévision littérale.

La technique repose sur un constat simple : les gens sont bien meilleurs pour comparer des choses entre elles que pour juger des valeurs absolues isolément. Le guide d'estimation agile d'Atlassian fait une remarque voisine : utiliser des story points plutôt que des heures encourage la collaboration au sein de l'équipe, réduit les biais émotionnels et améliore les prévisions. « Est-ce un S ou un M ? » est une question à laquelle on répond plus vite, et avec moins d'erreurs, que « combien d'heures cela va-t-il prendre ? ».

Le t-shirt sizing convient à l'affinage précoce du backlog, à la planification de la feuille de route et au PI Planning dans les contextes SAFe, où les epics et les features ont besoin d'une taille rapide avant que quiconque ne les découpe. Une équipe produit qui estime de cette façon lors des revues trimestrielles de la feuille de route peut traiter tout un trimestre de travail en une séance, car chaque élément prend quelques minutes au lieu de la discussion plus longue qu'appelle le planning poker. Avec 30 éléments ou plus sur la table, cette différence s'accumule vite.

Comment animer une séance de t-shirt sizing

Une séance comporte cinq phases.

• Préparation : l'animateur vérifie que chaque élément du backlog dispose d'assez de contexte pour une discussion utile. Si une story n'a qu'un titre d'une ligne et aucun critère d'acceptation, l'équipe passera 10 minutes à deviner de quoi il s'agit avant de pouvoir commencer l'estimation. Rendez les éléments lisibles avant la séance.
• Ancrage : avant le vote, l'équipe convient d'une story de référence pour chaque taille. C'est l'étape que les équipes sautent le plus souvent. Sans référence commune, « M » signifie quelque chose de différent pour chaque participant. Choisissez pour chaque taille une story terminée que tout le monde accepte, et gardez ces exemples visibles pendant toute la séance, sur un tableau Miro, une page Confluence ou une carte physique. Ils fonctionnent comme une règle graduée, et ce sont eux qui déterminent si l'équipe reste étalonnée ou repart de zéro à chaque séance.
• Révélation simultanée et silencieuse : chacun note une taille en privé et tout le monde révèle en même temps. Personne ne parle avant la révélation, de sorte que la première voix dans la salle ne peut pas ancrer les autres.
• Discussion : ne discutez que des valeurs aberrantes. Si tout le monde dit M et qu'une personne dit XL, cette conversation vaut la peine. Si l'écart est entre M et L, choisissez l'une des deux et passez à la suite. Les séances s'effondrent quand les équipes débattent en détail de chaque petit écart.
• Consignation du consensus : saisissez la taille convenue dans l'outil de backlog avant de passer à l'élément suivant.

Pour les équipes à distance, les modèles d'estimation agile de Miro et les tableaux numériques similaires rendent la révélation simultanée possible en une seule action « tout retourner ». C'est l'outil qui doit faire respecter la règle. Si les participants tapent leurs réponses dans un document partagé visible, ils lisent les réponses des autres avant de s'engager, et le biais que vous vouliez éviter revient.

Si vous épinglez les stories de référence sur une page Confluence partagée, les nouveaux membres de l'équipe peuvent apprendre ce que « M » signifie dans votre contexte sans un exercice d'étalonnage complet à chaque changement dans l'équipe. C'est une façon peu coûteuse de garder des tailles cohérentes dans le temps.

Faire correspondre les tailles de t-shirt aux story points

La correspondance est facultative. Elle aide quand votre outil de delivery (Jira, Azure DevOps, Linear) suit la vélocité en story points, mais la technique n'en a pas besoin.

Une correspondance courante est XS=1, S=2, M=3, L=5, XL=8, qui suit la suite de Fibonacci utilisée dans le planning poker. Certaines équipes utilisent XS=1, S=2, M=5, L=8, XL=13 pour creuser l'écart entre les gros éléments et imposer des distinctions plus nettes quand le backlog penche vers un travail complexe.

Quelle que soit la correspondance choisie, traitez-la comme une convention d'équipe et conservez-la au moins un trimestre. La changer en cours de projet revient à changer d'unité de mesure à mi-parcours. Toute personne de l'équipe qui assimile les story points à du temps devrait lire l'article de Scrum.org qui démonte les idées reçues sur les story points.

Imaginez une équipe produit qui applique la correspondance XS=1, S=2, M=3, L=5, XL=8 dans Jira, suit sa vélocité pendant deux trimestres et remarque que les stories XL aboutissent de façon bien moins prévisible que les stories M. Une réponse sensée est une règle d'équipe selon laquelle tout élément XL est découpé avant d'entrer dans un sprint. L'estimation sert alors aussi de déclencheur pour le découpage des stories.

Les équipes matures qui suivent des indicateurs de flux comme le temps de cycle et le débit plutôt que la vélocité peuvent utiliser les tailles de t-shirt comme filtre de priorisation approximatif sans les convertir en points.

T-shirt sizing, planning poker ou dot voting

On confond souvent ces trois techniques, mais elles remplissent des fonctions différentes.

Le t-shirt sizing est rapide et passe bien à l'échelle. Utilisez-le quand vous avez 20 éléments ou plus, peu de temps ou peu de détails au niveau des stories. Le planning poker est plus lent et plus précis : l'échelle de Fibonacci oblige les participants à choisir entre 5 et 8, ce qui fait ressortir plus de nuances que « M ou L ». Le dot voting est une méthode de priorisation. Il aide un groupe à s'accorder sur les éléments à traiter, et ne dit rien de leur taille.

Une règle qu'utilisent de nombreux coachs agiles : le t-shirt sizing pour tout ce qui se situe au-dessus du niveau du sprint (epics, features de la feuille de route, objectifs au niveau du programme) et le planning poker pour les user stories en cours d'affinage pour le prochain sprint. Le t-shirt sizing sert de première passe grossière, et la précision du planning poker va là où elle est rentable.

Dans les phases de découverte avec un client, cela signifie souvent que le t-shirt sizing couvre rapidement des ensembles entiers de fonctionnalités, et que le planning poker prend le relais pour l'affinage au niveau des stories une fois le développement lancé. Les deux techniques se complètent.

Quant à la place du dot voting : le dot voting vous dit sur quoi travailler, et le t-shirt sizing vous dit quelle est la taille du travail. Ils répondent à des questions différentes.

Les modes d'échec courants

Le biais d'ancrage est l'échec le plus courant. La première personne qui parle influence le groupe. C'est la révélation simultanée qui empêche la séance de simplement confirmer l'avis du lead technique ; ne la traitez donc pas comme facultative.

Le deuxième est la dérive des tailles. Avec le temps, les équipes élargissent discrètement leur définition de S jusqu'à appeler S ce qui était autrefois un M. Un réétalonnage mensuel ou trimestriel par rapport aux stories de référence corrige ce problème. Sans lui, vos données de vélocité dérivent d'une façon difficile à diagnostiquer.

Quand les parties prenantes traitent les tailles comme des engagements, c'est un problème d'animation et de gestion des parties prenantes. Les tailles sont des estimations d'ordre de grandeur approximatives, assorties d'une forte incertitude. La formulation aide : « notre meilleure estimation commune à ce jour » crée une attente différente de « notre estimation ».

Le dernier échec est le débat sans fin. Les équipes cherchent à s'accorder sur une taille exacte pour chaque story et transforment un exercice de 2 minutes en une dispute de 15 minutes. Si l'équipe ne parvient pas à s'accorder en 3-4 minutes, prenez la taille la plus grande et signalez la story pour découpage. Un timebox strict de 3 minutes par élément et une colonne « en attente » sur votre tableau Miro pour les stories contestées peuvent raccourcir considérablement une séance. Le récapitulatif de Scrum.org sur les erreurs d'estimation courantes traite plusieurs de ces schémas plus en profondeur.

Le t-shirt sizing dans les équipes à distance et distribuées

Les séances à distance ont besoin d'une structure explicite dont les équipes réunies au même endroit peuvent parfois se passer : un tableau numérique partagé que tout le monde voit, un protocole de révélation strict et une personne désignée pour tenir le temps. Sans cela, les séances à distance glissent vers un partage séquentiel, où les participants entendent les réponses des autres avant de s'engager.

Les équipes réparties sur plusieurs fuseaux horaires peuvent estimer de façon asynchrone. Des outils comme Parabol permettent aux membres de l'équipe d'enregistrer leur estimation indépendamment avant un débriefing synchrone qui ne couvre que les valeurs aberrantes. Un schéma courant pour les équipes d'ingénierie distribuées est une estimation asynchrone suivie d'un court échange synchrone d'environ 20 minutes pour trancher les éléments contestés, ce qui prend bien moins de temps de réunion qu'un planning poker entièrement synchrone.

La sécurité psychologique compte davantage à distance. Les ingénieurs juniors et les nouveaux membres de l'équipe peuvent se sentir exposés quand leur estimation diffère de celle d'un collègue senior. Une révélation simultanée à l'aveugle protège les opinions minoritaires qui, sinon, pourraient être abandonnées avant même que la conversation ne commence.

Intégrer le t-shirt sizing à l'affinage du backlog

Le t-shirt sizing s'intègre le mieux à l'étape de tri et d'affinage grossier de l'affinage du backlog, où l'on vérifie que les éléments sont prêts plutôt que de les planifier dans un sprint précis. Beaucoup d'équipes l'utilisent comme contrôle de préparation : les éléments XS, S et M peuvent passer en sprint planning, tandis que les éléments L et XL sont d'abord signalés pour découpage.

Dans les environnements SAFe, le t-shirt sizing apparaît souvent lors de l'affinage au niveau du programme pour estimer les Features avant qu'elles ne soient découpées en Stories. Les Product Managers peuvent alors prévoir la capacité sur plusieurs program increments sans attendre un découpage complet au niveau des stories.

Enregistrer les tailles dans votre outil de backlog vous donne une boucle de rétroaction. Si vos éléments M sont généralement terminés en 1-2 sprints, ce sont des données d'étalonnage. S'ils débordent régulièrement, la définition de M de l'équipe mérite d'être revue. Confronter les stories de référence à l'historique de livraison est ce qui permet aux équipes de progresser, au lieu de répéter le même mauvais étalonnage chaque trimestre.

Workshop Weaver propose des modèles d'animation pour les séances de t-shirt sizing, avec la mise en place des stories de référence et la structure de timebox décrites ici, pour que les équipes puissent mener le processus correctement dès la première séance.

Pour conclure

L'étiquette de taille compte moins que la conversation qu'elle impose. Quand une équipe se partage entre XS et L sur la même story, quelque chose est apparu : la story n'est pas claire, les personnes se représentent le travail différemment, ou personne ne sait à quel point il est complexe. Cette conversation doit avoir lieu avant le début du développement.

Si vous n'avez pas encore animé de séance de t-shirt sizing, essayez-la lors de votre prochain affinage du backlog. Suivez les cinq phases ci-dessus, préparez les stories de référence à l'avance, faites respecter la révélation simultanée et limitez les discussions à trois minutes.

Ensuite, lisez l'article sur le planning poker pour les cas où vous avez besoin de plus de détail au niveau des stories, et celui sur le dot voting pour une méthode de priorisation rapide en complément de l'estimation. À elles trois, ces techniques couvrent l'essentiel de ce dont une équipe a besoin pour estimer et prioriser.