#NoEstimates, comment prioriser sans estimations ?

Temps de lecture estimé : 4 minutes

Il y a quelques mois, je participais à la formation de Frédéric Leguédois sur le #NoEstimates.

Ce mouvement dont vous avez probablement déjà entendu parler consiste à bannir totalement les estimations des différents processus agile.

Bannir totalement les estimations ? Est-ce vraiment possible ? Est-ce même souhaitable ?

C’est évidemment plus nuancer que simplement “bannir les estimations” ;)

Mais revoyons tout d’abord ce qu’on entend par “estimation” finalement.

Qu’est-ce qu’une estimation ?

Dans le contexte d’un projet informatique, une estimation est le fait d’annoncer un prix (ou un délai) pour un périmètre fonctionnel donnés.

Ces estimations paraissent donc être inévitables pour :

✅ prioriser le travail à faire

✅ partager le besoin fonctionnel au sein de l’équipe

✅ donner de la visibilité

✅ rassurer la hiérarchie

✅ prendre des décisions sur la direction à donner au projet

✅. motiver les équipes devant des objectifs challengeant

✅. partager sur la conception technique

✅. définir un budget

✅. vendre un projet

✅. contractualiser

✅. et évidemment, pour planifier.

Les estimations semblent donc former la pierre angulaire du développement logiciel ! Autrement dit, pas d’estimations et tout se casse la figure.

Sauf qu’évidemment, les estimations ont aussi leur lot d’inconvénient, et non des moindres.

Les inconvénients des estimations

Le premier problème concerne l’essence même de notre activité : la non-prédictibilité.

Or qu’est-ce qu’une estimation sinon une prédiction ?

Lorsqu’une estimation est donnée, elle est souvent considérée comme un engagement. Ce qui était une prédiction, intrinsèquement hasardeuse, se transforme en “deadline” ou en moyen de micro-manager, voire de blâmer une équipe.

Pressée par le temps, l’équipe subit de plein fouet les inconvénients de ces estimations :

❌. la non-qualité, car on préfère le “quick & dirty” pour tenir les délais

❌. des coûts qui explosent

❌. un effondrement total de la réactivité de l’équipe

❌. une incapacité à s’adapter au contexte

❌. une dette technique exponentielle

❌. une démotivation générale

L’objectif du #NoEstimates est ainsi de répondre aux besoins auxquels sont censés répondre les estimations, en repensant toutes les activités qui y sont liées.

Prioriser sans estimer

Vous êtes en session de planning poker, vous devez décider combien de points “vaut” la story en cours de priorisation.

Certains de vos collègues annoncent un chiffre exorbitant, alors que vous pensiez vous que ça allait être beaucoup plus petit. Pour autant, en discutant, vous vous rendez compte que vous avez la même vision de l’ampleur de la tâche à réaliser, vous n’avez juste pas la même échelle en tête.

Cette “échelle” commune est censée se forger au fur et à mesure de l’état d’avancement d’un projet. Mais elle est fondamentalement biaisée : l’humain est très mauvais pour donner une note subjective individuellement. Il est par contre bien plus doué pour comparer deux à deux.

Comment appliquer ce raisonnement dichotomique ?

👉 En supprimant toute notion de durée, de complexité, et de vélocité.

La priorisation en #NoEstimates

1️⃣ L’émergence des idées

Dans un premier temps, il faut faire émerger toutes les idées.

C’est ici le rôle d’atelier de brainstorming, de “knowledge crunching”, où vont être discutés ensemble tous les besoins fonctionnels que l’on a en tête.

Des ateliers comme le Domain-Storytelling, le Story-Mapping, voire même l’Event-Storming sont tout indiqués ici.

2️⃣ La priorisation très grosse maille

Cette seconde étape consiste à se concentrer sur 2 ou 3 fonctionnalités que le client souhaite voir arriver en production en premier.

Si l’on écoute le client, toutes les fonctionnalités sont importantes et doivent arriver en production en même temps.

Le fait de retirer toute notion de complexité, de vélocité, de délai (et donc de coût) permet de se focaliser réellement sur les 2 ou 3 fonctionnalités les plus impactantes pour le client puisque cela le forcera à considérer ces fonctionnalités uniquement d’un point de vue de la valeur ajoutée pour l’utilisateur final.

3️⃣ Le découpage fonctionnelle

Cette troisième étape est la plus importante, et aussi la plus complexe. Il s’agit ici de découper fonctionnellement jusqu’au plus petit bout de fonctionnalité utilisable par un utilisateur.

Vous l’aurez sûrement devinés, l’idée est de se retrouver avec uniquement des “stories” qui ont pratiquement la même granularité. Si on devait les comparer avec des stories avec des points de vélocité, elles seraient toutes dans le même ordre de grandeur !

C’est le secret du #NoEstimates : quand toutes les tâches ont la même “vélocité”, alors cette notion de “vélocité” n’a plus de raison d’être, et le seul marqueur de l’évolution d’un projet, c’est le nombre de “tâches” ou “stories” mises en production (bye bye Scrum et son faux agile 👋 (- edit suite au commentaire de Xav ci-dessous - bye bye le faux Scrum qu'on voit partout dans les boîtes se considérant Agiles 👋)

Le découpage fonctionnelle est complexe, c’est un exercice difficile, mais primordial pour être le plus réactif au changement possible et livrer rapidement de la valeur aux utilisateurs.

Lors de ce découpage, il se peut que vous vous retrouviez avec encore de gros éléments. Auquel cas, retournez à l’étape 2 avec ces éléments :)

Les autres challenges du #NoEstimates

La priorisation des tâches est un des éléments auquel on pense en premier quand il s’agit d’appliquer #NoEstimates.

Puisque les estimations servent principalement à prioriser, il est logique de se poser cette question !

Mais si l’on se réfère aux autres actions que permettent de piloter les estimations, on se rend compte qu’il reste à #NoEstimates quelques challenges à relever.

Parmi lesquels :

• Donner de la visibilité et rassurer la hiérarchie sur l’état d’avancement du projet

• Réaliser un budget

C’est ce que nous verrons dans le prochain post !

En attendant, Happy Coding :)

Pierre.