Estimations Agile : le poker planning n'est pas là pour estimer
Le vrai intérêt du poker planning n'est pas l'estimation. C'est l'alignement de l'équipe sur ce qu'il y a à faire. Pourquoi et comment recentrer vos rituels d'estimation.
"Cette feature, c'est un 5 ou un 8 ?" Si vos poker plannings se résument à un débat sur les points de complexité, vous passez à côté de l'essentiel. Le chiffre qu'on met sur un ticket n'est pas l'objectif — c'est un prétexte pour aligner l'équipe.
Les estimations alimentent la construction de votre roadmap. Mais elles n'en sont qu'une brique — et pas la plus importante.
Ce qu'on croit faire vs ce qu'on fait vraiment
| Ce qu'on croit | Ce qui se passe réellement |
|---|---|
| Estimer la durée d'une feature | Découvrir que chacun a compris la feature différemment |
| Prédire la vélocité du sprint | Identifier les zones d'ombre et les risques techniques |
| Alimenter un planning projet | Forcer une conversation entre dev, produit et design |
| Mesurer la productivité de l'équipe | Créer un moment où tout le monde peut poser des questions |
La magie du poker planning, c'est le moment où deux développeurs sortent des cartes très différentes — un 2 et un 13 par exemple. Ce n'est pas un problème d'estimation. C'est la preuve qu'ils n'ont pas la même vision de ce qu'il faut faire. Et c'est cette conversation-là qui a de la valeur.
L'estimation a déjà eu lieu (et c'est normal)
Voici ce que beaucoup de guides Agile ne disent pas : quand une feature arrive en poker planning, l'essentiel du travail d'estimation est déjà fait.
Avant d'arriver devant l'équipe, une feature a traversé plusieurs étapes :
- Idéation produit : le CPO ou le Product Manager a identifié le besoin et l'a priorisé
- Design : un designer a exploré les parcours utilisateurs, produit des maquettes
- Cadrage technique : un dev senior, un lead ou le CTO a fait un premier t-shirt sizing (S, M, L, XL) pour valider que la feature est réaliste dans le contexte actuel
- Arbitrage roadmap : la feature a été retenue par rapport à d'autres, souvent sur la base de ce t-shirt sizing
Quand une feature arrive en poker planning, on a déjà investi des jours — voire des semaines — de travail produit et design dessus. La question "est-ce que c'est faisable dans un temps raisonnable ?" a déjà été traitée en amont. Si la réponse avait été non, la feature n'aurait jamais atteint ce stade.
Le poker planning n'est donc pas le moment de la faisabilité. C'est le moment de la compréhension partagée.
Ce que révèle un bon poker planning
Les incompréhensions sur le périmètre
"Attends, on doit gérer le cas mobile aussi ?" — "Il faut migrer les données existantes ou on part de zéro ?" — "Le design final, c'est celui-là ou l'autre version ?"
Ces questions surgissent systématiquement quand on confronte l'équipe à une estimation. Et c'est précisément le but. Mieux vaut découvrir un malentendu sur le périmètre avant de commencer à coder que deux jours après.
Les risques techniques que personne n'avait vus
Le dev back-end qui dit "ça va toucher le système de permissions, c'est plus complexe que prévu". Le dev front qui signale une incompatibilité avec le composant existant. Ces alertes ne remontent que quand on force chacun à se projeter concrètement dans l'implémentation.
Les dépendances cachées
"Pour faire ça, il faut d'abord que l'API de paiement soit migrée." Le poker planning est souvent le premier moment où ces dépendances sont verbalisées devant toute l'équipe — pas dans un Slack entre deux personnes.
Pourquoi le chiffre compte moins qu'on ne le croit
Beaucoup d'organisations passent un temps considérable à transformer les points de complexité en jours, puis en dates de livraison. C'est un exercice rassurant, mais souvent trompeur.
La vélocité n'est pas une métrique de productivité
"L'équipe a fait 42 points ce sprint, contre 38 la semaine dernière." Qu'est-ce que ça veut dire concrètement ? Pas grand-chose. Les points sont relatifs, subjectifs, et leur signification évolue avec la composition de l'équipe et la nature des sujets.
Utiliser la vélocité pour mesurer la productivité est une dérive courante. Son seul usage légitime est d'aider l'équipe à calibrer la quantité de travail qu'elle peut absorber sur un sprint — et même là, c'est une approximation.
L'illusion de la précision
Estimer en demi-journées, en heures, en story points avec une suite de Fibonacci — le format change, mais le problème reste le même : personne ne sait estimer avec précision un travail créatif et complexe. La recherche sur le sujet est assez unanime là-dessus.
Ce qui ne veut pas dire qu'il faut arrêter d'estimer. Mais il faut accepter que l'estimation est un outil de conversation, pas un engagement contractuel.
Comment tirer le meilleur de vos poker plannings
Recentrer sur le "pourquoi" avant le "combien"
Avant de sortir les cartes, le Product Owner devrait répondre à ces questions :
- Quel problème utilisateur résout-on ?
- Comment saurons-nous que c'est réussi ?
- Quels compromis sont acceptables ?
Si l'équipe ne comprend pas le "pourquoi", l'estimation sera mécaniquement fausse — parce que chacun estimera une feature différente dans sa tête.
Valoriser les écarts, pas le consensus
Le réflexe naturel est de converger rapidement vers un chiffre moyen. Résistez. Un écart de plus de 3 points entre deux estimations est un signal précieux. Prenez le temps de comprendre pourquoi : c'est là que se cachent les malentendus et les risques.
Limiter le temps par ticket
Si un ticket prend plus de 5 minutes de discussion en poker planning, c'est qu'il n'est pas assez bien défini. Plutôt que de débattre indéfiniment, renvoyez-le en affinage avec les bonnes personnes. Le poker planning n'est pas un atelier de spécification.
Garder le t-shirt sizing pour les décisions stratégiques
Le t-shirt sizing (S, M, L, XL) fait par un dev expérimenté ou le CTO reste l'outil le plus efficace pour les décisions de priorisation en amont. C'est rapide, ça donne un ordre de grandeur suffisant, et ça ne mobilise pas toute l'équipe.
Réservez le poker planning pour le moment où l'équipe doit s'aligner sur comment elle va implémenter — pas pour décider si on le fait.
Le vrai livrable d'un poker planning
À la fin d'un bon poker planning, ce qui compte n'est pas la colonne "points" dans votre outil de ticketing. C'est que chaque membre de l'équipe puisse répondre à ces questions :
- Qu'est-ce qu'on construit ? (périmètre clair et partagé)
- Pourquoi on le construit ? (valeur utilisateur comprise)
- Quels sont les risques ? (identifiés et verbalisés)
- Qui fait quoi ? (dépendances et responsabilités claires)
Si votre équipe sort du poker planning avec ça, peu importe que le ticket soit à 5 ou à 8 points. L'alignement est fait, et c'est ça qui détermine la qualité et la rapidité de l'exécution.
En coaching CTO ou en accompagnement scaling, je vous aide à transformer vos cérémonies Agile en vrais moments de décision — pas en cases à cocher.