Pièges d'estimation en Scrum : une liste pour les éviter dès ce sprint
L'estimation est l'une des pratiques les plus mal employées en Scrum. Le Guide Scrum n'impose ni points de récit, ni planning poker, ni aucune technique particulière — il indique simplement que les Développeurs sont responsables du dimensionnement du travail et que le Product Owner et les Développeurs affinent le Backlog de produit pour rendre les éléments prêts. Pourtant, les équipes transforment régulièrement l'estimation en source de pression, de fausse précision et de friction. En 2021, alors que la plupart des séances de planification se tenaient en visioconférence, les distorsions discrètes dans la manière d'estimer étaient devenues encore plus difficiles à repérer.
Voici une liste à appliquer lors de votre prochaine planification de sprint ou séance d'affinage. Elle ne rendra pas les estimations parfaites — rien ne le fait — mais elle les gardera honnêtes et utiles.
La liste d'estimation
Estimez en équipe, pas individuellement. L'intérêt de techniques comme le planning poker est de faire émerger les hypothèses divergentes. Quand la voix la plus forte ou le développeur chevronné fixe le chiffre, on perd la conversation qui donne sa valeur à l'estimation.
Traitez les estimations comme relatives, pas comme des heures déguisées. Les points comparent l'effort et la complexité entre éléments. Dès que quelqu'un déclare « un point égale un jour », on a reconstruit l'estimation en temps avec des étapes en plus et perdu toute la valeur.
Affinez avant la planification, pas pendant. Des éléments tirés dans la planification sans discussion préalable sont devinés. Un affinage continu signifie que l'équipe a déjà affronté les grandes inconnues.
Découpez tout ce qui est trop gros pour être raisonné. Une estimation énorme, c'est l'équipe qui vous dit qu'elle ne comprend pas l'élément. Divisez-le en morceaux assez petits pour que l'incertitude devienne visible et discutable.
Servez-vous de la vélocité pour prévoir, jamais pour juger. La vélocité aide l'équipe à planifier ce qu'elle prend dans un sprint. Dès qu'elle devient une cible de performance, les gens gonflent les estimations et le chiffre ne veut plus rien dire.
Réestimez quand vous apprenez quelque chose. Une estimation est un instantané de ce que l'on savait à un moment. Quand de l'information nouvelle arrive, mettez-la à jour plutôt que de défendre une supposition périmée.
Signaux d'alerte à surveiller
Des estimations qui ne changent jamais, signe que l'équipe les ajuste à rebours pour coller aux attentes.
Des gestionnaires comparant les vélocités de différentes équipes comme s'il s'agissait d'une même monnaie.
De longs débats pour savoir si un élément vaut trois ou cinq, alors que l'écart change rarement la décision.
Un Product Owner qui négocie les estimations à la baisse, ce qui corrompt le seul signal honnête que les Développeurs peuvent donner.
La façon la plus saine de voir l'estimation, c'est comme une conversation, non un chiffre. La discussion qui produit un cinq — révélant une dépendance cachée, un souci de test, une exigence floue — vaut généralement plus que le cinq lui-même. Si vos séances produisent des chiffres sans cette conversation, vous mesurez un accord pour passer à autre chose, pas une compréhension partagée.
Choisissez deux ou trois points de cette liste et appliquez-les à votre prochaine séance. Vous découvrirez sans doute que l'objectif n'a jamais été la précision. C'était d'avoir une équipe qui comprend assez bien le travail pour s'engager sur un objectif de sprint en toute confiance.
Si vos équipes veulent affûter leur manière de planifier, d'estimer et de livrer, le conseil en réalisation de programmes et de projets de XNM peut vous aider à bâtir des pratiques agiles qui tiennent sous une vraie pression.