Planning Poker, T-Shirt Sizing, estimation par affinité ou pas d'estimation du tout ? Un comparatif pratique de toutes les méthodes utilisées en sprint planning.
Pourquoi estimer ?
L'estimation en agile ne vise pas à prédire l'avenir. Comme le souligne le Scrum Guide, l'objectif est d'aider l'équipe à planifier ses sprints, révéler l'incertitude et avoir de meilleures conversations sur le travail à venir.
Une bonne estimation répond à la question : "Combien pouvons-nous raisonnablement livrer dans les deux prochaines semaines ?" Sans estimation, le sprint planning devient un exercice de devinette, et l'équipe soit s'engage trop (burnout et sprints incomplets), soit pas assez (capacité gaspillée).
Les méthodes comparées
1. Planning Poker (Fibonacci)
La technique la plus populaire dans les équipes Scrum à travers le monde.
Comment ça marche : chaque membre de l'équipe choisit simultanément une carte de l'échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21) représentant son estimation de l'effort relatif d'une story. Les cartes sont révélées en même temps. Les divergences déclenchent une discussion, puis l'équipe revote jusqu'au consensus.
Idéal pour : sprint planning avec 10-20 stories. Produit des estimations de haute qualité grâce à la discussion structurée.
Forces :
- Élimine le biais d'ancrage par la révélation simultanée
- Force la discussion sur les estimations divergentes, révélant la complexité cachée
- Les écarts Fibonacci reflètent l'incertitude du monde réel (voir pourquoi Fibonacci fonctionne)
- Crée une compréhension partagée de chaque story dans l'équipe
Faiblesses :
- Prend 1-3 minutes par story
- Nécessite la présence de toute l'équipe
- Rendements décroissants au-delà de 20 stories par session
Quand l'utiliser : chaque fois que vous avez besoin d'estimations fiables pour les stories qui entrent dans le prochain sprint.
Essayez Planning Poker maintenant.
2. T-Shirt Sizing (XS à XXL)
Une alternative plus simple et plus rapide qui échange la précision contre la vitesse.
Comment ça marche : l'équipe classe les stories dans des catégories de taille : XS, S, M, L, XL, XXL. Pas de valeurs numériques, juste des catégories relatives.
Idéal pour : planification de roadmap, refinement de backlog avec 30+ stories, estimation en phase initiale quand la précision n'est pas encore nécessaire.
Forces :
- Très rapide (30 secondes par story)
- Intuitif pour les stakeholders non techniques
- Faible charge cognitive
- Bon point de départ avant de passer à Fibonacci pour la précision sprint
Faiblesses :
- Pas assez précis pour la planification de capacité sprint
- Difficile de calculer la vélocité sans valeurs numériques
- La frontière entre les tailles est subjective
Quand l'utiliser : planification trimestrielle, estimation initiale de backlog, ou quand l'équipe débute en agile.
Lisez notre guide détaillé du T-Shirt Sizing et notre comparatif Fibonacci vs T-Shirt Sizing.
3. Estimation par affinité (wall estimation)
Une technique rapide pour estimer de gros backlogs d'un coup.
Comment ça marche : les stories sont imprimées sur des cartes ou post-its. L'équipe les place silencieusement sur un mur ou un board de gauche (petit) à droite (grand), en les positionnant les unes par rapport aux autres. Une fois toutes les stories placées, l'équipe trace des lignes verticales pour créer des catégories (1, 2, 3, 5, 8, 13...) et assigne des valeurs.
Idéal pour : estimation initiale d'un tout nouveau backlog de 30-100 stories.
Forces :
- Peut estimer 50+ stories en moins d'une heure
- Visuel et collaboratif
- Le positionnement relatif est intuitif
- Bon pour former un modèle mental partagé du backlog
Faiblesses :
- Nécessite la présence physique (ou un tableau numérique comme Miro)
- Moins de discussion par story que le Planning Poker
- Estimations plus grossières
Quand l'utiliser : lancements de projet, restructuration majeure de backlog, ou quand l'équipe hérite d'un gros backlog existant.
4. Bucket system
Une variante de l'estimation par affinité conçue pour les très gros backlogs.
Comment ça marche : créez des "seaux" étiquetés avec des valeurs Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100). Chaque membre de l'équipe prend des stories du tas et les dépose dans le seau qui lui semble correspondre. Après que toutes les stories sont placées, l'équipe examine et discute des stories dans les très grands seaux ou celles placées dans des seaux différents par différentes personnes.
Idéal pour : estimer 50-200 stories rapidement.
Forces :
- Extrêmement rapide pour de grands volumes
- Peut être fait avec des équipes distribuées en utilisant des outils numériques
- Monte bien en échelle
Faiblesses :
- Moins de discussion par story
- Nécessite des stories bien rédigées et auto-explicatives
- Estimations grossières
Quand l'utiliser : découverte de grands projets, estimation au niveau portfolio.
5. Dot voting
Pas une technique d'estimation à proprement parler, mais souvent confondue avec une.
Comment ça marche : chaque participant reçoit un nombre fixe de "points" (votes) à répartir entre les stories. Les stories avec le plus de points sont considérées comme les plus prioritaires.
Idéal pour : la priorisation, pas l'estimation de complexité.
Forces :
- Simple et démocratique
- Révèle rapidement les priorités de l'équipe
- Fonctionne bien avec les stakeholders non techniques
Faiblesses :
- Mesure l'importance perçue, pas l'effort
- Ne peut pas être utilisé pour la planification de capacité
- Risque de pensée de groupe (votes visibles)
Quand l'utiliser : ateliers de priorisation de backlog, sessions de vote sur les features.
6. Pas d'estimation (#NoEstimates)
Un mouvement qui questionne si l'estimation apporte de la valeur.
L'argument : au lieu d'estimer les stories, découpez chaque story à peu près à la même taille (1-2 jours de travail). Puis comptez le nombre de stories complétées par sprint. La vélocité devient "stories par sprint" au lieu de "points par sprint".
Idéal pour : équipes matures avec des tailles de stories cohérentes et une vélocité stable.
Forces :
- Élimine complètement le surcoût d'estimation
- Force les stories à être petites et bien définies
- Métriques plus simples
Faiblesses :
- Nécessite de la discipline dans le découpage des stories
- Difficile à appliquer aux stories de complexité variable
- Ne révèle pas la complexité cachée comme le Planning Poker le fait
- Moins applicable quand on communique avec des stakeholders qui attendent des prévisions de calendrier
Quand l'utiliser : uniquement quand l'équipe maîtrise le découpage cohérent de stories et a une cadence de livraison stable.
Matrice de comparaison
| Méthode | Vitesse | Précision | Taille d'équipe | Taille de backlog idéale | Qualité de discussion |
|---|---|---|---|---|---|
| Planning Poker | Moyenne | Haute | 3-9 | 10-20 stories | Excellente |
| T-Shirt Sizing | Rapide | Basse | N'importe | 20-50 stories | Basse |
| Estimation par affinité | Rapide | Moyenne | 3-12 | 30-100 stories | Moyenne |
| Bucket System | Très rapide | Basse-Moyenne | N'importe | 50-200 stories | Basse |
| Dot Voting | Rapide | N/A (priorité) | N'importe | 10-30 stories | Basse |
| #NoEstimates | N/A | N/A | Petite | N'importe | Aucune (par design) |
Choisir la bonne technique
Utilisez cet arbre de décision :
- Vous avez besoin d'estimations précises pour le prochain sprint ? Utilisez Planning Poker.
- Vous avez besoin d'un sizing grossier pour une roadmap ? Utilisez T-Shirt Sizing.
- Vous avez un gros nouveau backlog à estimer ? Utilisez l'estimation par affinité ou le Bucket System d'abord, puis affinez avec Planning Poker pour les items prioritaires.
- Vous avez juste besoin de prioriser ? Utilisez Dot Voting.
- Votre équipe livre régulièrement des stories petites et uniformes ? Envisagez #NoEstimates.
La plupart des équipes utilisent une combinaison : T-Shirt Sizing pour la roadmap, Planning Poker pour le sprint planning, et de l'estimation par affinité occasionnelle pour les restructurations de backlog.
Qu'est-ce qui fait une "bonne" estimation ?
Une bonne estimation n'est pas une prédiction exacte. C'est un catalyseur pour de meilleures conversations. Une estimation est "bonne" quand :
- L'équipe s'accorde sur ce que la story implique (compréhension partagée)
- La complexité cachée a été révélée (réduction du risque)
- L'équipe peut planifier un sprint réaliste (gestion de la capacité)
- Les stakeholders peuvent prévoir les délais de livraison (gestion des attentes)
Le nombre sur la carte compte moins que la conversation qui l'a produit.
Pièges communs à toutes les méthodes
Confondre effort et durée. Les story points mesurent la complexité relative, pas le temps calendaire. Une story à 5 points n'est pas "5 jours".
Comparer la vélocité entre équipes. Le "5" de l'équipe A et le "5" de l'équipe B ne sont pas les mêmes. La vélocité est une métrique interne à l'équipe, pas un benchmark inter-équipes.
Estimer trop tôt. Estimer des stories vagues ou à des mois de l'implémentation est du gaspillage. Estimez quand la story est affinée et approche du sprint.
Ignorer la carte "?". Quand quelqu'un signale qu'il ne peut pas estimer, la story a besoin de plus d'informations. Ne forcez pas un chiffre.
Re-estimer les stories terminées. Une fois une story terminée, son estimation est une donnée historique. Ne la changez pas rétroactivement pour correspondre au réel. Utilisez l'écart pour améliorer les futures estimations.
Commencez à estimer avec votre équipe
Prêt à essayer la technique d'estimation la plus populaire ? Créez une session Planning Poker gratuite et estimez votre prochain sprint en quelques minutes. Sans inscription, sans configuration, juste un lien à partager.
