Comprendre la philosophie « no estimates » : son origine, ses principes

Introduction

Dans le domaine du développement logiciel et de la gestion de projet agile, l’une des questions récurrentes est la suivante : comment estimer le temps et les ressources nécessaires à la réalisation d’une fonctionnalité, d’un sprint ou d’un projet complet ? Pendant des années, les équipes se sont appuyées sur des méthodes traditionnelles d’estimation des tâches, comme l’attribution de points de complexité (story points), l’utilisation du planning poker ou des estimations en jours-hommes. Pourtant, depuis quelque temps, un courant de pensée s’est développé, remettant en question la nécessité, voire la pertinence, de ces estimations. Cette philosophie, baptisée « no estimates », fait de plus en plus parler d’elle.

Le mouvement « no estimates » n’est pas simplement une posture de défiance envers les pratiques établies. Il s’appuie sur des réflexions profondes autour de la productivité informatique, de la réduction de l’incertitude dans le développement logiciel, et de la recherche d’une approche plus fluide, plus adaptable, et plus orientée vers la valeur réelle délivrée aux utilisateurs. L’objectif n’est pas de rejeter la planification, mais de remettre en cause les mécanismes rigides de l’estimation, souvent sources de frustration, d’imprécisions et de tensions dans les équipes.

Dans cet article, nous allons explorer en détail l’origine, les principes et les motivations du mouvement « no estimates ». Nous verrons comment il s’inscrit dans l’évolution des méthodes agiles et du management de projet, quelles sont les approches concrètes pour le mettre en pratique, et comment il s’articule avec d’autres concepts tels que les principes Lean, les flux de travail en continu, le throughput et le cycle time. Nous discuterons également de ses avantages, de ses limites, de ses critiques, et nous proposerons des pistes pour tester et adopter cette philosophie au sein de votre propre organisation.

Contexte historique et origine du mouvement « no estimates »

Pour comprendre la genèse de « no estimates », il faut d’abord se pencher sur l’histoire de l’estimation en développement logiciel. Dès les débuts de l’informatique, la question « Combien de temps cela va-t-il prendre ? » était omniprésente. Les responsables de projet, les Product Owners, les clients et autres parties prenantes cherchaient à se rassurer, à budgéter, à planifier, et à aligner les investissements avec les résultats attendus. Les premières méthodes de planification, héritées du génie civil ou de l’ingénierie, se sont vite révélées inadaptées à la complexité et à l’imprévisibilité du développement logiciel.

Avec l’émergence des méthodes agiles dans les années 1990-2000, des pratiques comme les story points, le planning poker et les estimations relatives ont vu le jour. Elles visaient à améliorer l’approximation du travail à fournir, en tenant compte de l’incertitude et en offrant une plus grande flexibilité. Pourtant, même ces méthodes, perçues comme plus légères que les approches traditionnelles de planification, sont restées une forme d’estimation. Et qui dit estimation, dit souvent écart entre prévision et réalité.

Au fil du temps, des voix se sont élevées au sein de la communauté agile pour questionner la pertinence même de l’estimation. Pourquoi continuer à gaspiller de l’énergie cognitive et du temps de réunion pour des chiffres qui, finalement, s’avèrent rarement exacts ? C’est dans ce contexte que des personnalités influentes, comme Woody Zuill, ont commencé à promouvoir l’idée selon laquelle on pouvait se passer d’estimations. Le hashtag #NoEstimates a émergé sur Twitter, rassemblant des professionnels qui partageaient des expériences, des réflexions et des arguments visant à montrer que l’on peut piloter un projet sans passer par l’étape périlleuse de l’estimation chiffrée.

Les principes et fondements théoriques de la philosophie « no estimates »

La philosophie « no estimates » ne propose pas un cadre méthodologique figé. C’est davantage un ensemble de principes, d’idées et de questionnements qui invitent à repenser la façon dont on aborde la livraison de valeur dans un projet logiciel. Parmi les principes majeurs, on retrouve :

1. Se concentrer sur la valeur et l’impact plutôt que sur les chiffres : Au lieu de chercher à prédire combien de temps prendra une fonctionnalité, on s’interroge sur l’importance réelle de celle-ci pour les utilisateurs. Que gagnent-ils si cette fonctionnalité est livrée ? Quel problème résout-elle ? En orientant l’attention sur la valeur délivrée, on réduit l’importance de la durée.

