Tous ceux qui ont déjà travaillé dans une équipe qui se dit agile a déjà fait des estimations de ticket / user story (US), en général dans la fameuse unité de mesure qu'est le "Story Point" avec une échelle Fibonacci parce qu'on est des pros. Mais est-ce que ça fait vraiment sens ?

Disclaimer : Le discours que je tiens ici n'est pas une vérité absolue ! Je partage un ensemble de réflexion que j'ai eu avec mon expérience. Si vous avez une vision totalement différente, et cette vision vous convient, vous avez raison, c'est votre avis. Ne prenez pas ce que je peux dire comme une attaque, mais bien comme un constat et peut-être vous faire prendre du recul, rien de plus.

Estimer ? C'est à dire ?

Petite remise à plat du concept avant d'aller plus loin pour que déjà on soit tous d'accord sur ce que c'est "estimer" et pour donner un peu de vision aux gens ne ferait pas d'agilité : l'estimation c'est un process qui vise à associé à une tâche / une US une valeur qui permettra d'évaluer sa "taille" (au sens le coût de travail) afin de pouvoir aider à prendre certaines décisions (typiquement décider de prendre ou non sur un sprint en fonction de ce qu'on pense être en capacité de réaliser). C'est à différencier du chiffrage qui vise à donner un temps en "jour/homme" (temps de travail si on imagine qu'une seule personne va réaliser la tâche).

En effet quand on travaille en Scrum, on va chercher à estimer une vélocité (= capacité de réalisation) pour l'équipe et prendre des engagements raisonnables. L'idée derrière l'estimation, c'est aussi de définir si une US est trop grosse pour être gérée par une personne d'un bloc. Plus une US est grosse plus c'est difficile de la réaliser dans un délai court, ne rien oublier, bien tester tous les cas, etc. Si on borne correctement les attentes d'une US, on peut plus facilement évaluer l'impact et garder en tête le périmètre d'action pendant la réalisation.

On a aussi une règle qui dit que plus une tâche est petite, plus c'est facile de l'estimer, plus elle est grosse plus c'est difficile et donc moins on est précis dans l'estimation.

Une autre règle dit qu'on est censé donner une estimation réaliste en partant du principe que la personne la moins en maîtrise du sujet prend la tâche de sorte que tout le monde monte en compétence, que tout le monde soit en capacité de prendre chaque tâche et qu'on représente bien la capacité à gérer un sujet pour l'équipe. Dans les faits cette règle je ne l'ai jamais vu appliqué…

Estimer quoi ?

La première question à se poser c'est ce qu'on estime : le temps pour réaliser l'US ? la complexité ? le niveau de connaissance du sujet ? le risque ? la confiance en soi ? l'humeur ? la fatigue ? un peu tout ça ?

En fait pour moi ça dépend à qui on parle, et même sans changer de projet, juste en demandant aux différents acteurs d'un projet ou aux personnes qui gravitent autour. Pour les développeurs c'est généralement un mélange complexité / connaissance / risque, un peu propre à chacun, un peu propre à l'équipe, un peu un consensus de conviction, un peu l'avis des personnes qui sont plus "leaders". Pour les POs / PMs / Chef de projet / etc. c'est un moyen de priorisation. Pour les directeurs / pilotes / etc. c'est un moyen de piloter la trajectoire projet, savoir si on avance, avec des mesures chiffrées qu'on voit évoluer au fil du temps.

Est-ce que ça vous semble pertinent de mettre une valeur chiffrée sur une US, avec une échelle qui n'est pas universelle, avec des objectifs différents derrière pour différentes personnes qui vont utiliser ce chiffre ? Moi pas.

Pourquoi estimer ?

Je commençais à en parler plus tôt : pourquoi on fait ça ?

L'idée c'est de prendre un moment pour évaluer la taille des différentes tâches pour réaliser un projet, petite tâche par petite tâche, en supposant que 100% de ce qu'il faut pour réaliser un projet peut être défini comme une tâche. Chaque petite estimation ayant une légère imprécision, on considère qu'en prenant une vue d'ensemble, on aura une estimation plutôt correcte du travail restant à accomplir.

Jusqu'à tomber sur cette US qu'on aura estimé à 3-5, en se disant "on prend un peu de marge", et on y passe un sprint complet, voir un peu plus. Est-ce que c'est grave ? Est-ce qu'on s'est trompé ? Est-ce qu'il faut jeter l'US ? Est-ce qu'il faut blâmer le développeur ? Pour moi ça dépend.

