Articles

Séquence de Fibonacci en Agile : Pourquoi nous utilisons 1, 2, 3, 5, 8, 13 pour les story points

Cartes de planning poker montrant les nombres de Fibonacci étalées sur une table avec les mains des développeurs les atteignantCartes de planning poker montrant les nombres de Fibonacci étalées sur une table avec les mains des développeurs les atteignant
Matt Lewandowski

Matt Lewandowski

Dernière mise à jour 16/02/20268 min de lecture

Vous vous asseyez pour votre première session de planning poker. Le chef d'équipe sort un élément du carnet de produits et demande à tous de voter. Vous regardez vos options de cartes : 1, 2, 3, 5, 8, 13. Où est passé le 4 ? Pourquoi saute-t-il de 5 à 8 ? Pourquoi ne pas simplement utiliser 1 à 10 ? C'est la question que pose chaque nouveau membre de l'équipe. Et la réponse révèle quelque chose de fondamental sur la façon dont les humains estiment les travaux complexes.

Ce qu'est réellement la séquence de Fibonacci

La séquence de Fibonacci est une série de nombres où chaque nombre est la somme des deux précédents : 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, et ainsi de suite. Elle a été décrite par le mathématicien italien Leonardo de Pisa (connu sous le nom de Fibonacci) en 1202, bien que le modèle apparaisse partout dans la nature, de la spirale d'un coquillage de nautile à la ramification des arbres. Les équipes agiles n'utilisent pas la séquence de Fibonacci en raison d'un lien avec la nature. Elles l'utilisent parce que les écarts entre les nombres augmentent à mesure que les nombres deviennent plus grands, et cela reflète comment l'incertitude fonctionne dans l'estimation de logiciels.

Pourquoi les échelles linéaires échouent pour l'estimation

Imaginez que votre équipe utilise une simple échelle de 1 à 10. Quelqu'un sort une histoire et deux développeurs votent différemment. L'un dit 6, l'autre dit 7. Ce désaccord est-il significatif ? Probablement pas. La différence entre un 6 et un 7 est si petite que c'est du bruit. Mais maintenant l'équipe passe cinq minutes à débattre pour savoir si c'est vraiment un 6 ou un 7, en essayant de justifier une distinction qui n'existe pas. C'est cinq minutes gaspillées en fausse précision. Une échelle linéaire implique que vous pouvez distinguer entre les niveaux d'effort avec une précision uniforme. Vous ne pouvez pas. Et plus l'élément est grand, pire est votre précision. Comparaison au tableau blanc montrant une échelle linéaire avec des nombres espacés uniformément par rapport à une échelle de Fibonacci avec des écarts croissants entre les valeursComparaison au tableau blanc montrant une échelle linéaire avec des nombres espacés uniformément par rapport à une échelle de Fibonacci avec des écarts croissants entre les valeurs

Pourquoi les écarts importent

La séquence de Fibonacci fonctionne pour l'estimation en raison de trois principes convergents.

Le cône d'incertitude

Les petites tâches sont prévisibles. « Changer la couleur du bouton de bleu à vert » a des inconnues minimes. Vous pouvez l'estimer avec confiance. Les grandes tâches comportent exponentiellement plus d'inconnues. « Construire l'intégration de paiement » ressemble à un seul élément, mais il contient l'authentification, la gestion des erreurs, la logique de nouvelle tentative, les exigences de conformité et les cas limites que vous n'avez pas encore envisagés. Plus le travail est important, plus votre incertitude est grande, et votre échelle d'estimation devrait le refléter. Les écarts de Fibonacci s'élargissent à mesure que la complexité augmente, reflétant la réalité qu'une histoire de 13 points a beaucoup plus d'incertitude qu'une histoire de 3 points. Offrir un choix entre 12 et 13 pour quelque chose d'aussi grand serait une précision sans sens.

Forcer des désaccords significatifs

Avec une échelle de Fibonacci, quand deux développeurs sont en désaccord, le désaccord est significatif. Le saut de 5 à 8 est une augmentation de 60%. Ce type d'écart reflète une différence réelle de compréhension : une personne voit une implémentation simple, l'autre voit une complexité cachée. Ce désaccord déclenche exactement la conversation que vous souhaitez dans le planning poker. « Pourquoi penses-tu que c'est un 8 ? » « Parce que nous devrons gérer le cas de synchronisation hors ligne. » « Ah, je n'y avais pas pensé. » L'échelle force les discussions qui font effectivement remonter les risques et les malentendus. Avec une échelle linéaire, un désaccord 6 vs 7 ne déclenche pas la même urgence de discussion. L'écart est trop petit pour sembler important, même si les hypothèses sous-jacentes sont complètement différentes.

La Loi de Weber

Il existe un principe en psychophysique appelé Loi de Weber : les humains perçoivent les différences comme des proportions, pas des valeurs absolues. Vous pouvez facilement distinguer la différence entre 1 kilogramme et 2 kilogrammes. Mais distinguer la différence entre 50 et 51 kilogrammes ? Beaucoup plus difficile. Il en va de même pour l'estimation. Vous pouvez dire avec confiance si quelque chose est un 2 ou un 3 (un saut de 50 %). Vous ne pouvez pas dire avec confiance si quelque chose est un 14 ou un 15 (un saut de 7 %). La séquence de Fibonacci respecte cela en gardant la différence proportionnelle entre les options adjacentes à peu près constante, ce qui signifie que chaque choix sur l'échelle représente un niveau d'effort genuinely distinguable.

La séquence de Fibonacci modifiée

Si vous avez utilisé différentes échelles d'estimation, vous remarquerez que la plupart des outils agiles n'utilisent pas la séquence de Fibonacci pure. Ils utilisent une version modifiée : 1, 2, 3, 5, 8, 13, 20, 40, 100 La modification commence après 13. Fibonacci pur vous donnerait 21, 34, 55, 89. Au lieu de cela, les équipes arrondissent à des nombres plus nets : 20, 40, 100. Pourquoi ? Parce qu'à cette échelle, la précision de Fibonacci n'a pas d'importance. Quelque chose estimé à 40 points a tellement d'incertitude que la différence entre 34 et 40 est hors de propos. Les nombres ronds communiquent le bon message : « C'est très gros, et nous devinons. » La plupart des équipes utilisant cette échelle traitent tout ce qui dépasse 13 comme un signal que l'élément doit être divisé en histoires plus petites avant de pouvoir être travaillé.

Les cartes d'infini et d'interrogation

Développeur tenant une carte d'infini et une carte d'interrogation pendant une session de planning pokerDéveloppeur tenant une carte d'infini et une carte d'interrogation pendant une session de planning poker Au-delà des nombres, la plupart des jeux de planning poker incluent deux cartes spéciales : L'infini signifie « c'est trop gros pour estimer ». C'est la façon de l'équipe de dire qu'une histoire doit être décomposée avant que l'estimation soit significative. Si quelqu'un joue l'infini, la bonne réponse n'est pas de les négocier jusqu'à un 40. C'est d'arrêter d'estimer et de commencer à diviser. Le point d'interrogation signifie « Je n'ai pas assez d'informations pour estimer cela du tout ». Peut-être que les exigences ne sont pas claires. Peut-être que le développeur n'a pas travaillé avec cette partie de la base de code. Peut-être que l'histoire dépend d'une décision qui n'a pas encore été prise. Le point d'interrogation fait remonter ces lacunes afin qu'elles puissent être abordées lors du raffinement du carnet de produits avant que le travail n'entre dans un sprint. Les deux cartes servent le même objectif : elles empêchent l'équipe d'attribuer un nombre à quelque chose qui ne le mérite pas encore. Une estimation présentée comme un nombre est traitée comme un plan. Un point d'interrogation est traité comme un élément d'action.

Quand Fibonacci n'est pas le bon choix

