Le Product Backlog de StockPro est ordonné, ses éléments du haut sont affinés. Vient la question qui crispe toutes les équipes : « combien de temps ça va prendre ? » Donner une date en heures pour un travail qu’on n’a jamais fait, c’est inventer un chiffre rassurant et faux. L’estimation relative résout ce malaise en changeant la question : au lieu de « combien d’heures », on demande « est-ce plus gros ou plus petit que cette autre tâche ? ». À la fin de ce tutoriel, vous saurez animer une séance de planning poker, attribuer des story points cohérents, et vous servir de la vélocité pour faire des prévisions honnêtes.
À savoir d’emblée. Ni les story points, ni le planning poker, ni la vélocité ne figurent dans le Guide Scrum 2020. Le cadre laisse l’équipe libre de sa technique d’estimation. Ce sont des pratiques complémentaires, nées de la communauté Agile, que beaucoup d’équipes Scrum adoptent — mais elles ne sont pas obligatoires.
Ce que vous allez apprendre
- Pourquoi estimer en taille relative plutôt qu’en heures.
- Ce qu’est un story point et comment fixer une référence d’équipe.
- Animer une séance de planning poker de bout en bout.
- Calculer et utiliser la vélocité pour prévoir sans sur-promettre.
Ce que vous allez construire
Vous repartirez avec les éléments du haut du backlog StockPro estimés en story points, une story de référence partagée par l’équipe, et une première vélocité prévisionnelle qui vous dira combien de points l’équipe peut raisonnablement viser par Sprint.
Prérequis
- Un Product Backlog affiné — voir Rédiger et prioriser le Product Backlog.
- Toute l’équipe des Developers présente (l’estimation est un acte collectif).
- Un jeu de cartes de planning poker, physique ou en ligne ; à défaut, des papiers numérotés.
- Niveau : débutant. Durée estimée : 40 minutes pour une première séance.
Étape 1 — Comprendre l’estimation relative
Notre cerveau est mauvais pour dire « cette tâche prendra 7 heures », mais excellent pour dire « cette tâche est à peu près deux fois plus grosse que celle-là ». L’estimation relative exploite cette force. Un story point est une unité sans dimension qui exprime la taille d’un élément — un mélange d’effort, de complexité et d’incertitude — comparée aux autres éléments. Ce n’est pas une durée. Une story à 2 points est censée être environ deux fois « plus grosse » qu’une story à 1 point, pas « deux heures ».
L’avantage est double. D’abord, la taille relative est plus stable que le temps : deux développeurs d’un niveau différent ne mettront pas le même nombre d’heures, mais s’accorderont souvent sur le fait qu’une tâche est « deux fois plus grosse » qu’une autre. Ensuite, on estime vite : comparer est plus rapide que décortiquer un planning.
✅ Point d’étape. Si quelqu’un demande « ça fait combien d’heures, un point ? », la bonne réponse est « aucune valeur fixe ». Convertir des points en heures détruit l’intérêt de la méthode ; on y reviendra dans les pièges.
Étape 2 — Choisir une échelle et une référence
Le planning poker utilise une suite de Fibonacci modifiée : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Les écarts grandissent à mesure qu’on monte, ce qui reflète une vérité : plus une tâche est grosse, moins on sait l’estimer finement. Il serait absurde de débattre entre 21 et 22 ; la suite vous force à choisir entre 20 et 40, ce qui est honnête. Trois cartes spéciales complètent souvent le jeu : le « ? » (je ne sais pas), l’infini (trop gros pour être estimé, à découper) et une tasse de café (pause).
Cartes : 0 1/2 1 2 3 5 8 13 20 40 100 ? (infini)Avant de voter, fixez une référence. Choisissez ensemble une story de taille moyenne, bien comprise, et déclarez-la « 3 points ». Toutes les autres seront jugées par rapport à elle. Pour StockPro, « consulter le stock d’un article » fait une bonne référence à 3 : ni triviale, ni énorme. Cette story-étalon ancre toute l’échelle de l’équipe.
Étape 3 — Animer une séance de planning poker
Le planning poker a été défini et nommé par James Grenning en 2002, puis popularisé par Mike Cohn dans son ouvrage sur l’estimation Agile. L’idée est de faire estimer chacun simultanément pour éviter que l’avis du plus ancien n’écrase les autres. Le déroulé d’un tour, story par story :
- Le Product Owner lit la story et ses critères d’acceptation, puis répond aux questions.
- Chaque Developer choisit en silence une carte, face cachée.
- Tout le monde retourne sa carte en même temps.
- Si les valeurs convergent, on retient le consensus et on passe à la suivante.
- Si elles divergent — par exemple un 2 et un 13 — on ne fait pas la moyenne ! On demande aux deux extrêmes d’expliquer leur raisonnement. Souvent, l’un a vu une difficulté que les autres ignoraient.
- On revote après discussion, jusqu’à convergence raisonnable.
Ce protocole transforme l’estimation en conversation. Le 13 du testeur révèle peut-être que la story « ajouter plusieurs articles à une vente » cache une gestion d’erreurs que personne n’avait anticipée. La valeur du planning poker n’est pas le chiffre final : c’est l’alignement de compréhension qu’il provoque.
✅ Point d’étape. Après deux ou trois stories estimées, vérifiez la cohérence : une story notée 8 doit « sembler » nettement plus grosse qu’une story notée 3. Si ce n’est pas le cas, rediscutez l’une des deux.
Étape 4 — Calculer et utiliser la vélocité
Une fois plusieurs Sprints derrière vous, additionnez les points des éléments réellement terminés (conformes à la Definition of Done) à chaque Sprint. La moyenne de ces totaux est votre vélocité : le nombre de points que l’équipe boucle typiquement par Sprint. Si StockPro termine 18, puis 22, puis 20 points, sa vélocité tourne autour de 20.
La vélocité sert à prévoir, pas à juger. Si le haut du backlog représente 80 points et que l’équipe boucle 20 points par Sprint, on peut annoncer prudemment « environ quatre Sprints » — une fourchette, pas une promesse au jour près. C’est infiniment plus honnête qu’un planning en heures inventé au départ.
Attention : la vélocité est propre à une équipe. Les 20 points de StockPro n’ont aucun rapport avec les 20 points d’une autre équipe ; comparer les vélocités entre équipes n’a pas de sens et pousse à gonfler les estimations. La vélocité se construit sur quelques Sprints ; au tout début, elle est forcément approximative.
Disséquer un story point : trois dimensions
Dire qu’un point mélange « effort, complexité et incertitude » reste abstrait tant qu’on ne sépare pas ces trois ingrédients. Les confondre est la source la plus fréquente d’estimations incohérentes, alors prenons le temps de les distinguer sur des exemples de StockPro.
L’effort est la quantité brute de travail. Saisir cinquante libellés d’articles est long mais simple : beaucoup d’effort, peu de complexité. La complexité est la difficulté intellectuelle : calculer un stock disponible en tenant compte des ventes en cours, des retours et des réapprovisionnements est délicat même si le code final est court. L’incertitude est ce qu’on ignore : brancher l’application sur une imprimante de tickets qu’on n’a jamais utilisée est risqué — on ne sait pas ce qui nous attend.
Une story peut être grosse pour n’importe laquelle de ces raisons. « Importer le catalogue existant depuis un vieux fichier » est typiquement faible en complexité mais forte en incertitude (dans quel état est le fichier ?). C’est précisément ce que le planning poker fait remonter : quand un membre vote haut « à cause du risque » et un autre bas « parce que le code est trivial », la discussion révèle que la vraie question est l’incertitude, qu’il faudra peut-être lever par une petite exploration avant d’estimer.
Exemple : le haut du backlog StockPro estimé
Voici à quoi ressemble une première passe d’estimation sur les éléments affinés, une fois la story de référence fixée à 3. Lisez la colonne « pourquoi » autant que le chiffre : c’est elle qui rend l’estimation défendable.
| Élément | Points | Pourquoi ce chiffre |
|---|---|---|
| Consulter le stock d’un article (référence) | 3 | Étalon de l’équipe : bien compris, taille moyenne |
| Enregistrer une vente simple | 5 | Un peu plus gros : saisie, validation, écriture en base |
| Décrémenter le stock après une vente | 2 | Logique courte une fois la vente en place |
| Ajouter plusieurs articles à une vente | 8 | Gestion d’un panier, cas d’erreurs, quantités |
| Alerter quand un article passe sous un seuil | 3 | Comparable à la référence : un calcul et un affichage |
| Importer le catalogue depuis l’ancien fichier | 13 | Forte incertitude sur l’état des données |
Total des éléments prêts (hors import incertain) : 21 points. Si la vélocité prévisionnelle de l’équipe est de 20, on devine déjà qu’un premier Sprint n’avalera pas tout : il faudra choisir. C’est exactement la conversation qu’ouvre le Sprint Planning.
Pièges fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| « 1 point = 4 heures », le planning redevient du temps | Conversion points → heures | Garder les points abstraits ; prévoir avec la vélocité, pas une règle de trois |
| Le plus ancien impose toujours son chiffre | Votes non simultanés | Révéler les cartes en même temps, faire parler les extrêmes |
| On débat dix minutes entre 20 et 21 | Échelle trop fine en haut | S’en tenir à la suite de Fibonacci modifiée |
| La vélocité d’une équipe sert à en juger une autre | Comparaison inter-équipes | La vélocité est interne ; ne jamais comparer entre équipes |
| Tout est estimé à 8 ou plus | Pas de story de référence | Fixer une story-étalon à 3 avant de voter |
Récapitulatif
Vous savez maintenant pourquoi l’estimation relative bat l’estimation en heures : elle s’appuie sur ce que le cerveau fait bien, comparer des tailles. Le story point mesure cette taille relative ; la suite de Fibonacci modifiée encode l’incertitude croissante ; le planning poker transforme l’estimation en conversation d’équipe avec révélation simultanée ; et la vélocité, calculée sur plusieurs Sprints, permet des prévisions prudentes. Gardez en tête que tout cela complète Scrum sans en faire partie : c’est un outil au service de l’équipe StockPro, pas une obligation du cadre.
Aide-mémoire
| Notion | L’essentiel |
|---|---|
| Story point | Taille relative (effort + complexité + incertitude), pas une durée |
| Échelle | Fibonacci modifiée : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 |
| Référence | Une story moyenne déclarée « 3 » qui ancre l’échelle |
| Planning poker | Vote simultané, discussion des extrêmes, revote |
| Vélocité | Points terminés/Sprint en moyenne ; sert à prévoir, propre à l’équipe |
À vous de jouer
Lors du vote sur « exporter les ventes du mois », l’équipe affiche : 3, 3, 2 et… 40. Que faites-vous ?
Voir une solution
On ne fait surtout pas la moyenne. On demande à la personne qui a voté 40 d’expliquer : elle a peut-être identifié que l’export doit gérer plusieurs formats, des milliers de lignes, ou une compatibilité comptable précise — autant de complexité invisible pour les autres. Soit l’équipe découvre une vraie difficulté et la story est en réalité grosse (et mérite d’être découpée), soit c’est un malentendu qui se dissipe et l’on revote autour de 3. Dans les deux cas, l’écart a fait émerger une information : c’est exactement le but.
Tutoriels frères
- Préparer et animer le Sprint Planning — utiliser ces estimations pour décider du contenu d’un Sprint.
- Daily Scrum et burndown — suivre la consommation des points en cours de Sprint.
Ressources
- Vue d’ensemble : Scrum, le cadre Agile pour livrer un produit en équipe.
- Le Guide Scrum 2020 — rappel : il n’impose aucune technique d’estimation.
FAQ
Story points ou heures ?
Les points pour la taille relative et la prévision ; ils évitent les fausses précisions. Certaines équipes matures reviennent à des comptages de tâches, mais convertir des points en heures fait perdre tout le bénéfice de l’abstraction.
Faut-il absolument du planning poker ?
Non. C’est une méthode parmi d’autres (T-shirt sizing, affinity estimation…). Scrum n’en exige aucune. Le planning poker reste populaire parce qu’il fait parler toute l’équipe.
Que vaut la vélocité au premier Sprint ?
Peu de chose. Elle se fiabilise sur trois à quatre Sprints. Au départ, prenez une estimation prudente et ajustez ensuite.
Peut-on estimer en équipe à distance ?
Oui. Des outils en ligne gratuits reproduisent le vote simultané à cartes cachées ; l’essentiel est de préserver la simultanéité et la discussion des écarts.