Technique d’estimation de User Story : Le T-shirt Size Estimating

Une technique d’estimation relative créative pour libérer les développeurs du poids des chiffres.

T-shirt-size-estimating-agilaction

Les atouts

Initialement lors de l’estimation des Users Stories les équipes sont plus accoutumés à utiliser des méthodes basées sur le comptage des points. Que ce soit le planning poker, ou bien encore le Bucket System , à chaque fois on demande aux développeurs de quantifier la complexité des Users Stories en la chiffrant. Cependant cette méthode est certes très arrangeante pour le Product Owner qui devra à la suite de cette activité établir un Backlog produit croisant valeur et complexité, mais il semblerait qu’elle puisse compliquer la tâche aux développeurs pour juger correctement une US.

En effet utiliser une échelle numérique est tellement précis que les équipes peuvent parfois avoir du mal à déterminer un score exact. Par contre, l’utilisation de la méthode T-shirt Size Estimating va permettre aux développeurs de penser de manière plus abstraite l’effort qu’impliquera la réalisation d’une user story. Le but est donc de proposer une méthode d’estimation créative pour faciliter la tâche d’estimation aux équipes. L’utilisation de tee-shirt comme ordre de grandeur laisse place à une certaine souplesse pour les votants.

Le principe

Le principe est extrêmement simple : le rituel est le même que pour les réunions d’estimation classiques. Sauf qu’au lieu d’utiliser des cartes ou des points, vous utilisez des T-shirts. Ou plutôt des tailles de T-shirt. Chaque User Story devra être estimée par une des tailles suivantes : XS , S, M , L et enfin XL voire XXL (à vous de voir). Vous pouvez illustrer les T-shirts en les dessinant sur un tableau ou même en en apportant de vrais.

Dans le même esprit, certaines équipes utilise des races de chien pour estimer la complexité d’une US, ceci peut aussi être une variante à essayer de temps à autres.

Les faiblesses

L’avantage de cette méthode est aussi sa faiblesse : le manque de précision de la notation. En effet si elle se révèle être libérante pour les développeurs, elle peut s’avérer difficile à manipuler par la suite par les autres parties prenantes du projet. On ne peut pas dire à un client que sa fonctionnalité sera mise en production dans 1 T-Shirt L et 2 T-Shirt M … Pour pallier ce problème, le Product Owner peut faire correspondre les tailles de T-shirt à des nombres afin de se faciliter la vie pour la suite. Par exemple dire qu’un M vaut 5 et un L vaut 10.

Précisons que cette méthode s’adresse plus à une équipe qui se lance dans l’agilité ou plus précisément dans la tâche d’estimation relative. Elle est pratique car elle permet une mise en route facile et rapide pour les débutants, cependant ce n’est pas la méthode que l’on préconisera à une équipe avancée ou experte. Car avec le temps l’utilisation de tailles de T-shirt comme barème de notation rendra les  diverses opérations trop complexes à gérer pour l’ensemble de l’équipe. Par exemple se rappeler qu’un XL est 33% plus grand qu’un L n’est pas une chose que les développeurs auront en tête automatiquement à chaque estimation.

Sources : Site Point, Dave Farley’s, Moutain Goat Software

2 réflexions au sujet de « Technique d’estimation de User Story : Le T-shirt Size Estimating »

  1. Merci pour cet article très intéressant.

    L’usage des tailles de T-shirt n’a pas, a mon sens, vocation à remplacer l’estimation en story point. Elle doit avant tout servir un tout autre objectif, qui est de permettre de définir un niveau de granularité des items (story ou autre), qui rendra à terme les activités de la team agile prédictibles.

    Voici comment j’utilise cette technique d’estimation :

    1- Je propose à l’équipe d’estimer en T-shirt, pour évaluer le niveau d’effort à fournir pour réaliser un élément du backlog (jusque la rien de bien nouveau) ;
    2 – Je propose de poser le pré-requis suivant : Tous les items ayant une taille supérieur au L doivent être revues et découpées plus finement ;
    3 – Lorsque le product owner a finalisé 3 à 5 items, l’équipe prend un peu de temps (par exemple un timebox de 45′) pour vérifier que ces items respectent bien les principes INVEST et la DoR du backlog de développement (ou backlog de sprint en Scrum) ;
    4 – Lorsque les items sont validés, ils entrent dans le backlog de l’équipe et je mesure alors le temps de réalisation de chaque item ;
    5 – A partir des mesures réalisées, je peux visualiser un temps moyen de réalisation par taille d’item (cycle time de développement) et aussi visualiser le temps mis sur chacune des étapes de développement, comprenant la phase de test ;
    6 – A partir de ces mesures, on peut savoir si une taille met trop de temps à être réalisée. Si cela est le cas ont la retire de la DoR et celle-ci devra être découpée à l’avenir.

    Le résultat (expérimenté plusieurs fois, avec succès) :
    – Le product owner monte ne maturité dans le niveau de qualité de ses items et dans le niveau de granularité attendu par l’équipe de dév ;
    – On constate, sur 3 à 4 itérations, que le niveau granularité des items s’affine et que le temps de traitement d’un item devient proche, sur les tailles de t-shirt éligibles ;
    – Le Product Backlog devient prédictible, car on a une bonne vision du temps moyen de traitement d’un item ;
    – Le pilotage ne se fait plus par le nombre de story point réalisé, mais par la mesure du débit moyen de production (ho le vilain mot) d’item.

    J’espère avoir été clair dans mes explications :).

    • Bonjour Courthaïer,

      Merci à vous pour vos précisions. N’hésitez pas à nous faire part de vos retours d’expérience.

      À bientôt,

      Agilaction

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *