Estimation en Scrum : Story Points, Planning Poker et Vélocité démystifiés
Cet article fait partie de notre Le Guide Ultime de Scrum : Maîtriser le Framework Agile de A à Z.
Dans le monde du développement logiciel et de l’agilité, peu de sujets provoquent autant de débats enflammés que l’estimation des tâches. Entre équipes submergées par des sessions d’évaluation interminables, managers obnubilés par la courbe de vélocité et développeurs frustrés par la conversion forcée de points en heures, la pratique s’éloigne souvent de son intention initiale. Pourtant, comprendre les mécaniques fondamentales de l’estimation relative permet de transformer ce moment de tension en un puissant levier de collaboration et de prédictibilité.
La vérité sur Scrum et l’estimation : Ce que dit (et ne dit pas) le Scrum Guide
Une mise au point s’impose avant d’entrer dans le détail des techniques : l’estimation ne fait pas partie des exigences prescrites par le cadre Scrum. Si vous relisez attentivement le Scrum Guide rédigé par ses créateurs Jeff Sutherland et Ken Schwaber, vous constaterez qu’aucune méthode d’estimation particulière n’est imposée.
Le Scrum Guide indique simplement que les éléments du Product Backlog doivent être affinés et dimensionnés (sized) afin que les développeurs puissent sélectionner ce qu’ils s’engagent à accomplir durant le Sprint. Les notions de Story Points, de Planning Poker ou de vélocité sont des pratiques complémentaires issues du terrain et popularisées par la communauté agile. Elles ne constituent en aucun cas une règle officielle du framework, même si des organismes comme Scrum.org ou la Scrum Alliance les enseignent fréquemment dans leurs parcours de formation.
Les Story Points : L’estimation relative expliquée
Pendant des décennies, l’ingénierie logicielle a tenté d’estimer les projets en heures ou en jours-hommes absolus. Le constat fut sans appel : l’esprit humain est notoirement médiocre pour évaluer la durée exacte d’une tâche complexe non encore réalisée. En revanche, l’humain excelle à comparer des objets entre eux. C’est sur ce principe d’estimation relative que reposent les Story Points, un concept clé popularisé notamment par Mike Cohn.
Un Story Point est une unité de mesure abstraite et non temporelle. Il synthétise trois facteurs indissociables :
- La complexité : le degré de difficulté technique ou d’architecture.
- L’effort : la quantité de travail matériel à fournir.
- L’incertitude ou le risque : le niveau d’inconnu lié aux dépendances, à la technologie ou au besoin fonctionnel.
Pour calibrer ces points, les équipes s’appuient généralement sur une échelle d’estimation dérivée de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 20…). Pourquoi cette progression non linéaire ? Parce que plus une tâche est volumineuse, plus l’incertitude grandit. Débattre pour savoir si un gros morceau de code fait 12 ou 13 points n’a aucun sens : la suite de Fibonacci force à trancher entre un 8, un 13 ou un 20. Si une User Story dépasse 8 ou 13 points, c’est le signal d’alerte qu’elle est trop grosse et doit être découpée en éléments plus fins.
Le Planning Poker : Réduire les biais d’ancrage en équipe
Attribuer des Story Points ne doit pas être la décision solitaire d’un expert ou d’un lead developer. C’est ici qu’intervient le Planning Poker, une technique d’estimation collaborative par consensus conçue par James Grenning en 2002 puis approfondie par Mike Cohn. Cette méthode s’inspire directement de la méthode Delphi (ou Wideband Delphi).
Le déroulement d’une session de Planning Poker est simple mais rigoureux :
- Le Product Owner présente une User Story et répond aux questions de clarification.
- Chaque développeur choisit silencieusement dans son jeu une carte représentant son estimation en Story Points.
- Toutes les cartes sont révélées simultanément.
Cette révélation synchrone est cruciale : elle élimine complètement le biais d’ancrage cognitif, ce phénomène où la première personne qui prononce un chiffre (« Ça devrait prendre 3 jours ») influence inconsciemment toute l’assemblée. Si les cartes affichent des valeurs divergentes (par exemple un 2 et un 13), le modérateur invite l’estimation la plus basse et l’estimation la plus haute à expliquer leur raisonnement. Le développeur ayant voté 13 a peut-être identifié un risque d’impact sur la base de données que les autres n’avaient pas vu ; celui ayant voté 2 connaît peut-être un composant réutilisable. Le véritable bénéfice du Planning Poker réside dans cette discussion, qui permet d’aligner la compréhension de toute l’équipe.
La Vélocité : Un outil de prévision, jamais un KPI de productivité
Une fois les fonctionnalités estimées en Story Points et réalisées lors des Sprints, l’équipe peut mesurer sa vélocité. La vélocité représente le nombre moyen de Story Points complétés (c’est-à-dire répondant strictement à la Definition of Done) sur les derniers Sprints.
Si une équipe a réalisé 28 points au Sprint 1, 32 points au Sprint 2 et 30 points au Sprint 3, sa vélocité moyenne se situe autour de 30 points par Sprint. Cette métrique empirique sert un objectif précis : aider au suivi de projet et à la planification des prochaines versions (release planning). Elle permet d’anticiper le nombre de Sprints nécessaires pour livrer un ensemble de fonctionnalités du Product Backlog.
Burndown Chart agile » loading= »lazy »/>Il existe deux règles d’or absolues concernant la vélocité :
- La vélocité n’est PAS comparable entre équipes différentes : L’équipe Alpha peut décider qu’une tâche de référence vaut 1 point, tandis que l’équipe Beta attribue 3 points à cette même tâche. L’équipe Alpha affiche une vélocité de 30 points et l’équipe Beta une vélocité de 90 points, sans que l’équipe Beta ne soit trois fois plus performante. Chaque équipe possède son propre étalonnage.
- La vélocité ne doit JAMAIS mesurer la performance individuelle : Évaluer l’efficacité d’un développeur au nombre de points qu’il « ferme » détruit l’esprit d’entraide, pousse au bâclage des revues de code et incite à sur-estimer artificiellement le travail.
Exemples concrets des erreurs les plus fréquentes sur le terrain
Même avec de bonnes intentions, de nombreuses organisations tombent dans des dérives managériales qui dénaturent l’agilité. Analyse de trois erreurs très répandues :
Erreur n°1 : Comparer la vélocité de deux équipes
Exemple concret : Un directeur des opérations observe que l’équipe « Mobile » produit 45 points par Sprint alors que l’équipe « Web » n’en produit que 20. Lors du bilan trimestriel, il demande publiquement à l’équipe Web de « s’aligner sur le rythme de l’équipe Mobile ». Résultat ? Inconsciemment, lors du Sprint Planning suivant, l’équipe Web se met à estimer à 5 points ce qu’elle évaluait auparavant à 2 points. Sa vélocité double artificiellement sur le papier dans leur outil comme Jira ou Azure DevOps, mais la quantité réelle de valeur livrée aux utilisateurs reste strictement inchangée.
Erreur n°2 : Convertir systématiquement les points en heures
Exemple concret : Pour rassurer sa hiérarchie, un Scrum Master décrète la formule : « 1 Story Point = 4 heures de travail ». Très vite, les développeurs cessent d’évaluer la complexité relative et se mettent à faire du calcul horaire déguisé : « Cette tâche va me prendre 2 jours, soit 16 heures, donc c’est une story de 4 points ». On réintroduit ainsi toute la lourdeur et l’imprécision des estimations temporelles classiques, perdant tout l’intérêt de la comparaison relative et du Planning Poker.
Erreur n°3 : Utiliser la vélocité comme un objectif de management
Exemple concret : Dans un cadre d’entreprise s’inspirant de grands frameworks à l’échelle comme SAFe, de Nexus ou de LeSS, le management fixe un objectif de performance (OKR) imposant une augmentation de la vélocité de 10 % à chaque trimestre. Sous cette pression, les développeurs sacrifient la qualité technique, réduisent les tests unitaires et créent une dette technique colossale. La vélocité augmente temporairement, puis s’effondre quelques mois plus tard sous le poids des bugs en production.
Les alternatives : Du T-Shirt Sizing au mouvement #NoEstimates
L’estimation relative en Story Points n’est pas la seule voie possible. Selon le niveau de maturité de l’équipe et le contexte du projet, d’autres approches offrent d’excellents résultats :
Le T-Shirt Sizing (S, M, L, XL)
Idéal pour l’élaboration de feuilles de route stratégiques ou la gestion d’Epics volumineuses, le T-Shirt Sizing attribue des tailles indicatives (XS, S, M, L, XL). Cette méthode très visuelle, facilement utilisable sur des tableaux virtuels comme Miro ou Trello, évite de se perdre dans des chiffrages chiffrés prématurés lorsque le besoin métier n’est pas encore totalement défini.
Le mouvement #NoEstimates
Initié par des experts de l’agilité comme Vasco Duarte, Woody Zuill ou des pionniers de l’Extreme Programming comme Kent Beck, le mouvement #NoEstimates part d’un constat provocateur : l’estimation demande un temps considérable pour un retour sur investissement faible ou biaisé.
La philosophie de #NoEstimates consiste à découper systématiquement toutes les histoires du Product Backlog jusqu’à ce qu’elles atteignent une taille petite et relativement uniforme (réalisables en 1 à 2 jours). Une fois ce découpage fin maîtrisé, il n’est plus nécessaire d’estimer en Story Points : il suffit de compter le nombre d’éléments terminés par Sprint (le débit ou throughput) pour faire des prévisions fiables grâce à des approches statistiques ou probabilistes (comme les simulations de Monte Carlo). C’est une démarche très prisée des équipes pratiquant Kanban ou intégrant les principes du Lean management, où la documentation centralisée sur des bases de connaissances comme Confluence permet de fluidifier la gestion du flux de travail.
Pour aller plus loin : Livres recommandés
Si vous souhaitez approfondir le sujet de l’estimation et de la planification agile, voici deux ouvrages essentiels :
- Agile Estimating and Planning par Mike Cohn : Le livre de référence absolu pour maîtriser l’estimation relative, les Story Points et la planification d’itérations.
- Scrum : Un outil convivial pour une agilité radicale par Claude Aubry : Un guide complet et pragmatique en français pour appliquer Scrum et gérer son backlog au quotidien.
- #NoEstimates: How to Measure Project Progress Without Estimating par Vasco Duarte : Un ouvrage passionnant qui remet en question la culture du chiffrage et propose des alternatives concrètes fondées sur la mesure de la valeur livrée.
Et dans votre organisation, comment les estimations sont-elles perçues au quotidien ? Utilisez-vous les Story Points comme un simple outil d’alignement d’équipe, ou faites-vous face à une pression pour les convertir en heures ou en métriques de productivité ? Partagez vos retours d’expérience et vos questions dans les commentaires ci-dessous !
Photo : ThisIsEngineering sur Pexels.
Pour aller plus loin
Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.
Agile Estimating and Planning, Mike Cohn
Le livre fondateur qui a popularisé les Story Points, le Planning Poker et l’estimation relative pour la planification de projets agiles.
Un ouvrage francophone complet et pragmatique pour appréhender Scrum et la gestion du backlog au quotidien.
Une alternative provocatrice et documentée qui remet en question la nécessité même des estimations dans le développement logiciel.
Autres ressources sur l’agilité
- Les cérémonies Scrum : le guide complet pour rythmer vos Sprints
- Glossaire Scrum : tous les termes de l’agilité expliqués
- La Méthode Scrum
- Le scrum master : un rôle déterminant de l’agilité
- Les Méthodes Agiles
