À quoi sert l'estimation

L'estimation remplit trois rôles, et les équipes qui les confondent finissent frustrées par les trois.

Rôle 1 : Compréhension partagée. Quand une équipe estime un ticket ensemble, le chiffre est un effet secondaire. Le véritable résultat est la conversation. Un développeur dit « c'est un petit changement — remplacer le point de terminaison et mettre à jour les tests ». Un autre dit « attends, ce point de terminaison est derrière un feature flag dont trois autres services dépendent ». L'écart entre leurs estimations est l'écart entre leurs modèles mentaux du travail. Faire ressortir cet écart avant le début du travail vaut plus que le chiffre ne le fera jamais.

Rôle 2 : Planification de la capacité. Une équipe de 10 développeurs avec un sprint de deux semaines a une quantité finie de travail qu'elle peut absorber. L'estimation — même approximative — vous indique si vous chargez 80 % de la capacité ou 140 %. Sans elle, la planification de sprint est une supposition, et « nous nous sommes engagés à trop » devient un thème récurrent de rétro.

Rôle 3 : Priorisation. Une fonctionnalité qui apporte une valeur modérée et coûte un petit effort est une conversation différente d'une fonctionnalité qui apporte la même valeur et coûte un gros effort. L'estimation donne au produit et à l'ingénierie un langage commun pour faire des compromis. Sans elle, la priorisation revient par défaut à celui qui argumente le plus fort.

Certains travaux ne peuvent vraiment pas être estimés, et prétendre le contraire produit des chiffres qui induisent plus en erreur qu'ils n'informent.

Un ticket qui dit « enquêter sur pourquoi le webhook de paiement échoue par intermittence » n'est pas estimable. Le développeur ne sait pas si la cause profonde est une condition de concurrence, un délai d'expiration d'API tierce, une politique de nouvelle tentative mal configurée, ou quelque chose d'entièrement différent. L'estimer comme « moyen » assigne simplement un chiffre à l'ignorance — et maintenant le plan de sprint traite ce chiffre comme s'il signifiait quelque chose.

La réponse honnête est « Je ne sais pas, et j'ai besoin d'un spike pour le découvrir ». Un spike est une investigation limitée dans le temps — typiquement d'une demi-journée à deux jours — dont le résultat n'est pas du code fonctionnel mais de l'information. Après le spike, l'équipe en sait assez pour estimer la correction réelle. Les spikes ne sont pas un échec de l'estimation ; ils sont l'estimation qui fonctionne correctement en admettant ses propres limites.

La même chose s'applique au travail véritablement nouveau : une nouvelle intégration avec une API inconnue, une migration vers une technologie que l'équipe n'a pas utilisée, ou un problème de performance sans goulot d'étranglement évident. Forcer une estimation sur ces tickets ne produit pas d'information utile — cela produit un chiffre que l'équipe se sent obligée d'atteindre et un plan construit sur de la fiction.

Les équipes qui sont obsédées par la précision de l'estimation optimisent la mauvaise chose. Une équipe dont les estimations sont systématiquement décalées de 30 % mais qui utilise la conversation d'estimation pour faire ressortir les hypothèses, attraper les lacunes de portée et s'aligner sur l'approche tire plus de valeur de l'estimation qu'une équipe dont les chiffres tombent parfaitement mais qui estime en silence.

Le chiffre est un sous-produit. La conversation est le produit. Quand deux développeurs estiment le même ticket différemment, ce désaccord est de l'information — l'un d'eux sait quelque chose que l'autre ne sait pas, ou ils imaginent des implémentations différentes. Résoudre ce désaccord avant le début du travail prévient le retravail, attrape les exigences manquantes et construit un contexte partagé à travers l'équipe.

C'est pourquoi les méthodes d'estimation qui forcent la conversation (comme le Planning Poker, où tout le monde révèle simultanément) surpassent les méthodes qui ne le font pas (comme une personne qui annonce un chiffre et demande « est-ce que ça semble correct ? »). La révélation ne concerne pas le chiffre — elle concerne l'écart. Un ticket où tout le monde montre un 3 est ennuyeux. Un ticket où une personne montre un 2 et une autre montre un 8 est là où l'estimation gagne sa valeur.