Pourquoi ne plus 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 en lieu et place des jours-hommes.

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

Pourquoi ne plus utiliser les jours-hommes ?

Dans les techniques d’estimation 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’utiliser 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.

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 ?

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 peut correspondre à une tâche S de l’équipe B et à une tâche L de l’équipe C.

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, celle-ci sera forcément ré-estimée par l’équipe B.

Comment estimer par comparaison relative ?

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 étalon S et moins de travail qu’une story étalon L ?

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.

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 entre la suite de fibonacci et les tailles de t-shirt :

XSSMLXL
235813

Dans votre outil de gestion de backlog 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, tout en simplifiant les estimations par les équipes.

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

Comment faire la transition ?

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.