Quand on estime un ticket, ce n’est pas « je » qui estime, mais « nous ». Toutes les estimations sont le résultat d’un travail d’équipe.
Le concept en bref
Une estimation est la manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé. Pour les équipes qui les utilisent, c’est généralement la dernière étape avant de passer un ticket en ready (DoR).
Ce n’est pas SCRUM, c’est XP — et ce n’est surtout pas un outil de prédiction exacte.
Pourquoi c’est important
- Réduire les risques — la session d’estimation met au jour les zones d’ombre du projet. Une fois identifiées, l’équipe choisit comment les traiter : les inclure dans l’estimation, ou lancer un Spike (idéalement avec un ou plusieurs POC) quand la solution technique n’est pas encore connue
- Servir la décision et la priorisation — connaître le coût avant de développer aide à estimer le ROI, à prioriser le backlog, et explique pourquoi une story estimée peut ne jamais être développée
- Établir la confiance — une équipe fiable sur sa capacité à livrer permet de négocier plus facilement le périmètre des releases avec les parties prenantes
- Aligner l’équipe — s’assurer d’une compréhension commune du périmètre et de la valeur à produire
- Découper les User Stories — estimer un ticket permet souvent de réaliser qu’il est trop gros et de le diviser, ce qui renforce la prédictibilité du travail
- Organiser le sprint — connaître l’effort nécessaire permet de juger si un ticket est réalisable dans le sprint, et d’estimer le nombre de sprints nécessaires pour une release (forecast)
Comment faire
Que représente une estimation ? Plusieurs hypothèses sont possibles, chacune avec ses limites :
- Du temps — l’humain estime mal son temps, une date ne prend pas en compte les imprévus (mails, meetings, entraide), et la charge émotionnelle du temps pousse soit à bâcler, soit à surestimer
- De la complexité — point de départ intéressant, mais deux tâches à complexité très différente peuvent demander un temps de réalisation comparable
- Du risque — au plus c’est risqué, au plus l’estimation serait élevée ; insuffisant pris seul, car le risque ne se matérialise pas toujours
- De l’effort — la synthèse des trois : quantité de travail, complexité, risques et inconnues, temps
Quelle mesure utiliser pour représenter l’effort ?
- T-shirt sizing (XS, S, M, L, XL…) — pour du haut niveau, avant analyse
- Les animaux (puce, tigre, éléphant…) — même usage, avant analyse ou au niveau épique
- Les Story Points (1, 2, 3, 5, 8, 13…) — pour des tickets déjà bien informés, avec peu d’inconnues
Pourquoi une estimation relative ? Les humains sont mauvais pour estimer dans l’absolu, mais très bons pour comparer deux choses entre elles. C’est ce principe que les Story Points exploitent : une story qui vaut 2 représente la moitié de l’effort d’une story qui vaut 4, sans que l’un ou l’autre chiffre ne corresponde à une durée précise.
Exemple concret
La course à pied vue par un Iron Man et un Scrum Master de 110 kg
Demandez-leur une estimation en temps pour les 20 km de Bruxelles : le premier répond 2h30, le second 6h (sans certitude de terminer). Impossible à généraliser si c’est une troisième personne qui court le jour J.
Demandez-leur d’estimer l’effort : les deux répondent « 20 km ». Et si demain c’est un marathon, les deux savent que l’effort double.
Pour les tickets, c’est la même logique : estimer en jours/homme suppose de savoir qui fera la tâche. Estimer en effort, non.
Les verres d’eau
Alignez trois verres d’eau remplis à des niveaux différents.
- Le premier verre sert de référence
- Le second est visiblement plus rempli — on peut estimer de combien, sans mesurer au millilitre
- Le troisième est à peu près aussi rempli que le premier — à moitié plein, ou à moitié vide, peu importe
Personne n’est capable de donner un volume exact au premier coup d’œil. Tout le monde est capable de comparer les trois entre eux. C’est exactement ce que fait une équipe quand elle attribue des Story Points : elle ne mesure pas, elle compare.
Pièges & limites
- Une équipe de spécialistes n’est pas interchangeable — même si l’équipe est censée couvrir tout le produit, une baisse de charge dans un domaine donné fait mécaniquement baisser la quantité de travail livrée
- Aucun chiffre ne sera jamais précis — mais pour une équipe stable, la corrélation entre estimation et tickets done par sprint s’affine avec le temps, ce qui améliore la prédiction à moyen terme
- Le forecast n’est pas une boule de cristal — il ne permet absolument pas de prédire avec certitude quand une application sera terminée