Pourquoi estimer nos projets en points ?

Les démarches agiles ont apporté avec elles leurs lots de changement et de pratiques. Parmi elles, la fameuse « estimation relative », appelées aussi « estimation en point ». Cette pratique n’est pas toujours facilement acceptée par l’ensemble de l’organisation car elle utilise des concepts abstraits, là où les « jours hommes » sont très concrets et parlent à tout le monde.

Et pourtant, l’estimation relative est une arme redoutable pour donner de la prédictibilité. C’est également un excellent KPI pour les équipes Lean que j’accompagne, leur permettant ainsi de visualiser simplement leur objectif et de s’organiser efficacement.

Etant souvent confronté à de l’incompréhension face à cette méthode, j’en reprends les principes dans ce billet en répondant aux questions suivantes :

  • Pourquoi a-t-on besoin d’estimer ?
  • Pourquoi utiliser les « estimations relatives » ?
  • Pourquoi est-ce plus efficace ? 

Pourquoi a-t-on besoin d’estimer ?

Les estimations sont régulièrement utilisées dans deux contextes bien différents dans les entreprises :

  • Définir un budget et en suivre l’avancement (suivi du coût d’un projet)
  • Estimer la date de livraison (prédictibilité à moyen et à long terme)

Les estimations relatives (donc en point) dont je vais parler dans cet article ne sont pas conçues pour réaliser un suivi budgétaire. Si vous souhaitez suivre cet indicateur, l’utilisation des jours imputés sur les projets reste aujourd’hui l’outil le plus simple étant donné sa conversion implicite en euros.

Les estimations relatives ont donc pour objectif de donner une vision de ce qui peut être fait dans une unité de temps (plus ou moins longue). Elles répondent donc aux questions suivantes :

  • Qu’est-ce qui peut être livré à une date donnée ?
  • Quand pourrons-nous livrer ces fonctionnalités / la première version ?
  • Sommes-nous dans le timing / en retard / en avance ?
  • Quel est l’impact d’un changement de périmètre sur la date de livraison ?
  • etc.

Pourquoi utiliser les « estimations relatives » ?

Historiquement les jours étaient utilisés, entre autres, pour estimer le coût d’un projet, mesurer l’avancement, et en déduire les dates de sorties. Les problèmes rencontrés avec cette approche sont les suivants :

  • L’imprécision : les estimations sont souvent faites en tout début de projet, au moment où l’incertitude est la plus grande. Ce qui engendre de l’approximation, et souvent de la surestimation de la part de la personne en charge de cette lourde responsabilité qui, en général, sera souvent gravé dans le marbre jusqu’à la fin du projet.
  • Le temps : sur un projet important et long, l’équipe va progresser. Elle va prendre en main les nouveaux outils, les nouvelles versions d’un éventuel Framework de développement, d’une nouvelle techno etc. L’aspect relatif de cette approche permet de visualiser cela par l’augmentation de la vélocité. Ce que ne permet pas l’estimation en jour.
  • L’équipe : lors des estimations, il n’est pas rare que l’équipe ne soit même pas connue. Et du coup, on ajoute à l’approximation fonctionnelle une approximation des compétences. Le développement avancera-t-il de la même façon avec des experts qu’avec des débutants ? On voit trop souvent des chiffrages réalisés par des experts ne participant même pas aux développements. Ces mêmes développements qui seront finalement faits par des débutants. Et on se posera alors la question des raisons du dépassement lors du bilan de version.
  • Le coût : un tel chiffrage nécessite souvent une étude approfondie et un ensemble de réunions interminables. Ce qui représente un coût non négligeable, surtout quand on sait que l’imprécision est à son maximum à ce moment-là du projet. On investit alors beaucoup de temps dans l’espoir d’améliorer la précision :

Pourquoi est-ce plus efficace ?

Avec les estimations relatives, nous allons chercher à être le plus juste possible, mais on ne va pas chercher à être précis pour prendre en compte l’approximation et l’imprécision que nous avons (surtout en début de projet). Nous allons donc chercher à avoir un juste équilibre entre le temps investi et la précision.