2. Optimiser le flux plutôt que prévoir le temps : La philosophie « no estimates » encourage à améliorer le flux de travail en continu, inspiré par le Kanban et les principes Lean, plutôt que d’investir du temps et de l’énergie dans des estimations. L’idée est de rendre le processus de livraison plus fluide, de réduire les goulots d’étranglement, et d’augmenter le throughput (nombre d’éléments livrés par unité de temps).

3. Utiliser des métriques empiriques au lieu de deviner : Plutôt que d’estimer en amont, on se base sur les données historiques de l’équipe. Combien d’éléments (user stories, par exemple) l’équipe livre-t-elle en moyenne par semaine ou par sprint ? Quel est le cycle time moyen (délai entre le début et la fin d’un élément) ? Ces données, mesurées empiriquement, offrent une vision plus réaliste que des estimations basées sur des hypothèses incertaines.

4. Accepter l’incertitude et l’adapter à la demande : Le développement logiciel est incertain par nature. Au lieu de lutter contre cette réalité, « no estimates » invite à l’accepter et à ajuster en continu, en fonction des retours des utilisateurs, des imprévus techniques et de la réévaluation des priorités.

5. Minimiser la charge mentale et la frustration associées aux estimations : Les séances d’estimation peuvent être longues, pénibles et sources de tension. En s’en passant, on libère du temps et de l’énergie pour des activités à plus forte valeur ajoutée, comme la conception, le développement, la revue de code ou la communication avec les stakeholders.

Les motivations derrière « no estimates »

La quête de « no estimates » ne repose pas sur un simple caprice idéologique. Elle répond à des problèmes concrets, fréquemment rencontrés dans le management de projet et le développement logiciel :

1. Précisions trompeuses : Les estimations traditionnelles donnent l’illusion de précision. Or, même les meilleurs développeurs peinent à prévoir la durée exacte d’une tâche complexe, surtout lorsque des incertitudes techniques, des dépendances externes et des exigences changeantes entrent en jeu.

2. Pression sur l’équipe : Une fois une estimation établie, elle tend à devenir un engagement, voire une promesse. Les équipes subissent alors une pression pour « tenir » l’estimation, même si les conditions ont changé. Cela peut mener à du stress, à des raccourcis techniques, et à une baisse de la qualité.

3. Perte de temps : Les activités d’estimation sont parfois chronophages. Le temps passé à débattre sur le nombre de story points à attribuer à une tâche pourrait être utilisé pour réellement avancer sur le code, améliorer les tests, ou discuter avec le Product Owner afin de mieux comprendre les besoins.

4. Focalisation sur la quantité au détriment de la qualité : Les estimations, en mettant l’accent sur la durée, ont tendance à faire oublier la qualité du résultat. On peut livrer dans les temps (selon une estimation) un logiciel qui n’est pas stable, pas maintenable, ou qui ne répond pas aux attentes réelles des utilisateurs.

5. Coûts et délais mal compris : Même si l’on multiplie les efforts pour affiner les estimations, on aboutit souvent à des plannings qui ne reflètent pas la réalité. Les budgets peuvent exploser, les deadlines être dépassées, et cela crée une forme de défiance entre l’équipe de développement, la direction, et les clients.

Méthodes et outils pour mettre en œuvre « no estimates »

Adopter la philosophie « no estimates » ne signifie pas travailler sans aucun repère ni indicateur. Au contraire, il s’agit de remplacer les estimations par d’autres outils, métriques et pratiques plus orientés vers la livraison continue et la compréhension du flux de travail.

1. Focalisation sur le flux de travail en continu

L’un des points clés consiste à adopter des pratiques inspirées du Kanban, où l’on visualise le flux de travail via un tableau. Chaque élément traverse des colonnes (À faire, En cours, En test, Fait…), et l’équipe cherche à limiter le « work in progress » (WIP) pour éviter l’accumulation de tâches en souffrance. La philosophie « no estimates » s’intègre bien ici, puisque l’objectif est de rendre le flux aussi régulier et prévisible que possible sans devoir estimer chaque item.

2. Mesurer le throughput et le cycle time

