Pouvons-nous estimer sans utiliser les jours-hommes ?

Échelle de complexité : le T-shirt sizing

Pour exprimer l’effort ou la complexité d’un incrément de valeur, nous essayons aujourd’hui, dans les équipes agiles, d’utiliser le format de tailles de T-shirt, et de fait, d’estimer sans utiliser les jours-hommes.

Cette échelle de complexité uniforme et relative est applicable à tout élément du backlog : feature, User Story, Technical, Bug, Kaizen…

Pourquoi estimer sans utiliser les jours-hommes ?

Dans les techniques d’estimation des projets menés en agile, nous appliquons la philosophie de Warren Buffet : “Mieux vaut avoir approximativement raison  qu’avoir  précisément tort ! ”.

Pour comprendre, dites-vous qu’il est beaucoup plus facile de dire quel immeuble est le plus grand ou le plus petit que d’estimer la hauteur de chaque bâtiment. En agile on ne parle pas de chiffrage (trop prédictif) mais d’estimation de l’effort à fournir pour réaliser une story ou une feature. Cet effort n’a pas vocation à être précis, mais simplement à nous assurer que la réalisation pourra être faite dans le temps d’une itération. Si l’effort est grand la story peut/doit être découpée.

Et bien évidemment, il faut éviter d‘estimer avec le jour-homme, car il dépend de l’homme en question et de son contexte spatio-temporel (dans une équipe à un instant donné).

Pourquoi ne plus utiliser de série de nombres (comme la suite de Fibonacci) ?

Il est important de limiter l’échelle d’estimation pour obtenir des éléments de backlog à être de taille similaire, petits et verticaux. Une échelle commune entre toutes les équipes est un facilitant pour les métiers qui peuvent (sont) être transverses et ainsi éviter des valeurs spécifiques (0.5, 20 ou 21 ?, 40…).

Et bien sûr, il est très important de ne pas faire de lien – inconsciemment ou non – avec des jours-hommes quand on utilise des chiffres.

De plus, une échelle limitée comme les tailles de T-shirt est propice à la génération d’indicateurs exploitables (calcul de temps de cycle, date d’atterrissage…).

Travailler sur une échelle commune nous permettra-t-il d’avoir un backlog commun à toutes les équipes ?

Naturellement, la réponse est non (et là il faut être ferme et catégorique). Si l’échelle S/M/L reste la même dans toutes les équipes, chaque équipe aura son propre étalon. Cela signifie qu’une tâche estimée en M dans une équipe A ne correspond pas à une tâche M dans l’équipe B. Les deux équipes sont différentes.

Ainsi, si une feature a reçue une première estimation par l’équipe A et que l’équipe B est amenée à la réaliser, l’estimation sera obligatoirement refaite par l’équipe B.

Comment estimer par comparaison relative sans utiliser les jours-hommes ?

Il faut se baser sur des éléments de référence (étalons) pour chacune des tailles de T-shirt.

La question à se poser pour estimer une nouvelle story est donc maintenant :

• où se situerait ma story en termes de complexité par rapport à cet étalon ?
• est-ce qu’une story que je place en M correspond bien à plus de travail qu’une story en S ?

Comment faire pour calculer un ROI avec une taille de t-shirt ?

Le ROI est le résultat de la division entre la charge et la valeur métier. Typiquement en SAFe le WSJF sera calculé pour permettre la priorisation des backlogs est se basant sur cette valeur (attention quand même de ne pas faire votre priorisation uniquement avec le WSJF, cette technique est précisément fausse …).

De plus de nombreux outils de calculs de métriques, comme EazyBI, vont avoir besoin de chiffre pour bâtir les indicateurs et calculer le ROI ou WSJF.

Ma solution, qui n’engage que moi, est de créer une matrice de correspondance. Cette matrice fera la correspondance entre la suite de fibonacci et les tailles de t-shirt :

Dans votre outil de gestion de backlog agile préféré, vous affichez une liste de choix avec les tailles de T-Shirt mais en base de données vous enregistrez la correspondance avec la suite de fibonacci.

Ainsi, vous pouvez continuer à calculer un ROI pour prioriser. Vous simplifierez ainsi les estimations par les équipes. Vous pourrez également, au bout de quelques itérations, calculer le référentiel de chaque équipe.

Pour les équipes en Scrum, cette technique vous permet aussi de calculer la vélocité des équipes.

Comment faire la transition ?

Estimer sans utiliser les jours-hommes dans de nombreux contexte n’est pas simple, c’est un changement profond de “logiciel de pensée”. Comme toujours, il faut y aller doucement. Je vous conseille d’expérimenter et de mettre au point cette technique dans une équipe pilote. Et ensuite, communiquer largement le retour de cette expérimentation aux autres équipes avant de la généraliser.