Honnête sur les limites.
Une estimation est une prévision, pas un contrat. Dès qu'une équipe traite une estimation comme un engagement — « tu as dit que c'était un 5, donc ça devrait être terminé mercredi » — l'estimation cesse d'être un outil de planification et devient un mécanisme de punition. Les ingénieurs réagissent en gonflant les estimations pour se protéger, ce qui rend les estimations inutiles pour la planification, ce qui pousse les parties prenantes à exiger des chiffres « précis », ce qui pousse les ingénieurs à gonfler davantage. Le cycle est prévisible et courant.
La distinction compte surtout à la frontière entre l'ingénierie et le reste de l'organisation. À l'intérieur de l'équipe, les estimations déterminent la capacité du sprint et aident à identifier les semaines surchargées. C'est bien — l'équipe contrôle le plan et peut l'ajuster en cours de sprint. Le problème commence quand les estimations quittent l'équipe sous forme de promesses de livraison aux ventes, aux dirigeants ou aux clients. Un « nous pensons que c'est environ 13 points de travail » devient « l'ingénierie s'est engagée à trois semaines » dans une présentation que l'équipe ne voit jamais.
Protéger les estimations pour qu'elles ne deviennent pas des engagements est une discipline d'équipe et une responsabilité de leadership. L'équipe devrait communiquer les estimations sous forme de fourchettes (« 2 à 4 semaines selon ce qu'on trouve dans le code hérité »), pas en points. Et les leaders devraient résister à la pression de retirer l'incertitude des estimations pour rendre une feuille de route plus propre. L'incertitude est la partie honnête.
L'estimation a un coût : le temps que l'équipe passe à estimer au lieu de construire. Pour la plupart des équipes, ce coût est raisonnable — 30 minutes d'estimation évitent des heures de surprises en cours de sprint. Mais le coût peut augmenter jusqu'à ce que la cérémonie consomme plus de valeur qu'elle n'en produit.
Signes d'alerte que l'estimation est devenue son propre gaspillage :
Le principe est le même que celui qui s'applique à chaque élément de processus : si ça ne crée pas de levier, ça crée de la surcharge. L'estimation devrait être peu coûteuse, rapide et utile. Quand elle devient coûteuse, lente ou ignorée, réduisez-la.
Le mouvement #NoEstimates soutient que l'estimation est souvent inutile et que les équipes peuvent prévoir la livraison en utilisant le débit historique — le nombre de tickets complétés par semaine — au lieu d'assigner des tailles aux tickets individuels. L'argument a du mérite, et le rejeter comme paresseux est aussi faux que de le traiter comme un évangile.
La prévision basée sur le débit fonctionne comme ceci : si une équipe complète systématiquement 10 à 14 tickets par semaine, et qu'un projet a 45 tickets, la prévision est de 3 à 5 semaines. Aucune séance d'estimation nécessaire. Le calcul repose sur deux conditions : les tickets doivent être découpés en tailles à peu près similaires, et l'équipe doit avoir suffisamment de données historiques pour établir une fourchette de débit fiable. Quand ces conditions sont remplies, la prévision est souvent plus précise qu'une estimation ascendante de chaque ticket individuel.
Le piège est la discipline. Les équipes qui abandonnent l'estimation mais abandonnent aussi la discipline de découpage se retrouvent sans aucune capacité de prévision — elles ne peuvent pas estimer parce qu'elles ont abandonné la pratique, et elles ne peuvent pas utiliser le débit parce que leurs tickets vont de corrections d'une heure à des épopées de trois semaines. #NoEstimates sans découpage cohérent, c'est juste #NoInformation.
Pour la plupart des équipes, le chemin pragmatique est quelque part au milieu : estimez légèrement (S/M/L), suivez le débit comme signal secondaire, et abandonnez complètement l'estimation seulement quand les données montrent que le débit seul est suffisant. Le pire choix est d'estimer lourdement et d'ignorer le débit — c'est un maximum de cérémonie pour un minimum d'information.
L'option #NoEstimates
Certaines équipes matures abandonnent complètement l'estimation et utilisent le débit (nombre d'éléments complétés par semaine) pour la prévision. Ça fonctionne — mais seulement quand l'équipe a la discipline de découper le travail uniformément.