L’estimation est l’un des sujets les plus débattus dans les communautés Agile. Les débats vont généralement comme ceci : Story Points contre heures, dimensionnement relatif contre absolu, #NoEstimates contre quelques estimations, planning poker contre ce qui est venu après.
Ce sont de vrais débats. Et ils ont tendance à manquer le problème plus profond — à savoir que les arguments sur comment estimer remplacent une conversation sur si le modèle d’estimation lui-même est le problème.
Ce qu’Agile a réellement dit sur l’estimation
Agile n’est pas né pour aider les équipes à mieux estimer. Il est né parce que quelqu’un a remarqué que dans le travail complexe — un travail où les exigences complètes ne peuvent pas être connues à l’avance, où la bonne approche se révèle par la pratique — la précision que l’estimation promet est une fausse précision.
Ce que signifie réellement le “travail complexe”
Cette expression — travail complexe, travail où les exigences complètes ne peuvent pas être connues à l’avance — est facile à passer. Elle ne devrait pas l’être. C’est l’affirmation la plus structurante de cet article, et sans l’intérioriser, tout ce qui suit peut être entendu comme un argument sur les techniques d’estimation plutôt que sur l’aptitude de l’estimation à l’objectif.
Le travail complexe n’est pas une description de projets où l’équipe n’était pas assez intelligente, ou rigoureuse, ou où la bonne méthodologie n’avait pas encore été appliquée. Il désigne une catégorie spécifique : un travail où la relation entre cause et effet ne peut être comprise qu’en rétrospective. Où la bonne approche se révèle par la pratique, et non par l’analyse. Où les exigences changent non pas parce que les parties prenantes ont manqué de réflexion préalable, mais parce que faire le travail change ce dont on a besoin.
Les méthodologies — même excellentes — sont construites pour le travail simple et compliqué. Elles fonctionnent en appliquant des schémas connus à des types de problèmes connus. C’est précisément leur valeur dans les contextes pour lesquels elles ont été conçues. Le travail complexe n’a pas de schémas connus. Il en a des émergents. Appliquer une méthodologie au travail complexe ne résout pas le problème — cela crée l’illusion de structure tandis que l’incertitude réelle reste intacte. Les mini-cascades — la planification séquentielle à cycle court que de nombreuses implémentations Agile sont silencieusement devenues — tombent dans la même catégorie. La durée de l’itération change ; l’hypothèse sous-jacente que la planification en amont peut guider de manière fiable le travail ne change pas.
La “simplification impitoyable” est une prescription connexe qui mérite examen. Si le travail peut véritablement être simplifié en un type de problème connu, simplifiez-le — c’est une bonne pratique. Mais c’est de l’hygiène, pas de la gestion de travail complexe. Ce qui reste après toute simplification possible est la partie qui y résiste, c’est-à-dire le travail complexe lui-même, nécessitant quelque chose que les stratégies de simplification ne sont pas conçues pour fournir. En 2025, si la réponse compétitive à la complexité est “nous devrions simplifier davantage”, la conversation sur la gestion réelle du travail complexe n’a pas encore commencé.
Le revirement public de Jeffries n’est pas seulement un changement d’avis sur une unité de mesure. C’est la reconnaissance de quelque chose de plus profond : la prémisse était fausse. L’estimation suppose une catégorie de travail où l’analyse en amont produit des prévisions fiables. Pour le travail simple et compliqué, cette hypothèse tient raisonnablement bien. Pour le travail complexe, elle ne tient pas — et aucun perfectionnement de la technique ne la fera tenir. Cette réalisation, une fois intériorisée, change ce dont parle le reste de cet article.
Un sprint de deux semaines livrant du logiciel fonctionnel n’est pas une meilleure méthode d’estimation. C’est un remplacement de l’estimation par la mesure empirique. Au lieu de prédire combien de temps le travail prendra, vous mesurez combien est réellement accompli, dans des conditions réelles, en incréments réels. La prédiction est remplacée par une cadence et une boucle de rétroaction.
Ce n’est pas une distinction subtile. Cela signifie que les équipes qui exécutent des processus Agile mais traitent encore l’estimation précise des Story Points comme l’objectif ont fondamentalement mal compris à quoi sert le processus.
Pourquoi les arguments persistent
Le débat sur l’estimation persiste en partie parce que les organisations qui ont adopté Agile n’ont pas abandonné leur besoin sous-jacent : des systèmes de gestion construits sur des prévisions, des budgets, des délais, des contrats. Les cérémonies Agile ont été superposées à ce besoin. Les Story Points sont devenus un substitut aux heures. La vélocité est devenue un intrant de planification. Le vocabulaire Agile a été adopté ; l’attente de prévision n’a pas été abandonnée.
La situation qui en résulte est réellement contestée. Certaines équipes opèrent dans des environnements où “pas d’estimations” est réellement possible — où les parties prenantes ont appris à faire confiance à la livraison empirique et n’ont pas besoin de prévisions. D’autres équipes opèrent dans des environnements où les contrats, les exigences réglementaires ou la culture organisationnelle rendent une forme de prévision inévitable.
La position Agile n’est pas que l’estimation est toujours fausse. C’est que l’estimation dans le travail complexe est structurellement peu fiable — que la confiance attachée aux estimations dépasse régulièrement les preuves à leur appui — et que la discipline des cycles de livraison courts avec une rétroaction réelle fait plus pour améliorer la prévisibilité que de meilleures méthodes d’estimation.
Le problème des unités — et un schéma qui vaut la peine d’être noté
Une tendance actuelle dans les cercles Agile est de s’éloigner des Story Points vers les Jours Idéaux (IPDs) — un retour à l’estimation basée sur le temps que ses défenseurs soutiennent être plus intuitive et plus facile à défendre auprès des parties prenantes.
Il vaut la peine de savoir d’où viennent les Story Points. Ron Jeffries — l’un des trois fondateurs d’Extreme Programming et signataire original du Manifeste Agile — a inventé les Story Points. Ils sont apparus directement à partir des jours idéaux, l’unité basée sur le temps qu’utilisaient initialement les équipes XP. Le problème avec les jours idéaux était que les parties prenantes entendaient “trois jours idéaux” et interprétaient cela comme un engagement de trois jours, quel que soit le qualificatif “idéal”. Alors l’étiquette temporelle a été supprimée, et le nombre brut est devenu l’unité. Les Story Points étaient, à l’origine, des jours idéaux avec la référence temporelle supprimée spécifiquement pour éviter qu’ils soient traités comme des engagements de temps.
Jeffries a depuis écrit directement à ce sujet. “J’aime dire que j’ai peut-être inventé les Story Points”, a-t-il écrit en 2019, “et si c’est le cas, je le regrette maintenant.” Il est maintenant parmi les défenseurs les plus éminents de #NoEstimates — la position que le problème n’est pas l’unité d’estimation que vous utilisez, mais que l’estimation dans le travail complexe est fondamentalement peu fiable quelle que soit l’unité.
Il vaut la peine de se demander pourquoi le passage aux IPDs se produit maintenant. La réponse n’est pas que les équipes ont trouvé une meilleure méthode d’estimation. C’est que les IPDs s’alignent avec l’infrastructure financière du modèle en cascade — les cycles budgétaires, les systèmes de comptabilité de projet, les modèles de facturation des contrats et les outils de planification des effectifs que les organisations ont construits autour de la planification basée sur le temps et n’ont jamais changés lorsqu’elles ont adopté Agile. Les Story Points ne s’intègrent pas dans ces systèmes. Les IPDs, oui.
Ce n’est pas une évolution d’Agile. C’est la cascade qui continue de se réaffirmer avec les habits d’Agile — en utilisant les structures financières qui n’ont jamais été démantelées pour ramener la pratique vers le modèle pour lequel ces structures ont été construites. L’unité d’estimation a changé ; le système organisationnel exigeant des engagements basés sur le temps n’a pas changé. Le résultat est le même théâtre de prévision, juste avec un nouveau nom.
Ce ne sont pas des entreprises prenant enfin les choses en main et corrigeant ce qu’Agile a manqué. Ce sont des entreprises réaffirmant l’infrastructure qui n’a jamais changé. Les IPDs ne nécessitent aucun changement de pensée, de compréhension ou d’état d’esprit — vous réétiquetez simplement ce que vous savez déjà. C’est précisément pourquoi ils gagnent du terrain.
La communauté Agile a manqué une opportunité de leadership ici. Quand la demande de prévisions basées sur le temps est revenue déguisée en IPDs, la bonne réponse était de nommer ce qui se passait : c’est la finance en cascade qui se réaffirme sur la pratique Agile. Au lieu de cela, de nombreux praticiens l’ont accommodée, traitant la demande comme une contrainte à gérer plutôt qu’une erreur de catégorie à corriger. Le résultat est que les équipes qui maîtrisent le mieux le vocabulaire Agile exécutent souvent la version la plus sophistiquée du modèle qu’Agile était conçu pour remplacer.
L’humanité apprend lentement
Il y a un schéma ici qui va plus profond que la méthodologie d’estimation. C’est le schéma de traiter un changement d’étiquette comme un changement de pratique — de confondre l’adoption d’un nouveau vocabulaire avec le changement de pensée que ce vocabulaire était censé représenter.
La définition de la folie par Einstein est souvent citée, généralement mal attribuée, mais toujours résonnante : faire la même chose encore et encore en attendant des résultats différents. L’attribution est probablement apocryphe. Le schéma ne l’est pas. Les organisations qui ont adopté les cérémonies Agile sans adopter la pensée Agile adoptent maintenant les cérémonies de remplacement d’Agile sans examiner si la pensée sous-jacente a changé. Les mots sont différents. Le modèle est le même.
La conversation que cet article essaie d’ouvrir ne porte pas sur les unités d’estimation. Elle porte sur la question de savoir si votre organisation a réellement examiné ce qu’est le travail complexe et ce qu’il exige. Si la réponse est que votre infrastructure de planification n’a pas changé — que vous avez encore besoin de prévisions, d’engagements et d’une comptabilité basée sur le temps qui supposent que l’analyse en amont produit des prédictions fiables — alors le débat sur l’estimation est un symptôme. La condition qu’il pointe est que le changement qu’Agile proposait ne s’est pas encore produit.
Commentaires 0