No estimate

Le no estimate : une autre manière d’estimer En avant-propos, je vous propose de clarifier immédiatement un malentendu fréquent : la méthode du « No estimate » n’est pas une invitation à ne plus estimer les User Stories (US), mais une autre manière de les estimer. Nous allons voir comment cela fonctionne, et dans quelles conditions cette approche est possible et souhaitable. Les origines du no estimate Au fil des sprints et de la pratique de l’agilité, plusieurs constats ont émergé : Le temps considérable consacré au Poker Planning. Des estimations incertaines, très dépendantes de la composition de l’équipe. Le cône d’incertitude de McConnell, dont certains concluent — à tort ou à raison — qu’un projet comporte en moyenne ±25 % d’erreur d’estimation sur 75 % de son cycle (affirmation discutable, voire inexacte dans notre contexte, mais ce n’est pas le sujet). La problématique la plus importante concerne l’usage réel des estimations et de la vélocité. La vélocité est souvent interprétée comme du temps de travail. Par exemple : « Il me faut 100 points pour le delivery, je fais 50 points par sprint de 2 semaines, donc je livre dans 4 semaines. » « Le management veut une projection temporelle, donc on convertit les points par règles de trois : on est moins mauvais, mais on reste mauvais. » « Je ne peux pas parler à mon client en points, cela ne veut rien dire pour lui. » Dès qu’un système de mesure existe, certains rôles (comptables, PMO, Delivery Managers, etc.) cherchent à le convertir en charge, afin de : produire des roadmaps, fixer des dates de livraison, calculer un ROI, voire fixer le prix d’un projet (oubliant totalement le triangle de fer de l’agilité), etc. Donc, si les estimations ne servent pas leur objectif premier et génèrent plus de problèmes que de solutions, une conclusion émerge : autant ne pas en faire. C’est dans ce contexte qu’est né le mouvement « No estimate ». Woody Zuill et Vasco Duarte en sont les principales références. Le no estimate, ou une autre manière d’estimer Contrairement à ce que son nom laisse penser, le « No estimate » n’est pas une méthode de non-estimation. Il change simplement l’unité de mesure : on ne parle plus de story points, de tailles de t-shirts ou de poids d’animaux. Le « No estimate » se base sur le nombre d’US et/ou de tâches réalisées. C’est donc le nombre d’US terminées pendant un sprint qui sert à définir la vélocité du sprint suivant. C’est également ce volume qui permet d’anticiper la capacité de l’équipe et d’éviter la surcharge. Et… c’est tout ? En théorie, oui. Mais il existe une condition absolument essentielle : vos User Stories doivent être parfaites. Elles doivent être rédigées par un PO expérimenté, capable de produire des US irréprochables. Pour mémoire, voici les critères INVEST, avec les points critiques dans le cadre du « No estimate » : Independent : chaque US doit être indépendante. Point critique : rarement le cas, sauf si l’US est suffisamment petite. Negotiable : le scope doit être ajustable. Valuable : chaque US doit apporter de la valeur. Point critique : conserver la valeur malgré un découpage fin. Estimable : la compréhension doit permettre l’estimation lors des refinements. Small : les US doivent être aussi petites que possible. Point critique principal, car c’est l’unité de mesure. Testable : chaque US doit être vérifiable. Conclusion intermédiaire : ce n’est que si vos US respectent rigoureusement INVEST que le « No estimate » est réellement applicable. Limites Si, après avoir adopté le « No estimate », le top management recommence à faire des produits en croix pour fixer des dates, alors le problème restera le même, simplement avec une autre unité. Dans ce cas, je serais presque tenté de proposer l’estimation… en poids d’animaux. Exemple : « Dans 6 éléphants, 2 girafes, 16 lions et 40 ouistitis, on livre dans 2 mois… mais comment l’annoncer au métier ? » Le métier ne dira jamais : « Je vous commande 3 éléphants et 4 girafes pour livrer en 2 semaines. » Cette absurdité a un mérite : elle empêche la conversion en jours, et rappelle que l’estimation n’est pas une donnée contractuelle. Conclusion Le « No estimate » n’est pas l’absence d’estimation. C’est un changement d’unité, basé sur le nombre d’US réalisées. Cette approche n’est valable que si les User Stories sont parfaitement découpées et maîtrisées. Dans le cas contraire, elle ne fera qu’amplifier les problèmes. Pour aller plus loin (Source): https://blog.cellenza.com/actualite-cellenza/estimer-sans-estimer/ https://blog.octo.com/noestimates-un-an-de-projet-faisons-le-bilan/ https://fr.slideshare.net/agilemtl/noestimates-vs-estimates-vraiment