Le no estimate : une autre manière d’estimer En avant-propos je vous propose de casser tout de suite le mauvais sous-entendu, la méthode du « No estimate » N’EST PAS de ne plus estimer les User stories (US), mais c’est UNE AUTRE MANIERE d’ESTIMER une US. Et nous allons voir comment cela se fait et dans quelles conditions cela est possible et souhaitable.

Les origines du no estimate

Au fur et à mesure des sprints ou de la pratique de la méthode Agile, certaines personnes ont fait diverses constatations :

• La grande quantité de temps alloué au poker planning en Agile.
• Des estimations qui restent incertaines et fluctuent beaucoup en fonction de la composition d’équipe.
• D’après le cône de l’incertitude de McConnell certains tirent comme conclusion qu’un projet est en Moyenne +/-25% dans des erreurs d’estimations sur 75% du temps de projet (c’est extrêmement discutable voire complètement faux et inapplicable dans notre cas, mais ce n’est pas le sujet).

La problématique la plus importante constatée c’est l’utilisation des estimations et des vélocités :

• Les vélocités sont comprises/interprétées/traduites en temps de travail pour un livrable
  • « J’ai besoin de 100 points pour le delivery, je fais 50 points par sprint de 2 semaines » ainsi le programme manager traduit cela en delivery pour dans 4 semaines …
  • « Et puis ce que veut le management, c’est une projection en temps pour savoir quand est-ce qu’on atterrit. Donc on fait des règles de 3 pour convertir la complexité en temps. Bref avec les points de complexité, on est moins nuls, mais on est nuls quand même. »
  • « Je ne peux pas parler à mon client de points car ça ne veut rien dire pour lui »
• Dès qu’il y a un système de décompte de travail, les comptables ou delivery managers vont tenter de le traduire en force de travail ou quantité de travail afin de :
  • Réaliser des roadmaps, ou de fixer des dates de livraison.
  • Faire de la sélection de projet selon un ROI
  • Fixer le prix d’un projet (le triangle de fer de l’agilité est complétement oublié dans ce cas)
  • Et j’en passe…

DONC si les estimations ne servent pas ce pour quoi elles ont été créées dans le framework agile, et apportent plus de problématiques que de solutions, autant ne pas en faire : d’où la naissance du « no estimate ». Woody Zuill et Vasco Duarte sont les références en ce qui concerne cette méthode.

Les limites

Si suite à l’application du no estimate, le top management ou les parties externes recommencent à faire des produits en croix et utilisent le nombre d’US pour régler des dates de livrable, le problème sera toujours le même et non résolu.

Je proposerais dans ce cas de prendre le système le moins efficace pour estimer, car le plus flou dans sa forme, mais c’est sa force : l’estimation en poids d’animaux :

➡️ Même les plus obstinés se retrouvent dans une position ridicule quand ils commencent à dire « Bon dans 6 éléphants, 2 girafes, et 16 lions et 40 ouistitis je peux livrer dans 2 mois la nouvelle version … mais comment je vais dire ça au métier »

➡️ Le métier ne demandera pas non plus, « je vous commande 3 éléphants et que 4 girafes pour que vous puissiez livrer dans 2 semaines ».