Déjà il faut se rappeler qu'on a fait une estimation collective de la complexité d'un ticket, qui ne se base pas sur du temps, donc "une US à 5 qui prend le sprint complet" ça ne veut rien dire. Si chaque US prise par un développeur prend des proportions énormes, il y a peut-être un problème à soulever, et il faut en parler avec la personne pour comprendre le problème (ce n'est pas forcément ce développeur qui ne travaille pas, mais peut-être que le projet est trop complexe, qu'il y a un déphasage trop grand entre ce développeur et le reste de l'équipe, etc.). Si c'est une exception le concernant, ça peut être signe d'un sujet compliqué sous estimé. Mais est-ce que c'est grave ? C'est surtout une question de priorité pour moi : est-ce que la tâche fait sens ? est-ce qu'on veut vraiment la réaliser ? coûte que coûte ?

Je peux aussi citer la dérive systématiquement des "macros estimations", qui sont des estimations des gros sujets, en prenant une vue large, sans aller voir la technique derrière, les détails de ce qu'on veut faire et donner une estimation de sa taille. Ça ne peut que dériver à mon avis, car il y a trop de par de pif pour que ça vaille quelque chose.

Le Story Point est propre à l'équipe mais en même temps pas tout à fait

On cherche généralement à faire des "estimations précises", sur l'échelle de l'équipe, sans vraiment s'être concerté sur ce qui caractérise cette échelle. Donc on y va de son expérience personnelle avant tout, on échange quand on ne donne pas un chiffre commun, et on s'aligne généralement sur la majorité.

Déjà fonctionner en s'alignant sur la majorité n'est pas la bonne pratique en agilité, on est censé estimer en partant du principe que la personne la moins expérimentée va réaliser la tâche de sorte que n'importe qui dans l'équipe puisse prendre la tâche et avoir le temps de la réaliser sans pression malsaine, donc on devrait s'aligner sur la personne qui estimer au plus haut systématiquement.

Et donc si on est d'accord avec l'estimation en équipe (la valeur abstraite, pas forcément ce qu'elle représente), on fait quoi ensuite ? On constitue notre sprint en alignant des tickets en se basant sur la priorité, on voit que ça ne rentre pas dans le temps du sprint car on est des bons élèves et qu'on calcule la sacro-sainte vélocité de l'équipe (voir la vélocité par développeur ou encore la vélocité par développeur par jour !) et donc on sait que l'équipe est en capacité de réaliser 34 points (n'en faites pas une référence, j'ai pris un nombre au hasard) par sprint en se basant sur l'observation des N derniers sprints. Et ensuite évidemment : on s'engage sur la réalisation du sprint, et on devra à la fin du sprint expliquer pourquoi on a pas fini le sprint.

Ça vous semble logique tout ça ? Parler de vélocité (notion temporel) pour parler de point réalisé alors que le point de complexité s'appelle "point de complexité" justement parce que ça n'a rien de temporel ? On est d'accord que la complexité prend en compte le risque : donc faire une tâche qui prend 15min mais qui risque de casser la prod, devrait être estimé très haut, et un truc qui prend 3 semaines mais 100% mécanique devrait être estimé super bas ?

Le développement logiciel ce n'est pas une industrie, c'est de l'artisanat : on passe notre temps à faire et refaire des choses pour s'adapter à un besoin précis, on ne travaille pas à la chaîne, on a jamais deux tâches identiques, similaires oui mais pas identiques. Comment on peut partir du principe que deux tâches similaires prennent le même temps ? De la même façon, ce n'est pas un travail mécanique, c'est un travail qui demande beaucoup de temps de réflexion, qui de facto va être influencé par la fatigue, l'ennui, l'expérience, l'interruption, etc. Beaucoup de facteur qui ne sont jamais pris en compte dans l'estimation.

Le coût de l'estimation

On se rappelle qu'on sort un chiffre un peu de nulle part à partir d'un ressenti sur l'US. Est-ce qu'on irait pas plus vite à lancer un dé finalement ? On sait qu'on vise essentiellement des tickets estimés à 1, 2 ou 3, donc on fait un dé à 8 faces avec deux faces à 1, deux faces à 2, deux faces à 3, une à 5 et une 8 et ça devrait être assez proche de ce qu'on obtient à la sorte d'une séance d'estimation. Non ? Peut-être une face à 1 et 3 faces à 2 ? Tentez l'expérience et vous verrez. Pas sur un ticket en particulier, mais sur un ensemble de ticket, peut-être sur l'équivalent de 3-4 sprints.

Où je veux en venir ? Ça coûte cher d'estimer. Ça coûterait cher de chiffré aussi qu'on soit clair, surement encore plus !

Combien ? Imaginons un sprint classique (en me basant sur mon expérience) : sur des sprints de trois semaines, une session d'estimation d'1h par semaine (et je suis gentil, j'ai souvent vu plutôt 1h30-2h) et un sprint planning d'1h par sprint, avec en moyenne des équipes de cinq développeurs (je ne compte pas les autres métiers ici, c'est trop variable bien qu'on devrait aussi les compter), ça nous fait 4h par développeurs de perdus par sprint, donc 2,5 jours de productions de perdus (soit un peu plus de 3% du sprint), et ça c'est sans compter la perte de temps due à l'interruption que provoquent les 4 réunions cités.

Vous voulez des estimations plus "précise" en passant par une phase de conception avant estimation ? (Pour moi c'est inutile, ça devrait juste être pris en compte dans la complexité du ticket, mais je l'ai aussi beaucoup vu donc parlons-en), ça va donner quoi, en gros une demi-journée par développeur par sprint en plus ? Donc encore 2,5j de perdus qui ne rentre pas dans la réalisation de l'équipe, alors que la conception fait partie intégrante du travail réalisé par les développeurs.

Time out ?

Comme on ramène tout à du temps (même si ça ne fait pas sens), est-ce qu'on se dit qu'on pose un temps max pour la réalisation d'un ticket ? Je n'ai jamais vu ça appliqué mais en vrai on pourrait vu tous les postulats qu'on pose pour transformer le nombre abstrait magique qu'ait le Story Point en temps.

Au bout du temps on fait quoi ? On abandonne la tâche ? On la recommence avec un autre développeur ? On change / découpe le besoin ? On continue ?

Je n'ai pas de réponse absolue, mais je pense que la question se pose. Mais je pense aussi que l'abandon ne sera que très rarement la bonne option comme on a besoin du résultat de la tâche et qu'on l'a prise parce que c'était le besoin prioritaire.

Alternative : no estimate ? Kanban ? ScrumBan ?

Je critique, mais j'ai aussi des solutions (avec leurs défauts aussi, qu'on soit clair) à proposer. Pas forcément bonne pour tout le monde mais au moins pour amener de la réflexion.

No estimate. En français "Ne pas estimer". Ça peut faire peur mais ce n'est pas aussi YOLO que ce qu'on pourrait penser : il faut s'imposer de découper au maximum toutes les tâches pour qu'elle soit le plus petit possible. En fait l'idée c'est d'imaginer qu'on ne fait que des tickets à 1 point et jamais plus. Ce qui implique qu'on n'a plus besoin d'estimation, au pire une relecture des tickets par un développeur avant que le ticket soit prêt à être pris par les développeurs pour valider que c'est bien "assez petit" mais pas plus. Dans un sens, ça revient à reporter plus sur le PO (Product Owner) la tâche d'estimer la taille des tâches.

Kanban ou la priorisation en continu. Avec Kanban, on part du principe que ce qui compte c'est la priorité des tickets pas l'estimation. Chaque nouveau ticket peut arriver n'importe où dans la pile des tickets en attente, et un développeur qui fini sa tâche va prendre le ticket de plus haute priorité. L'estimation est optionnelle avec Kanban, ça se marie très bien au no estimate, mais ce n'est pas une obligation. Kanban c'est aussi peu de rituel autre que le daily.

ScrumBan c'est Kanban avec quelques rituels Scrum pour prendre du recul ponctuellement sur ce qu'on fait.

Note : Il existe beaucoup d'autres approches. Ne vous arrêtez pas à ce que je vous dis là.

Conclusion

Du coup on fait quoi ? On rejette en bloc les estimations et on refuse ces rituels ?

Malgré tout, même si je suis convaincu que c'est une perte de temps, je participe aux rituels d'estimations parce que ça fait partie de ce qu'on attend de moi, par contre je refuse le terme "chiffrage", un chiffrage implique du temps pur, ce qu'on fait est un pur pif donc ce n'est pas la même chose et ce serait se voiler la face que de parler de "chiffrage" quand on donne un nombre quasi au hasard.

Qu'on soit clair aussi : je ne vous dis pas de rejeter en bloc au bureau les estimations "par principe", juste vous faire prendre conscience que c'est plus compliqué que ce qu'on vous propose au quotidien, qu'il faut avoir un regard critique sur ce qui semble acquis, et se rappeler que l'agilité c'est une pratique récente, qui donc a besoin de grandir et d'évoluer, pour peu qu'on sache pourquoi on veut le faire. L'agilité c'est énormément de code, de vocabulaire, de cadre qu'on s'impose, beaucoup aussi d'éléments qui sont là pour faire ce qu'on appelle du "passage à l'échelle", ce n'est pas toujours inutile, mais il faut se poser les bonnes questions avant d'utiliser ces outils.

Crédit photo : Générée via Mistral AI avec le prompt suivant

Crée une illustration dans un style minimaliste et moderne, représentant une ampoule éteinte au milieu d'un groupe d'ampoules allumées. L'ampoule éteinte doit être de couleur gris foncé ou noire, symbolisant une idée impopulaire ou différente, tandis que les ampoules allumées doivent émettre une lumière chaude et accueillante dans des tons jaunes ou oranges. Utilise un arrière-plan dans des nuances de gris clair ou blanc cassé pour faire ressortir le contraste entre les ampoules. Ajoute des ombres subtiles pour donner de la profondeur à l'image, et assure-toi que les ampoules sont disposées de manière asymétrique pour accentuer l'unicité de l'ampoule éteinte.