Quelqu'un lâche « ça, c'est deux jours » avant le vote, et plus personne n'ose estimer au-delà de trois. Toutes les équipes l'ont vécu. Ce phénomène a un nom, le biais d'ancrage, et c'est la raison principale pour laquelle le Planning Poker fait voter chacun en secret puis révéler toutes les cartes en même temps.
Cet article explique ce qu'est l'ancrage, ce que la recherche en dit pour l'estimation logicielle, où il se glisse dans les séances d'estimation et quelles habitudes permettent de le tenir à distance.
Qu'est-ce que le biais d'ancrage ?
Le biais d'ancrage est la tendance à trop s'appuyer sur le premier chiffre entendu au moment d'estimer quelque chose. Cette première valeur, l'ancre, devient un point de départ dont on s'éloigne trop peu, même quand elle est sans rapport avec le sujet ou manifestement fausse. Les psychologues Amos Tversky et Daniel Kahneman l'ont décrit en 1974 sous le nom d'« ancrage et ajustement », l'un des raccourcis que nous prenons pour juger dans l'incertitude. Dans une équipe de développement, l'ancre est souvent un chiffre prononcé avant le vote : l'intuition rapide d'un développeur, l'échéance d'un manager, le budget d'un client ou l'estimation d'une fonctionnalité semblable l'an dernier. Tous ceux qui l'ont entendu estiment ensuite plus près de ce chiffre qu'ils ne l'auraient fait seuls. L'effet est d'autant plus fort que le travail est incertain, ce qui est le cas de la plupart des user stories. Le Planning Poker y répond par une règle simple : chacun choisit sa carte en secret, et toutes les cartes sont révélées en même temps.
Que dit la recherche sur l'ancrage dans l'estimation logicielle ?
L'ancrage est l'un des effets les mieux documentés de la recherche sur le jugement, et l'estimation logicielle n'y échappe pas.
L'expérience d'origine. Tversky et Kahneman faisaient tourner une roue de loterie devant les participants, puis leur demandaient quel pourcentage des pays africains siégeait à l'ONU. Ceux qui avaient vu la roue s'arrêter sur 10 répondaient 25 en médiane ; ceux qui avaient vu 65 répondaient 45. Un nombre tiré au hasard déplaçait leur estimation de 20 points (Tversky et Kahneman, 1974).
L'estimation d'un projet logiciel. Jorge Aranda et Steve Easterbrook ont demandé à 23 participants, surtout des étudiants de master et quelques professionnels, d'estimer le même projet (ESEC/FSE 2005). Certains lisaient la remarque d'un manager qui avouait n'avoir « aucune expérience des projets logiciels » mais pensait à 2 mois ; d'autres lisaient la même remarque avec 20 mois ; un groupe témoin ne lisait aucun chiffre. Les estimations moyennes : 6,8 mois avec l'ancre basse, 8,3 mois sans ancre et 17,4 mois avec l'ancre haute (données du mémoire). L'avis d'un non-expert déclaré suffisait à doubler l'estimation.
Les attentes du client. L'équipe de Magne Jørgensen, au laboratoire Simula, a observé le même mécanisme avec les attentes des clients : les estimateurs se rapprochaient de ce que le client espérait, même après avoir été prévenus que cette attente ne disait rien de l'effort réel (Jørgensen et Sjøberg, 2004).
En entreprise. Une expérience menée auprès de 46 sociétés de sous-traitance a mesuré des effets plus faibles qu'en laboratoire, mais une échéance courte inscrite dans le cahier des charges faisait encore nettement baisser les estimations (Jørgensen et Grimstad, 2011).
| Étude | Ancre | Effet sur les estimations |
|---|---|---|
| Tversky et Kahneman, 1974 | Un nombre tiré au hasard sur une roue (10 ou 65) | Réponses médianes de 25 contre 45 |
| Aranda et Easterbrook, 2005 | L'intuition d'un non-expert (2 ou 20 mois) | Moyenne de 6,8 contre 8,3 (sans ancre) contre 17,4 mois |
| Jørgensen et Sjøberg, 2004 | L'effort espéré par le client | Estimations attirées vers cette attente |
| Jørgensen et Grimstad, 2011 | Des informations hors sujet ou trompeuses | Plus faible sur le terrain, mais une échéance courte fait encore baisser les estimations |
Où l'ancrage se glisse-t-il dans les séances d'estimation ?
Les ancres ont rarement l'air d'en être. Les plus fréquentes :
- La première voix. Un « ça devrait aller vite » ou un « au moins 8 » lancé pendant la présentation de la story.
- La personne la plus expérimentée. Quand le lead technique parle en premier, les autres s'alignent, même quand ils voient des risques qu'il a manqués.
- L'échéance ou le budget. « Il nous le faut pour la release » devient sans qu'on s'en rende compte « ça doit être petit ».
- L'avis du Product Owner. Le PO connaît la valeur métier, pas l'effort technique. Les règles du Planning Poker recommandent qu'il réponde aux questions sans voter.
- L'ancienne estimation. Une story réestimée après refinement reste souvent collée à son premier chiffre.
- Les votes visibles. Dans un fil de discussion ou en visio, chaque chiffre tapé ou prononcé ancre ceux qui n'ont pas encore répondu.
- Une suggestion d'IA affichée trop tôt. Une estimation proposée par un assistant avant le vote est une ancre de plus. Notre article sur le Planning Poker et l'IA conseille de ne la montrer qu'après le premier tour.
Comment le Planning Poker limite-t-il l'ancrage ?
Le Planning Poker, décrit par James Grenning en 2002 et popularisé par Mike Cohn, repose sur une idée : recueillir d'abord des avis indépendants, discuter ensuite.
- Chacun vote en secret. Chaque estimateur choisit sa carte sans voir celle des autres.
- Toutes les cartes sont révélées en même temps. Aucun vote ne peut en influencer un autre, puisqu'aucun n'est visible avant la révélation.
- Les extrêmes s'expliquent. Les votes le plus haut et le plus bas justifient leur choix, ce qui fait apparaître les risques ou les raccourcis que les autres n'avaient pas vus.
- L'équipe revote. Après la discussion, les estimations convergent en général, cette fois pour de bonnes raisons.
Des votes indépendants montrent aussi plus honnêtement les désaccords. Sur les sessions mesurées dans notre page de données d'usage, à peine un quart des premiers votes sont unanimes, et environ 40 % présentent un écart d'au moins deux crans sur l'échelle de Fibonacci. Avec l'ancrage, ce désaccord serait resté caché derrière le premier chiffre prononcé.
L'outil doit protéger cette indépendance. Dans Planning Poker Online, personne ne voit un vote avant la révélation, pas même le Scrum Master. Un tableur partagé ou un fil de discussion où les chiffres apparaissent un par un casse la règle.
Quelles autres habitudes réduisent l'ancrage ?
La révélation simultanée protège le vote lui-même. Ces habitudes protègent ce qui se passe autour.
| Habitude | Comment l'appliquer | Ancre neutralisée |
|---|---|---|
| Donner du contexte, pas des chiffres | Le PO décrit le besoin et les critères d'acceptation, jamais une taille ni une durée | Pression métier |
| Un facilitateur neutre | Le Scrum Master garde sa propre estimation pour lui | Autorité |
| Varier qui parle en premier | Après la révélation, alterner entre votes hauts et votes bas | Ancienneté |
| Parler de l'échéance après le vote | Estimer d'abord l'effort, puis discuter de ce qui tient avant la date | Échéance |
| Réestimer à partir de zéro | Masquer ou ignorer l'ancienne estimation quand une story revient | Ancienne estimation |
| Des stories de référence stables | Comparer à deux ou trois stories validées, pas au dernier chiffre entendu | Chiffres au hasard |
Les stories de référence sont elles aussi des ancres, mais choisies et partagées : l'équipe les a retenues, tout le monde les connaît et elles changent rarement. C'est toute la différence entre l'estimation relative et l'ancrage. Notre guide pour animer une session de Planning Poker détaille ces réflexes de facilitation.
La révélation simultanée supprime-t-elle complètement l'ancrage ?
Non. Elle supprime l'ancrage entre les votes, pas toutes les ancres.
- La discussion avant le vote ancre encore. Si quelqu'un cite un chiffre pendant la présentation de la story, le vote secret arrive trop tard. Demandez des questions sur le périmètre, pas des avis sur la taille.
- Les tours suivants convergent volontairement. Se rapprocher du groupe après un bon argument est le but de la discussion. S'aligner à cause d'un titre ou d'une voix forte ne l'est pas : c'est pourquoi le facilitateur fait parler les extrêmes avant que quiconque revote.
- Les effets réels varient. Jørgensen et Grimstad ont constaté des effets bien plus faibles sur le terrain qu'en laboratoire, alors qu'une information pertinente mais trompeuse, comme une échéance courte, pouvait encore peser lourd. Traitez l'ancrage comme un risque à maîtriser, pas comme une fatalité.
Questions fréquentes
Quel est un exemple de biais d'ancrage dans l'estimation agile ? Un exemple typique de biais d'ancrage dans l'estimation agile : un développeur dit « c'est une correction rapide » pendant la présentation d'une story. Même si la story touche finalement plusieurs services, les estimations de l'équipe restent basses, car chacun s'est ajusté à partir de cette remarque au lieu d'estimer le travail de façon indépendante.
Le Planning Poker élimine-t-il le biais d'ancrage ? Le Planning Poker n'élimine pas le biais d'ancrage, mais il en supprime la source la plus fréquente : l'influence des votes les uns sur les autres. Comme chaque carte est choisie en secret et révélée en même temps, aucun estimateur ne voit un autre chiffre avant le sien. Les ancres prononcées avant le vote, comme une échéance, peuvent encore jouer.
Le Product Owner doit-il voter au Planning Poker ? Dans la plupart des équipes, le Product Owner ne vote pas au Planning Poker. Il apporte le contexte métier et répond aux questions, tandis que les développeurs estiment l'effort du travail. Le vote de la personne qui priorise le backlog peut servir d'ancre, surtout si l'équipe se sent obligée d'être d'accord avec elle.
Les stories de référence sont-elles une forme d'ancrage ? Les stories de référence sont une forme d'ancrage volontaire, et utile. L'équipe choisit deux ou trois stories terminées, s'accorde sur leur taille et y compare le nouveau travail. Contrairement à une remarque en passant ou à une échéance, ces références sont partagées, stables et liées à l'effort : c'est ce qui rend l'estimation relative cohérente dans le temps.
Sources
- Amos Tversky et Daniel Kahneman, Judgment under Uncertainty: Heuristics and Biases, Science, 1974
- Jorge Aranda et Steve Easterbrook, Anchoring and Adjustment in Software Estimation, ESEC/FSE 2005, et Jorge Aranda, mémoire de master, université de Toronto, 2005
- Magne Jørgensen et Dag Sjøberg, The Impact of Customer Expectation on Software Development Effort Estimates, International Journal of Project Management, 2004
- Magne Jørgensen et Stein Grimstad, The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates, IEEE Transactions on Software Engineering, 2011
- James Grenning, Planning Poker or How to avoid analysis paralysis while release planning, 2002
- Mountain Goat Software, Planning Poker
Gardez des estimations indépendantes
L'ancrage commence par un chiffre prononcé trop tôt. Créez une session Planning Poker gratuite : chaque vote reste caché jusqu'à la révélation, et toute l'équipe découvre l'écart en même temps. Sans inscription. Voir toutes les fonctionnalités.
