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.
Le no estimate, ou une autre manière d’estimer
Le « No estimate » contrairement à son nom n’est pas une méthode de non-estimation. Le “No estimate” change l’unité de mesure, qui ne sont pas des story point ou des tailles de T-shirt, ou des poids d’animaux ; le « No estimate » mesure en fonction du nombre de tâches et / ou d’US.
C’est le nombre d’US passées pendant un sprint qui va définir la vélocité du prochain sprint, c’est aussi ce nombre de tâches qui va permettre de dire la quantité de travail de l’équipe afin de travailler efficacement sans surcharger le sprint.
Et c’est tout ?
En soit, oui, mais il y a 1 seule condition extrêmement forte pour que le « No estimate » fonctionne pour de vrai : Vos US sont PARFAITES !!! et dans le vrai sens du terme : c’est-à-dire que le PO qui rédige les US est expérimenté et il qu’il produit des US irréprochables :
Voici un rappel de la méthode la plus connue (INVEST) avec les points les plus critiques pour la pratique du « no estimate » :
- Independant: chaque User Story est indépendante et ne nécessite pas d’autres User Stories pour être réalisée.
- ➡️ Point critique : c’est rarement le cas sauf si l’US est suffisamment petite
- Negotiable: le scope des User Stories doit être négociable afin de pouvoir adapter le plan tout au long de l’itération si l’on observe que l’on ne pourra pas atteindre l’objectif de sprint.
- Valuable: chaque User Story doit apporter de la valeur à l’utilisateur.
- ➡️ Point critique : conserver de la valeur business malgré la petite taille de l’US.
- Estimable: chaque User Story doit pouvoir être estimée lors des sessions de refinement.
- Small (suffisamment petite): afin de maximiser le nombre d’User Stories terminées et faciliter leur réalisation, il vaut mieux avoir des User Stories les plus petites possibles.
- ➡️ Point critique le plus important. Etant donné que c’est l’unité de mesure
- Testable: Chaque User Story doit pouvoir être testée une fois réalisée.
Donc uniquement dans le cas où vos US sont irréprochables, alors le « no estimate » peut être une solution.
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 ».
Conclusion
Le no estimate n’est pas une méthode sans estimation, c’est un changement d’unité de mesure d’estimation par le nombre d’US. Elle n’est valable que si le principe et le découpage des User Stories est vraiment parfait.
Merci pour votre lecture !