Le throughput est le nombre d’éléments (features, user stories, bugs résolus) livrés sur une période donnée. Le cycle time, quant à lui, est le temps nécessaire pour réaliser un élément de bout en bout. Ces données sont collectées de manière empirique, simplement en observant l’activité de l’équipe. En connaissant le throughput moyen et le cycle time, on peut donner des indications plus fiables à un Product Owner : « Nous livrons en moyenne 5 user stories par semaine » ou « Une tâche met environ 3 jours à passer de ‘À faire’ à ‘Fait’ ». Ces informations sont plus utiles et fiables que des estimations initiales, car elles se fondent sur la réalité du travail effectué.

3. Ajustement continu des priorités

Plutôt que de définir à l’avance toutes les fonctionnalités avec des estimations, la philosophie « no estimates » encourage une priorisation continue. Le Product Owner peut réévaluer chaque semaine ou chaque sprint les éléments les plus importants à livrer, en se fondant sur les retours des utilisateurs et la vision produit. Les équipes livrent en continu, et les fonctionnalités les plus urgentes ou précieuses prennent le pas, sans perdre de temps en estimations infructueuses.

4. Communication et collaboration

Sans estimations, la communication au sein de l’équipe, ainsi qu’entre l’équipe et les parties prenantes (direction, clients, sponsors), devient cruciale. Il s’agit d’expliquer pourquoi on ne fournit pas d’estimations traditionnelles, mais plutôt des indicateurs de performance réels (throughput, cycle time). L’équipe doit partager régulièrement l’état d’avancement, les difficultés rencontrées, et proposer des ajustements. Cette transparence renforce la confiance et le partenariat entre les différents acteurs du projet.

5. Outils logiciels de suivi

Il existe aujourd’hui de nombreux outils (Jira, Trello, Azure DevOps, etc.) qui permettent de visualiser le flux de travail, de mesurer le throughput et le cycle time, et de suivre les tendances. Ces outils facilitent la mise en œuvre de « no estimates » en fournissant des données concrètes et historiques, sans besoin de réunions d’estimation récurrentes.

Comparaison avec les approches traditionnelles (story points, planning poker, Scrum)

Il est intéressant de comparer « no estimates » aux approches traditionnelles afin de mieux saisir la différence conceptuelle :

1. Story points et planning poker : Les story points attribuent une valeur abstraite à la complexité d’une tâche. Le planning poker est une méthode pour atteindre un consensus sur ces points. Ces techniques restent dans le domaine de l’estimation, même si elles sont plus souples que les jours-hommes. « No estimates » s’affranchit de ces valeurs arbitraires et se concentre sur des indicateurs réels.

2. Scrum et ses sprints prévisibles : Scrum prévoit des sprints de durée fixe, avec des objectifs déterminés à l’avance. On y utilise souvent les story points pour estimer la capacité de l’équipe sur un sprint. Avec « no estimates », on continue d’utiliser la cadence courte (itérations), mais on ne se préoccupe plus de prévoir précisément la quantité de travail réalisable dans un sprint. On se base sur la performance passée pour guider la planification, sans chiffrage détaillé en amont.

3. Kanban et flux tiré : Kanban, déjà très axé sur le flux, se prête particulièrement bien à l’approche « no estimates ». Au lieu de planifier un ensemble de tâches pour une itération, on laisse le flux tirer le travail. Les limites WIP et le suivi du cycle time sont parfaitement compatibles avec l’absence d’estimation. En somme, Kanban et « no estimates » partagent une philosophie semblable : se concentrer sur la fluidité et l’amélioration continue, plutôt que sur la prévision.

Critiques et limites de « no estimates »

Aussi séduisante que soit cette philosophie, elle n’est pas exempte de critiques et de limites :

1. Difficultés d’adoption dans certains contextes : Certains secteurs, comme l’aéronautique ou la défense, requièrent des plannings précis et des engagements fermes pour des raisons légales, contractuelles ou réglementaires. Dans de tels environnements, « no estimates » pourrait être difficile à faire accepter.

2. Requiert une maturité agile : Pour que « no estimates » fonctionne, l’équipe doit déjà être à l’aise avec les pratiques agiles, la visualisation du flux, l’amélioration continue, et la communication transparente. Sans cette base solide, le passage à « no estimates » risque d’être perçu comme du chaos.

3. Peut inquiéter les parties prenantes : Certains stakeholders, habitués à obtenir des chiffres et des deadlines, pourraient être perturbés par l’absence d’estimations. Il faudra donc un effort de pédagogie pour expliquer le bien-fondé de cette approche, et montrer que d’autres indicateurs (comme le throughput) peuvent offrir une forme de prévisibilité, sans estimation chiffrée.

