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 » justifie que l’on cesse d’exiger un chiffre précis pour quelque chose que personne n’a 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 sur un graphique en fonction du temps, elle ressemble à un cône : large à gauche, là où l’on en sait le moins, 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 aller de travers.

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 la considère 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 évalue la taille relative des tâches plutôt que de s’engager sur des dates. Les « story points » 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 réaliste 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 est bien compris, ce qui permet d’obtenir des estimations plus précises que si l’on ne faisait qu’une seule estimation pour l’ensemble.
• Réévaluez votre estimation lorsque vous avez appris quelque chose. Réévaluer son estimation à mesure que le champ se rétrécit relève de l’honnêteté ; le faire dans le seul but d’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 ajoutant une marge de sécurité, on rehausse l’ensemble du cône 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 sous la forme d’une relation entre le coût et les logiciels ; 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. Identifiez le point le plus risqué, affinez le scénario jusqu’à ce qu’il n’y ait plus de questions, décomposez-le pour 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 le chiffre est gonflé.

Lectures complémentaires

• Estimation relative ou absolue : pourquoi le dimensionnement relatif 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 marge d’incertitude.
• Velocity : transformer une estimation préliminaire et approximative en une prévision assortie d’une fourchette.
• Guide d’estimation agile : l’ensemble complet des méthodes d’estimation.
• Planning Poker gratuit pour les équipes agiles : obtenez l’évaluation relative rapide que le « cône » requiert.