2018-09-13_11h48_22

L’objectif est donc d’être globalement bon plutôt que précisément erroné.

Comment ça marche ?

La subtilité de la méthode réside dans les deux clés suivantes :

  • Estimer l’effort qu’il faudra fournir pour réaliser une tâche par rapport à une autre plutôt que le temps qu’il faudra pour la faire.
  • Constater la capacité de l’équipe pour en déduire l’avenir, plutôt que d’essayer de prédire une capacité comme dans une boule de cristal.

Estimer l’effort ?

Concrètement, l’effort est la quantité de travail à fournir pour réaliser une tâche (ou une User Story). L’idée de l’estimation relative est d’estimer cet effort de manière relative en comparant un ensemble de tâches les unes par rapport aux autres (une Story Map par exemple). Une tâche qui aura un effort de « 2 » demandera donc approximativement deux fois plus d’efforts qu’une tâche estimée à « 1 » et grosso modo 4 fois moins qu’une tâche à « 8 ».

Du coup, cet effort relatif signifie la même chose pour un expert que pour un débutant. Une tâche A nécessitant deux fois plus de travail qu’une tâche B pour un débutant nécessitera aussi deux fois plus de travail pour un expert. Et c’est là une différence majeure qu’il y a avec une estimation en jour, où pour le coup, le débutant estimera à 2 jours ce qu’un expert estimera à 1 heure.

Par exemple, si vous demandez à Usain Bolt le temps qu’il lui faut pour faire 100m, il répondra sûrement moins que si vous demandez à quelqu’un de votre équipe. Mais si vous leur demandez à tous les deux d’évaluer la distance jusqu’au poteau là-bas, ils vous répondront tous les deux 100m (si vous montrez un poteau à 100m, ba oui y’a des prérequis :-p). C’est exactement cela que nous allons faire avec notre effort. Nous allons chercher la distance qui nous sépare du résultat final, c’est à dire la quantité de travail qu’il faudra réaliser pour terminer une tâche. Ainsi, il sera alors possible d’estimer l’ensemble des fonctionnalités d’une Story Map relativement les unes par rapport aux autres avec des valeurs parlantes pour les experts et les débutants.

Et là, vous allez me dire : Pourquoi ça marche mieux ? En quoi c’est plus efficace ?

Et bien les estimations relatives sont plus faciles et rapides à réaliser car elles exploitent la capacité de notre cerveau à comparer. Et oui, notre cerveau est capable de beaucoup de choses, mais il a de réelles difficultés à évaluer des mesures exactes. Ce n’est peut-être pas facile à lire, mais notre cerveau n’est pas câblé pour cela. Ce n’est donc pas la peine d’insister !! 🙂

Par exemple : si je vous demande de me donner précisément la largeur de votre bureau, allez-vous pouvoir me la donner précisément ? Pourtant ce n’est pas censé être compliqué. Vous passez 8 heures par jour dessus depuis des années, vous devez bien le connaitre depuis le temps. Et pourtant… Le cerveau humain est très mauvais en estimation absolue mais il sait cependant très rapidement comparer. Si je mets un bureau différent à côté du vôtre, vous saurez assez facilement dire s’il est plus grand ou plus petit.

Pas vraiment convaincu ? Questions simples :

  • Combien fait-il dans votre bureau ? Fait-il plus chaud dans votre bureau ou dehors ?
  • Combien pèse une girafe ? Quel animal pèse le plus lourd entre la girafe et le lion ?
  • Quelle est la superficie de la France ? Quel pays est le plus grand entre la France et le Portugal ?
  • Combien faut-il de jours pour réaliser cette tâche ? Est-ce que cette tâche demande plus d’efforts que cette autre tâche ?

Dites-vous que si notre cerveau arrivait à estimer des mesures exactes, estimer le poids d’un cochon dans une fête foraine n’aurait jamais été un défi. 🙂

Bref, vous avez compris.

Et pour la prédictibilité ?