La séquence de Fibonacci est l'échelle d'estimation la plus courante, mais ce n'est pas toujours la meilleure option. Le dimensionnement par t-shirt (XS, S, M, L, XL) fonctionne mieux quand vous avez besoin d'estimations rapides et approximatives et que vous ne voulez pas vous engager dans des débats numériques. C'est particulièrement utile pour la planification au niveau de la feuille de route où les points exactes n'ont pas d'importance. Lisez notre guide sur les techniques d'estimation agile pour voir comment le dimensionnement par t-shirt et d'autres méthodes se comparent. Puissance de 2 (1, 2, 4, 8, 16, 32) plaît aux équipes qui veulent des écarts encore plus agressifs entre les options. Chaque étape double l'effort, ce qui rend les désaccords encore plus évidents. Les échelles linéaires peuvent fonctionner pour les équipes qui effectuent un travail très prévisible et uniforme où les éléments se regroupent genuinely autour de tailles similaires. Mais ces équipes n'ont généralement pas besoin d'estimation du tout. Compter les éléments vous donne la même précision de prévision. Le mouvement #NoEstimates fait un argument convaincant pour savoir quand ignorer complètement l'estimation. La bonne échelle dépend du contexte de votre équipe, mais pour la plupart des équipes agiles effectuant un travail varié avec une certaine incertitude, Fibonacci reste le paramètre par défaut pour une bonne raison.

Mettre Fibonacci en pratique

Comprendre pourquoi Fibonacci fonctionne est utile. Mais la véritable valeur provient de son utilisation dans des sessions d'estimation structurées où toute l'équipe participe. Si vous exécutez planning poker pour la première fois, commencez par l'échelle de Fibonacci standard (1, 2, 3, 5, 8, 13). Établissez une histoire de référence rapidement (« tout le monde convient que cette modification de formulaire de connexion est un 3 ») et estimez tout le reste par rapport à cet ancrage. Si un élément génère des estimations très différentes, ne les moyennez pas. Discutez du désaccord. C'est là que l'échelle fait son travail. Vous pouvez l'essayer avec votre équipe en utilisant l'outil de planning poker de Kollabe. Choisissez Fibonacci comme échelle, invitez votre équipe et commencez à estimer. Vous pourriez également vouloir exécuter des éléments à travers l'analyseur de complexité d'estimation avant la session pour identifier les histoires susceptibles de générer des désaccords.

Les heures mesurent la durée, qui varie selon la personne. Un développeur senior pourrait terminer une tâche en 2 heures qu'un développeur junior prend 8 heures. Les story points mesurent la complexité relative aux autres travaux, sur lesquels toute l'équipe peut s'accorder indépendamment de qui prend la tâche. Les points évitent également le piège de traiter les estimations comme des délais.

Un story point représente l'effort relatif et la complexité comparés à d'autres histoires que votre équipe a estimées. Une histoire de 5 points devrait être environ deux fois plus complexe qu'une histoire de 3 points et environ deux fois moins complexe qu'une histoire de 8 points. Les nombres spécifiques n'ont aucune signification en isolation. Ils n'ont de sens que relatif les uns aux autres au sein de votre équipe.

Certaines équipes incluent 0 dans leur échelle de Fibonacci pour représenter un travail trivially petit, comme une faute de frappe ou un changement de configuration. Cela signifie « cela prend presque aucun effort mais nous devrions le suivre. » D'autres équipes ignorent 0 et utilisent 1 comme leur plus petite valeur. Les deux approches fonctionnent, soyez juste cohérent.

Si la plupart de vos estimations se regroupent autour de deux valeurs, vos histoires pourraient être trop de taille similaire (ce qui est en fait bien pour la prévision du débit) ou votre équipe pourrait ne pas différencier suffisamment. Essayez de recalibrer vos histoires de référence. Assurez-vous que votre ancre « 3 » est genuinely petite et que votre ancre « 13 » est genuinely grande. Si tout s'empile toujours, vos histoires devront peut-être être divisées différemment. Consultez notre guide surla division des épopéespour les modèles.