L'estimation minimale utile

La plupart des équipes surinvestissent dans la précision de l'estimation. Elles débattent pendant dix minutes pour savoir si un ticket vaut 5 ou 8 — une distinction qui n'a aucun impact sur la planification du sprint et encore moins sur la livraison. Le temps passé à argumenter sur la granularité est du temps qui n'est pas consacré à comprendre le travail.

Trois tailles — petit, moyen, grand — couvrent la grande majorité des besoins de planification. Un petit ticket est un travail bien compris qu'un ingénieur peut terminer en une journée ou moins. Un moyen représente un à trois jours avec une certaine complexité ou des inconnues. Un grand représente plus de trois jours et doit probablement être décomposé avant que quelqu'un ne commence.

C'est tout. Si votre équipe peut trier les tickets dans ces trois catégories de manière cohérente, vous avez suffisamment d'information pour planifier un sprint, repérer les semaines surchargées et identifier les tickets qui nécessitent plus de discussion. La valeur marginale de diviser « moyen » en 3, 5 et 8 est réelle pour certaines équipes — mais la plupart des équipes n'en ont pas besoin, et la complexité coûte plus cher que les gains de précision.

Commencez avec P/M/G. Si après quelques sprints vous constatez que votre planification nécessite systématiquement une résolution plus fine — peut-être que les grands tickets varient trop, ou que vous avez des engagements externes qui nécessitent des prévisions plus serrées — passez à Fibonacci ou aux tailles de t-shirt. Mais faites-en une décision tirée par les données, basée sur des preuves, et non une décision poussée par ce qu'un cadre vous a dit de faire.

P/M/G ne fonctionne plus quand quelqu'un à l'extérieur de l'équipe a besoin de plus que « à peu près combien de travail est-ce ? » Trois situations vous poussent vers une estimation plus granulaire :

Engagements externes. Quand une équipe de vente doit dire à un client « la fonctionnalité X sera livrée au T3 », l'équipe d'ingénierie doit estimer avec suffisamment de résolution pour soutenir cette date. P/M/G ne peut pas distinguer entre « trois semaines » et « trois mois ». Les estimations à l'échelle de Fibonacci combinées aux données de vélocité historique le peuvent — pas parfaitement, mais suffisamment bien pour donner une fourchette plutôt qu'un haussement d'épaules.

Budgétisation et dotation en personnel. Une équipe produit qui décide de financer le Projet A ou le Projet B doit comparer leurs coûts. « Le Projet A représente 40 points d'histoire et le Projet B en représente 90 » est une donnée approximative mais utile. « Le Projet A a quelques moyens et le Projet B a plus de grands » ne l'est pas.

Planification des dépendances. Quand le travail de l'Équipe A est bloqué jusqu'à ce que l'Équipe B termine un prérequis, les deux équipes ont besoin de suffisamment de précision d'estimation pour coordonner les échéanciers. « Nous aurons terminé quelque part dans le prochain sprint ou deux » n'est pas suffisant quand une équipe en aval planifie son travail autour de la transition.

Dans les trois cas, l'investissement dans la précision se rentabilise parce que quelqu'un prend une décision basée sur l'estimation. Si personne ne prend de décision — si les estimations vont dans un outil de suivi et que personne ne les regarde — économisez le temps.

La plus grande menace pour une estimation honnête est l'ancrage : le premier chiffre prononcé à voix haute déforme tous les chiffres qui suivent. Si le responsable technique dit « Je pense que c'est environ un 3 », l'ingénieur junior qui pensait 8 se remet en question et dit 5. L'équipe converge vers un chiffre qui reflète la voix la plus forte, pas la compréhension collective.

Le Planning Poker résout cela mécaniquement. Tout le monde estime simultanément et révèle en même temps. Il n'y a pas d'ancrage parce qu'il n'y a pas de premier chiffre. L'écart — la différence entre l'estimation la plus élevée et la plus basse — est le signal. Un 3 unanime signifie que l'équipe est d'accord et vous passez à autre chose. Une division entre 2 et 13 signifie que deux personnes imaginent un travail fondamentalement différent, et cette conversation doit avoir lieu avant que quiconque n'écrive du code.

L'estimation asynchrone étend cela aux équipes distribuées. Au lieu de se rassembler dans une salle, les ingénieurs soumettent leurs estimations de manière indépendante sur une période de temps, avec des votes cachés jusqu'à ce que tout le monde ait soumis. L'avantage anti-ancrage est le même ; la logistique convient aux équipes qui couvrent plusieurs fuseaux horaires ou ne peuvent pas justifier des réunions synchrones pour chaque lot de tickets.

Les deux approches partagent le même principe : l'estimation fonctionne mieux quand les opinions se forment indépendamment avant d'être partagées. Toute méthode qui permet au chiffre de l'ingénieur senior d'influencer la salle avant que les autres ne se soient engagés sur leur propre estimation laisse de l'information sur la table.