Pour exploiter cette estimation et s’en servir comme moyen de prédictibilité, nous allons tout simplement lancer le projet et mesurer ce que l’équipe produit. C’est ce que nous allons appeler la vélocité. Le principe est simple et à la portée d’un enfant de CM2. Imaginez une Story Map estimée avec au total 200 points. Eh bien, si l’équipe commence à travailler et qu’elle produit 20 points en 1 mois, et bien on peut annoncer que l’ensemble de la Story Map sera réalisée approximativement dans 10 mois (200 / 20). Et cette vision un peu grossière au début, va s’affiner au fur et à mesure de l’avancement. Des éléments de la Story Map vont se préciser et vont être réestimés, la capacité de production (la fameuse vélocité) va s’ajuster en fonction des difficultés rencontrées par l’équipe, etc. Et comme toute l’estimation est relative, elle reste juste, et c’est bien là la subtilité et la puissance de cette méthode. Même si chacun des éléments est précis à +/- 40% (globalement bon plutôt que précisément erroné), en moyenne cela reste juste.

Prérequis

Comme toute méthode ou démarche, il y a des prérequis à respecter pour que ce modèle fonctionne et pour en tirer tous ces bienfaits.

  • On a plusieurs choses à estimer.

Bien sûr, pour pouvoir estimer une tâche de manière relative, il faut pouvoir le faire relativement à d’autres. Personnellement, j’utilise la Story Map. Cela me permet d’avoir un découpage en objectifs, activités et fonctionnalités, ce qui est un bon niveau de découpage et permet d’avoir un bon nombre d’éléments à estimer. Cela permet aussi de donner des visions sur les releases intermédiaires. Mais ce n’est pas le sujet.

  • On a une équipe pour réaliser l’estimation

Eh oui, les estimations se font en équipe. C’est un véritable changement de paradigme avec l’oracle qui donnait des chiffres en lisant dans sa boule de cristal. Là, on a une équipe constituée, et on réalise l’estimation ensemble. Cela permet également d’aligner l’équipe sur les besoins métier, mais là encore, ce n’est pas le sujet.

  • On décide de réviser nos estimations de façon continue tout au long de la réalisation d’un produit

Eh oui, nous constatons la production de l’équipe, nous apprenons et nous découvrons des éléments. Il faut donc s’engager à réviser régulièrement l’ensemble de la Story Map afin d’ajuster et d’affiner la date d’atterrissage. Mais cela peut se faire très rapidement.

Et après ?

Vous voilà prêt à vous lancer. Mais pour vous y aider, je vais vous donner quelques mots clés que vous pouvez googleliser. Je ne rentre pas dans le détail car ce n’est pas le but de cet article. A vrai dire, chacun de ces termes mériterait un article (Challenge ?). En attendant, je vous laisse chercher :

  • Planning Poker : une manière ludique et efficace pour estimer rapidement et relativement des éléments en s’inspirant de la suite de Fibonacci
  • CURSE : Acronyme peu souvent utilisé, mais que j’aime bien prendre en exemple lorsque les équipes ont vraiment du mal à définir ce qu’est un « effort » ou que cela ne leur convient pas. Il va un peu plus loin dans les éléments à prendre en compte.
  • KPI : Lorsqu’on a une Story Map estimée, on peut définir un Burnup permettant visuellement de montrer à l’équipe l’objectif, où l’on est, et où l’on va. Il est alors possible de challenger l’équipe pour qu’elle puisse s’organiser à atteindre cet objectif de réussite.
  • Extreme quotation : Pratique permettant d’estimer un grand nombre de fonctionnalités en un minimum de temps. Estimer l’ensemble d’une Road Map en 1 heure, ça vous tente ? 🙂

Et pour ouvrir la discussion, je ne peux terminer un article comme celui-là sans vous envoyer à mon billet sur l’énorme conférence de Frédéric Leguédois sur le sujet « Arrêtons les estimations« .

Et vous, comment faites-vous pour estimer la date de livraison de votre prochaine version ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s