4. Ne supprime pas l’incertitude, la transfère : « No estimates » ne résout pas miraculeusement l’incertitude inhérente au développement logiciel. Il change simplement la façon de l’aborder. Les équipes doivent tout de même gérer les imprévus, les retards et les changements de priorités. Elles le font cependant d’une manière plus adaptée, sans l’illusion de contrôle qu’apportent les estimations.

Conseils pour adopter ou tester une approche « no estimates »

Si vous souhaitez expérimenter « no estimates » dans votre équipe ou votre organisation, voici quelques pistes :

1. Commencez par une équipe pilote : Au lieu de généraliser tout de suite, testez l’approche avec une seule équipe. Choisissez une équipe mature, familiarisée avec les méthodes agiles, et disposée à remettre en question ses pratiques.

2. Mesurez votre flux avant de supprimer les estimations : Avant d’abandonner les estimations, commencez par mesurer votre throughput et votre cycle time sur quelques sprints. Ces données serviront de base de comparaison pour plus tard, et vous permettront de donner des repères aux parties prenantes.

3. Communiquez en interne : Expliquez clairement à la direction, aux Product Owners et aux autres acteurs ce qu’est « no estimates » et pourquoi vous souhaitez l’essayer. Soulignez les bénéfices attendus (réduction de la charge mentale, amélioration de la flexibilité, meilleure adaptation à l’incertitude).

4. Surveillez les effets et ajustez en continu : Durant la période d’expérimentation, observez les effets sur la productivité, le moral de l’équipe, la satisfaction des parties prenantes. Ajustez votre processus si nécessaire. Peut-être que vous conserverez certaines formes légères d’estimation, ou que vous renforcerez la mesure du throughput pour donner plus de visibilité.

5. Soyez prêt à itérer et à apprendre : « No estimates » est plus un cheminement qu’une destination finale. Il s’agit d’une approche pragmatique, basée sur l’empirisme. L’essentiel est de rester ouvert, de tirer des enseignements de chaque itération, et d’adapter votre pratique au contexte de votre organisation.

Conclusion et perspectives d’avenir de « no estimates » dans la gestion de projet

La philosophie « no estimates » invite les équipes et les organisations à remettre en question un pilier historique de la gestion de projet agile et du développement logiciel : l’estimation des tâches. En proposant de se focaliser sur la valeur, le flux, le throughput et le cycle time, plutôt que sur des chiffres hypothétiques, « no estimates » offre une nouvelle perspective. Elle permet de travailler de manière plus fluide, plus adaptative, et de réduire la pression et la frustration souvent associées aux estimations.

Cette approche s’inscrit dans une évolution plus large, où l’on accepte l’incertitude inhérente au développement logiciel, et où l’on cherche à s’adapter en continu, plutôt qu’à planifier l’imprévisible. Les méthodes agiles, les principes Lean, le Kanban, le management visuel, et le développement en flux continu sont autant d’éléments qui convergent vers une vision du travail plus transparente, plus centrée sur la valeur et la collaboration.

L’avenir de « no estimates » dépendra de la capacité des équipes à communiquer clairement cette approche, à convaincre les parties prenantes, et à démontrer que l’on peut piloter un projet efficacement sans recourir aux estimations traditionnelles. Déjà, de plus en plus de professionnels partagent leurs expériences, leurs réussites et leurs défis avec l’approche « no estimates ». Il est probable que cette philosophie continue de gagner en visibilité, surtout dans les environnements de développement logiciel qui valorisent l’agilité, l’empirisme et la livraison continue de valeur.

En fin de compte, « no estimates » n’est pas une révolution qui supprime toute forme de prévisibilité ou de contrôle. C’est plutôt une réorientation du regard, du « combien de temps cela va-t-il prendre ? » vers le « comment livrer de la valeur de façon régulière et fiable ? ». Si cette question trouve des réponses concrètes, si les équipes parviennent à travailler plus sereinement et plus efficacement, alors « no estimates » aura pleinement sa place dans le paysage diversifié des approches de gestion de projet et de développement logiciel.

Lire aussi :

Comment écrire une User Story INVEST ?

Comment définir des critères d'acceptation d'une User Story ?

Example Mapping : Le Guide Ultime pour clarifier vos exigences en Méthodologie Agile

FAQ