Depuis que Vasco Duarte a popularisé le hashtag #NoEstimates en 2012, le sujet divise la communauté agile. D’un côté, les partisans de l’estimation rappellent que toute organisation a besoin de visibilité budgétaire. De l’autre, les tenants du #NoEstimates soutiennent que le temps passé à estimer serait mieux employé à livrer. Le débat, formulé ainsi, est une impasse. La question utile n’est pas “faut-il estimer?”, mais “qu’est-ce que l’estimation apporte réellement, et à qui?”.
D’où vient le malaise
L’estimation en gestion de projet prédictive remplit une fonction contractuelle: elle permet de s’engager sur un périmètre, un budget et un délai. Le triangle de fer (scope, coût, délai) structure cet engagement. En agile, ce triangle est explicitement remis en question. Le Manifeste Agile valorise la réponse au changement plutôt que le suivi d’un plan, ce qui implique que le périmètre n’est pas fixe. Si le périmètre bouge, l’estimation du périmètre initial perd sa raison d’être.
Le malaise apparait quand une organisation adopte les rituels agiles (sprints, daily, rétrospective) sans modifier ses mécanismes de gouvernance. Le sponsor continue d’exiger un budget et un calendrier fixés en amont. Le PMO (Project Management Office, structure de pilotage des projets) demande une estimation en jours-homme pour alimenter la planification de capacité. L’équipe se retrouve à faire du planning poker le lundi et à remplir un tableau de charge le mardi. Cette double contrainte est la source réelle du problème, pas l’estimation en tant que telle.
Ce que #NoEstimates propose réellement
Contrairement à ce que son nom suggère, le mouvement #NoEstimates ne recommande pas de supprimer toute forme de prévision. Il propose de remplacer l’estimation prédictive par la mesure empirique, en s’appuyant sur trois mécanismes complémentaires.
La décomposition fine constitue le premier levier. Si chaque item de travail (user story, tâche) est suffisamment petit pour être terminé en quelques jours, la variance entre items devient négligeable. Il n’est plus nécessaire d’estimer chaque item individuellement: le throughput (nombre d’items livrés par sprint) suffit pour projeter l’avancement.
La mesure du cycle time fournit le deuxième levier. Plutôt que de demander “combien de temps cela prendra-t-il?”, on observe combien de temps les items similaires ont pris dans le passé. Le cycle time (durée entre le début et la fin du traitement d’un item) constitue une base statistique pour les projections futures, bien plus fiable qu’une estimation ponctuelle.
Le troisième levier est la stabilité de l’équipe. Les données historiques n’ont de valeur prédictive que si les conditions de production restent comparables. Une équipe dont la composition change fréquemment ne produit pas de données exploitables, quelle que soit la méthode de mesure utilisée.
Pourquoi le débat est mal posé
Le vrai clivage n’est pas entre “estimer” et “ne pas estimer”. Il est entre deux conceptions de la prévisibilité. L’approche prédictive cherche à réduire l’incertitude en investissant dans l’analyse préalable: plus on sait avant de commencer, mieux on prédit. L’approche empirique accepte l’incertitude initiale et construit la prévisibilité en cours de route, par accumulation de données réelles.
Dave Snowden, créateur du framework Cynefin, distingue les domaines compliqués (analysables, prévisibles avec expertise) des domaines complexes (émergents, où les résultats ne sont visibles qu’après l’action). L’estimation prédictive est adaptée au domaine compliqué. Dans le domaine complexe, qui correspond à la réalité de nombreux projets, la seule prédiction fiable est celle qui s’appuie sur des mesures de ce qui s’est déjà passé.
Le planning poker illustre bien cette tension. En tant qu’exercice de discussion, il est précieux: il force l’équipe à expliciter ses hypothèses, à identifier les risques techniques, à aligner sa compréhension du travail. En tant qu’outil de prévision, il est fragile: les story points sont une estimation subjective et relative dont la fiabilité décroit dès qu’on les extrapole au-delà du sprint en cours.
Estimer pour comprendre, mesurer pour prévoir
La question pratique pour un chef de projet n’est pas de choisir un camp. C’est de distinguer deux fonctions que l’estimation remplit simultanément, et qui gagneraient à être séparées.
La première fonction est cognitive: estimer oblige à analyser le travail, à identifier les inconnues, à construire une compréhension partagée. Cette fonction est irremplaçable et ne nécessite pas de précision chiffrée. Un T-shirt sizing (S, M, L, XL) ou un simple “c’est petit, c’est gros, on ne sait pas” remplit ce rôle aussi bien qu’une estimation en story points.
La seconde fonction est prévisionnelle: donner une visibilité sur le calendrier et le coût. Cette fonction est mieux servie par les métriques de flux que par les estimations. Un throughput observé sur dix sprints est un meilleur prédicteur qu’un chiffrage initial du backlog, parce qu’il intègre la réalité du terrain (absences, bugs, dette technique, changements de priorité) que l’estimation ne peut pas anticiper.
En pratique, cela implique trois ajustements concrets pour les équipes en transition. Investir dans la décomposition des items plutôt que dans leur estimation détaillée: une story qui prend plus de cinq jours signale un problème de découpage, pas un manque de productivité. Stabiliser les équipes pour que les données historiques soient significatives. Communiquer en fourchettes plutôt qu’en dates fixes: “avec notre throughput actuel, nous livrerons entre 35 et 42 stories d’ici la fin du trimestre” est plus honnête et plus utile qu’un engagement sur un périmètre précis.
Les équipes qui fonctionnent le mieux ne sont pas celles qui ont choisi un camp dans le débat #NoEstimates. Ce sont celles qui utilisent chaque outil pour ce qu’il fait bien: l’estimation comme levier de compréhension, la mesure comme levier de prédictibilité.