Le « cône d'incertitude » dans l'estimation agile

Votre première estimation est toujours la moins précise — et c’est une caractéristique inhérente au travail, et non un défaut de l’équipe. Le « cône d’incertitude » explique pourquoi il ne faut pas exiger un chiffre précis pour un projet qui n’a même pas encore commencé.

Le « cône » est un constat simple aux conséquences marquantes : au début d’un projet, l’écart entre votre estimation et la réalité est énorme, et il se réduit à mesure que vous acquérez des connaissances. C’est Barry Boehm qui a repéré cette courbe dans les données relatives aux coûts logiciels ; Steve McConnell lui a donné son nom. Représentée graphiquement au fil du temps, elle ressemble à un cône : large à gauche, là où vous en savez le moins, et se rétrécissant jusqu’à un point à droite, là où le travail est presque terminé et où il n’y a plus rien qui puisse mal tourner.

Pourquoi est-ce important pour l’estimation ?

La plupart des difficultés liées à l’estimation proviennent du fait d’exiger une estimation ponctuelle au niveau de la partie la plus large du cône. Quelqu’un demande « Combien de temps prendra la mise en place du nouveau système de facturation ? » avant même qu’une seule ligne de code n’ait été écrite, obtient la réponse « environ trois mois » et considère cela comme un engagement. Le cône indique que ce délai se situe en réalité entre six semaines et neuf mois — et prétendre le contraire ne fait que repousser la déception à plus tard.

C’est précisément pour cette raison que la méthode agile estime la taille relative plutôt que de s’engager sur des dates. Les points d’histoire et le planning poker ne vont pas à l’encontre du « cône » : ils l’acceptent. Une évaluation relative rapide (« c’est plus important que ce que nous avons livré lors du dernier sprint ») constitue le niveau de précision honnête dont on dispose au début, et la vélocité transforme cela en une prévision avec une fourchette plutôt qu’en une fausse promesse.

Comment rétrécir le cône

Le champ se rétrécit lorsque vous éliminez les inconnues — et non lorsque vous ajoutez une marge de manœuvre. Par ordre d’importance :

• Le « spike » est l’inconnue la plus risquée. Un spike limité dans le temps permet d’obtenir des informations, ce qui est la seule chose qui permet réellement de réduire la fourchette.
• Affinez jusqu’à ce qu’il n’y ait plus de questions. Une histoire sur laquelle l’équipe ne cesse de poser des questions se trouve à l’extrémité la plus large du cône ; des critères d’acceptation précis la font glisser vers la droite.
• Divisez-le. Les tâches plus petites se situent plus bas dans le cône : chaque élément étant bien compris, chaque estimation est plus précise qu’une estimation globale.
• Réévaluez votre estimation lorsque vous avez appris quelque chose. Réévaluer à mesure que le champ se rétrécit relève de l’honnêteté ; le faire pour atteindre un objectif, en revanche, n’en relève pas.

Le cône n’est pas une excuse pour se la couler douce

La leçon erronée est la suivante : « Tout est incertain, il faut donc doubler chaque estimation. » En gonflant les chiffres, on déplace l’ensemble du cône vers le haut sans le rétrécir : vous continuez à faire des suppositions, mais de manière pessimiste. La bonne réponse face à un cône large consiste soit à lever l’incertitude (préciser, affiner, diviser), soit à communiquer honnêtement la fourchette et à s’engager à réévaluer les estimations.

Foire aux questions

Qu’est-ce que le « cône d’incertitude » ?

Le « cône d’incertitude » décrit comment la fourchette d’une estimation est la plus large au début d’un projet et se rétrécit à mesure que celui-ci avance et que les inconnues sont levées. Au début, une estimation peut présenter un écart considérable dans un sens ou dans l’autre ; lorsque le projet est bien compris, cette fourchette se réduit pour se rapprocher du résultat réel.

Qui a inventé le « cône d’incertitude » ?

Ce concept a été observé pour la première fois par Barry Boehm au début des années 1980 comme une relation entre le coût et le logiciel ; Steve McConnell l’a ensuite baptisé « cône d’incertitude » et l’a popularisé dans les domaines de l’agile et de l’estimation logicielle.

Comment le « cône d’incertitude » s’applique-t-il à l’estimation agile ?

C’est la raison pour laquelle la méthode agile évalue la taille relative plutôt que de s’engager dès le départ sur des dates. Les « story points » et le « planning poker » partent du principe que les premières estimations sont approximatives, privilégient une évaluation relative rapide au détriment d’une fausse précision, et procèdent à de nouvelles estimations à mesure que le champ d’action se précise grâce au raffinement, aux « spikes » et au travail livré.

Comment réduire le « cône d’incertitude » ?

Il ne s’agit pas de gonfler les chiffres, mais de résoudre les inconnues qui élargissent le champ. Concentrez-vous sur la partie la plus risquée, peaufinez le scénario jusqu’à ce qu’il n’y ait plus de questions, décomposez-le de manière à ce que chaque élément soit compréhensible, puis réévaluez-le une fois que vous en aurez tiré des enseignements. Le cône se rétrécit lorsque l’incertitude est levée, et non lorsque les chiffres sont gonflés.

Lectures complémentaires

• Estimation relative vs estimation absolue — pourquoi l’estimation relative résiste à l’épreuve du cône.
• Décomposition des user stories — les « spikes » et les « splits », ces étapes qui permettent d’obtenir les informations nécessaires pour réduire la fourchette.
• Velocity — transformer une estimation préliminaire et approximative en une prévision comportant une fourchette.
• Guide d’estimation agile — l’ensemble complet des ressources sur l’estimation.
• Planning Poker gratuit pour les équipes agiles — découvrez rapidement les notions de base que le « cône » requiert.