Le Planning Poker Qui Tourne Mal
Lundi matin, réunion de sprint planning.
Product Owner : « On va estimer la feature « Notifications Push ». »
L’équipe sort les cartes planning poker.
Développeur 1 : « Je pense que c’est un 5. »
Développeur 2 : « Non, c’est clairement un 8. Il y a la gestion des permissions iOS, Android, web… »
Développeur 3 : « Attendez, on compte juste le backend ou aussi le frontend ? »
Dev 1 : « Euh… les deux ? »
Dev 2 : « Dans ce cas c’est un 13. »
20 minutes de débat.
Product Owner : « Ok, on valide à 8 points. »
Six semaines plus tard.
Product Owner : « Pourquoi les notifications ne sont pas finies ? On avait estimé 8 points. »
Développeur 1 : « Oui mais 8 points c’est pas 8 jours. En vrai on a passé 3 semaines dessus. »
Product Owner : « Mais… à quoi servent les points alors ? »
Silence gêné.
Le Problème Fondamental Des Story Points
Les story points (points de complexité) sont une abstraction inventée par les méthodologies Agiles pour estimer le travail sans parler de temps.
L’Illusion de l’Abstraction
La Promesse :
« Les points mesurent la complexité, pas le temps. Ça évite la pression du management sur les délais. »
La Réalité :
- Personne ne sait ce qu’un « 5 » représente concrètement
- Chaque équipe a sa propre échelle (un 5 chez l’équipe A ≠ 5 chez l’équipe B)
- Les points changent avec le turnover (nouveau dev = recalibration complète)
- Le management finit toujours par convertir les points en temps (« votre vélocité est de 40 points/sprint, donc 10 jours »)
Résultat : Vous créez une couche d’abstraction inutile qui masque la réalité.
Les Quatre Mensonges Des Story Points
Mensonge 1 : « Les Points Évitent La Pression Sur Les Délais »
Faux.
Le management convertira toujours les points en temps :
- « Vous faites 40 points par sprint de 2 semaines. »
- « Donc 1 point = 0,25 jour. »
- « Cette feature fait 20 points, donc 5 jours. »
Vous avez juste ajouté une étape de conversion.
Au lieu de dire directement « 5 jours », vous dites « 20 points » qui se transforment en « 5 jours » dans la tête de tout le monde.
Mensonge 2 : « Les Points Mesurent La Complexité, Pas Le Temps »
Faux.
Lors du planning poker, l’équipe pense toujours en temps :
- « C’est un 5 » = « Ça va prendre environ 2-3 jours »
- « C’est un 13 » = « Ça va prendre une semaine complète »
Personne ne pense en “unités de complexité abstraite”.
Les développeurs convertissent mentalement les points en temps, puis vous reconvertissez les points en temps pour faire la planification.
Pourquoi ne pas simplement estimer en temps dès le départ ?
Mensonge 3 : « Les Points Permettent De Comparer Les Issues »
Faux.
Les points créent une fausse comparabilité :
- « Cette issue est un 5, donc elle est moitié moins complexe qu’un 10. »
Mais en réalité :
- Un 5 peut prendre 1 jour (feature simple bien définie)
- Un autre 5 peut prendre 5 jours (feature « simple » mais avec dépendances cachées)
Les points ne garantissent aucune cohérence.
Mensonge 4 : « Les Points S’Ajustent Automatiquement Avec L’Expérience »
Faux.
À chaque nouveau membre d’équipe :
- Recalibration des points
- « Attends, pour toi un 5 c’est quoi ? »
- Nouvelles sessions de planning poker pour aligner l’équipe
Les points dépendent de la composition actuelle de l’équipe.
Quand quelqu’un part ou arrive, toute votre échelle devient invalide.
Pourquoi Sinra Utilise Le Temps (En Jours)
Chez Sinra, nous avons abandonné les story points pour une approche plus simple et plus honnête : estimer en jours.
Le Temps Force À Confronter La Réalité
Estimation en points :
« Cette feature fait 8 points. »
Question : Combien de temps ça prend ? Réponse : « Ça dépend de la vélocité, de l’équipe, du sprint… »
Estimation en temps :
« Cette feature prendra 3 jours. »
Question : Combien de temps ça prend ? Réponse : « 3 jours. »
Bénéfice : Pas d’abstraction. Pas de conversion mentale. Vous confrontez directement votre estimation à la réalité.
Le Temps Révèle Les Features Mal Décomposées
Règle Sinra : Si vous ne pouvez pas estimer une issue en jours, c’est qu’elle est trop grosse.
Scénario typique :
Développeur : « Je ne peux pas estimer ça. C’est entre 5 et 15 jours. »
Product Owner : « Pourquoi cette incertitude ? »
Développeur : « Parce qu’il y a 10 choses différentes dans cette issue : backend, frontend, tests, migration de données, documentation… »
Solution Sinra : Décomposez.
Créez 5 issues séparées :
- Backend API : 2 jours
- Frontend UI : 1,5 jours
- Tests automatisés : 1 jour
- Migration données : 3 jours
- Documentation : 0,5 jour
Total : 8 jours (avec une visibilité claire sur chaque composant)
Résultat :
- ✅ Estimations précises
- ✅ Suivi granulaire
- ✅ Identification des blocages rapides
Le Temps Permet La Gestion De Charge Réelle
Avec les points :
- « Marc a 20 points à faire ce sprint. »
- Mais combien d’heures ça représente ? Vous ne savez pas.
Avec le temps (Sinra) :
- « Marc a 6 jours de travail assignés ce sprint (10 jours ouvrés). »
- Il reste 4 jours pour bugs, réunions, imprévus.
Bénéfice : Vous savez exactement combien de capacité chaque développeur a, en unités concrètes.
Vous pouvez :
- ✅ Équilibrer la charge entre développeurs
- ✅ Identifier les surcharges avant qu’elles deviennent des crises
- ✅ Faire des prévisions fiables (« À ce rythme, on livre dans 3 semaines »)
Le Temps Est Universel
Les points :
- L’équipe A estime en Fibonacci (1, 2, 3, 5, 8, 13…)
- L’équipe B estime en puissances de 2 (1, 2, 4, 8, 16…)
- Le management ne comprend rien
Le temps :
- Tout le monde comprend « 3 jours »
- Le CTO comprend
- Le CEO comprend
- Le client comprend
- L’équipe comprend
Bénéfice : Pas besoin d’expliquer votre système d’estimation. Le temps est une unité universelle.
Le Temps Force La Responsabilité
Avec les points :
« J’avais estimé 5 points, mais ça a pris plus de temps que prévu. »
Avec le temps :
« J’avais estimé 2 jours, mais ça m’a pris 4 jours. »
La différence est immédiate. Vous confrontez l’estimation au réel.
Quand vous estimez en jours :
- Vous êtes plus prudent (« 2 jours » sonne plus engageant que « 5 points »)
- Vous décomposez mieux (« 10 jours c’est trop, je dois découper »)
- Vous apprenez de vos erreurs (« J’ai sous-estimé de 100%, je vais ajuster »)
Résultat : Vos estimations s’améliorent avec le temps.
Le Temps Permet Des Prévisions Fiables
Avec les points :
- Vélocité sprint 1 : 35 points
- Vélocité sprint 2 : 42 points
- Vélocité sprint 3 : 28 points
Question : Quand on livre la feature de 60 points ? Réponse : « Ça dépend… entre 1,5 et 2,5 sprints ? »
Avec le temps (Sinra) :
- Sprint 1 : 7 jours livrés sur 10 planifiés (70% de capacité utilisée)
- Sprint 2 : 8 jours livrés sur 10 planifiés (80%)
- Sprint 3 : 6,5 jours livrés sur 10 planifiés (65%)
Moyenne : 72% de capacité utilisée
Feature estimée : 15 jours
Calcul prévision : 15 jours / 0,72 = 20,8 jours calendaires = 2,1 sprints
Bénéfice : Prévisions basées sur des données réelles et objectives.
Les Six Avantages Du Temps Sur La Complexité
1. Charge Exacte Et Visible
Points : Abstraction floue Temps : Unités concrètes
Vous savez exactement combien de jours de travail sont assignés à chaque personne.
2. Prévisions Fiables
Points : Conversion mentale aléatoire Temps : Calcul direct
« 15 jours estimés + 70% de capacité = 21 jours calendaires. »
3. Décomposition Forcée
Points : On peut estimer « 13 » sans décomposer Temps : « 10+ jours » force à découper
Si vous ne pouvez pas estimer en jours, décomposez.
4. Universalité
Points : Échelle d’équipe unique Temps : Compréhensible par tous
Le management, les clients, les stakeholders comprennent « 3 jours ».
5. Comparabilité
Points : Non comparable entre équipes Temps : Comparable partout
Vous pouvez comparer la vélocité entre projets et équipes (« équipe A livre 6j/sprint, équipe B livre 8j/sprint »).
6. Amélioration Continue
Points : Difficulté à mesurer l’amélioration Temps : Métriques claires
« Avant on estimait avec 50% d’erreur. Maintenant 20%. »
Objections Courantes (Et Réponses)
Objection 1 : « Le Temps Met Trop De Pression Sur L’Équipe »
Réponse : Non, les mauvaises estimations mettent de la pression.
Quand vous estimez en points :
- Vous créez une fausse impression de précision
- Le management convertit les points en temps de toute façon
- L’équipe est surprise quand la réalité ne correspond pas
Quand vous estimez en temps :
- Vous êtes honnête dès le départ
- Vous pouvez ajuster vos estimations avec l’expérience
- Vous confrontez les attentes à la réalité avant de commencer
La pression vient de la déconnexion entre attentes et réalité, pas de l’unité d’estimation.
Objection 2 : « Chaque Développeur Travaille À Un Rythme Différent »
Réponse : C’est vrai. Mais c’est aussi vrai avec les points.
Un développeur junior estimera « 5 points » pour une tâche qu’un senior fera en « 2 points ».
La différence avec le temps :
- Vous savez qui estime
- Vous pouvez ajuster selon le développeur assigné
- Vous pouvez mesurer l’amélioration individuelle
Avec Sinra :
- Marc (senior) estime 2 jours → prend 2,5 jours (125%)
- Sophie (mid) estime 2 jours → prend 3 jours (150%)
- Thomas (junior) estime 2 jours → prend 4 jours (200%)
Vous apprenez les coefficients de chacun et ajustez vos prévisions.
Objection 3 : « On Ne Peut Pas Estimer Précisément En Jours »
Réponse : C’est exactement le signal que l’issue est trop grosse.
Si vous dites :
« Je ne sais pas si c’est 2 jours ou 8 jours »
Alors décomposez.
Créez des issues plus petites :
- Backend : 1,5 jours
- Frontend : 2 jours
- Tests : 1 jour
- Intégration : 1,5 jours
Total : 6 jours (avec une meilleure visibilité)
Le temps force la décomposition. C’est une feature, pas un bug.
Objection 4 : « Les Story Points Évitent Les Débats Sur Les Délais »
Réponse : Non, ils reportent les débats.
Avec les points :
- Équipe estime 40 points
- Management demande « Ça prend combien de temps ? »
- Vous convertissez : « Environ 2 semaines »
- Management : « Pourquoi pas 1 semaine ? »
Avec le temps :
- Équipe estime 8 jours
- Management : « Pourquoi pas 4 jours ? »
- Vous expliquez : « Parce qu’il y a X, Y, Z à faire »
Le débat a lieu de toute façon. Autant être direct.
Objection 5 : « Les Points S’Ajustent Automatiquement Avec La Vélocité »
Réponse : Faux. La vélocité fluctue énormément.
Vélocité sprint 1 : 35 points Vélocité sprint 2 : 42 points (un dev était en vacances au sprint 1) Vélocité sprint 3 : 28 points (beaucoup de bugs en prod)
Les points ne s’ajustent pas. Vous devez manuellement recalibrer tout le temps.
Avec le temps :
- Sprint 1 : 7 jours livrés / 10 disponibles = 70%
- Sprint 2 : 8 jours livrés / 8 disponibles (1 dev en vacances) = 100%
- Sprint 3 : 6 jours livrés / 10 disponibles (bugs) = 60%
Moyenne : 77% de capacité effective
Vous pouvez mesurer objectivement votre capacité réelle.
Sinra En Action : Temps vs Complexité
Exemple Réel : Feature « Export PDF »
Approche Points (Avant Sinra)
Planning Poker :
- Équipe débat 30 minutes
- Estimation finale : 8 points
Livraison :
- Temps réel : 12 jours
- Pourquoi le retard ? « On avait sous-estimé la complexité du layout PDF. »
Rétrospective :
- « On devrait estimer plus large. »
- « Peut-être 13 points la prochaine fois ? »
Problème : Aucun apprentissage concret. Vous ajustez une abstraction.
Approche Temps (Avec Sinra)
Estimation initiale :
- Product Owner : « On estime combien pour l’export PDF ? »
- Développeur : « Je ne peux pas estimer ça en un bloc. Il faut découper. »
Décomposition :
- Générer PDF simple (texte) : 1,5 jours
- Ajouter images et layout : 2 jours
- Gérer les tableaux complexes : 2,5 jours
- Optimiser performance (gros documents) : 1,5 jours
- Tests et edge cases : 1,5 jour
Total estimé : 9 jours
Livraison :
- Temps réel : 11 jours
- Pourquoi le dépassement ? Le layout des tableaux a pris 3,5 jours au lieu de 2,5.
Rétrospective :
- « On sous-estime systématiquement les layouts complexes. »
- « Prochaine feature avec layout : ajouter +1 jour buffer. »
Bénéfice : Apprentissage concret et actionnable.
Les Trois Règles Sinra Pour Estimer En Temps
Règle 1 : Estimez En Jours (Pas En Heures)
Pourquoi ?
- Les heures donnent une fausse impression de précision
- Personne ne travaille 8h productives par jour (réunions, bugs, interruptions)
- Les jours sont plus faciles à communiquer
Granularité :
- 0,5 jour (demi-journée)
- 1 jour
- 1,5 jours
- 2 jours
- etc.
Évitez :
- « 3,75 jours » (trop précis, irréaliste)
- « 0,25 jour » (trop petit, créez une issue séparée)
Règle 2 : Si Vous Ne Pouvez Pas Estimer, Décomposez
Signal d’alerte :
« C’est entre 3 et 10 jours. »
Action : Décomposez en issues plus petites jusqu’à ce que l’incertitude disparaisse.
Objectif : Chaque issue doit être estimable avec ±50% de précision.
Exemple :
- ❌ « Implémenter notifications : 5-15 jours »
- ✅ « Backend API notifications : 2 jours »
- ✅ « Frontend UI notifications : 1,5 jours »
- ✅ « Notifications push mobile : 3 jours »
Règle 3 : Confrontez Vos Estimations Au Réel
Après chaque issue :
- Temps estimé : 2 jours
- Temps réel : 3,5 jours
- Écart : +75%
Action : Identifiez pourquoi.
- Dépendance imprévue ?
- Complexité sous-estimée ?
- Bugs bloquants ?
Ajustez vos estimations futures en conséquence.
Résultat : Vos estimations s’améliorent sprint après sprint.
Comparaison : Planning Poker vs Estimation Temps Sinra
| Aspect | Planning Poker (Story Points) | Estimation Temps (Sinra) |
|---|---|---|
| Unité | Points abstraits (1, 2, 3, 5, 8, 13…) | Jours (0,5j, 1j, 1,5j, 2j…) |
| Compréhension | Nécessite calibration d’équipe | Universel, immédiatement compris |
| Conversion | Points → temps (mental ou explicite) | Déjà en temps |
| Gestion charge | Abstrait (« 20 points ce sprint ») | Concret (« 8 jours sur 10 disponibles ») |
| Prévisions | Basées sur vélocité fluctuante | Basées sur capacité réelle |
| Décomposition | Peut rester vague (« 13 points ») | Force décomposition (« 10+ jours = trop gros ») |
| Comparabilité | Non comparable entre équipes | Comparable universellement |
| Turnover | Recalibration complète nécessaire | Impact minimal |
| Amélioration | Difficile à mesurer | Métriques claires (% erreur) |
| Transparence | Opaque pour stakeholders | Transparente pour tous |
Les Cinq Signes Que Vous Devriez Abandonner Les Story Points
Signe 1 : Vous Convertissez Systématiquement Les Points En Temps
Si votre processus ressemble à :
- Estimer en points
- Multiplier par votre « coefficient » pour obtenir des jours
- Utiliser les jours pour planifier
Vous perdez votre temps. Estimez directement en jours.
Signe 2 : Le Planning Poker Dure Plus De 5 Minutes Par Issue
Si chaque estimation déclenche un débat de 20 minutes (« C’est un 5 ou un 8 ? »), vous optimisez la mauvaise métrique.
Le but n’est pas d’avoir l’estimation parfaite. C’est d’avoir une estimation utilisable.
Signe 3 : Vos Prévisions Sont Toujours Fausses
Si vous dites régulièrement :
« On pensait livrer dans 2 sprints, finalement ça a pris 4 sprints »
Vos estimations en points ne vous aident pas à prévoir.
Signe 4 : Les Stakeholders Ne Comprennent Pas Votre Vélocité
Si le management vous demande constamment :
« Votre vélocité est de 40 points/sprint. Ça veut dire quoi concrètement ? »
Vous avez créé une abstraction inutile.
Signe 5 : Chaque Nouveau Membre Bouleverse Votre Échelle
Si l’arrivée d’un développeur junior ou senior force à recalibrer tous vos points, votre système d’estimation n’est pas robuste.
Exemple Réel : TechFlow Passe Aux Estimations Temps
TechFlow (équipe de 15 personnes, plateforme marketing automation)
Note : TechFlow est une entreprise réelle que nous avons anonymisée sous un nom fictif pour protéger leur confidentialité.
Avant Sinra : Story Points Et Planning Poker
Problèmes :
- Planning poker : 45 minutes par sprint pour estimer 10-15 issues
- Vélocité fluctuante : 32-48 points par sprint (50% de variation)
- Prévisions fausses : 60% des releases livrées en retard
- Débats sans fin : « C’est un 5 ou un 8 ? »
- Turnover : Chaque nouveau dev nécessitait 2 sprints de recalibration
Incident Révélateur : Feature « API Webhooks » estimée à 13 points. Vélocité moyenne : 40 points/sprint. Prévision : « 1/3 de sprint = 3-4 jours. »
Réalité : 18 jours (3,5 semaines).
Pourquoi ? Les 13 points cachaient :
- 5 endpoints différents
- Gestion retry + queue
- Tests d’intégration complexes
- Documentation API
Personne ne savait ce que « 13 points » représentait réellement.
Après Sinra : Estimation En Temps
Changements :
- Abandon du planning poker
- Estimation directe en jours
- Décomposition forcée si >3 jours
- Suivi temps estimé vs temps réel
Feature « API Webhooks » (Version Temps) : Au lieu de « 13 points », décomposition :
- Endpoint création webhook : 1,5 jours
- Endpoint liste/update/delete : 1 jour
- Système de retry : 2 jours
- Queue management : 2,5 jours
- Tests intégration : 2 jours
- Documentation OpenAPI : 1 jour
Total estimé : 10 jours
Livraison réelle : 12 jours
Écart : +20% (au lieu de +350% avec les points)
Résultats (Après 6 Mois)
Avant (Story Points) :
- Temps planning poker : 45 min/sprint
- Fiabilité estimations : 40% (60% de retard)
- Vélocité : Fluctuante (32-48 points)
- Prévisions releases : Fausses 6 fois sur 10
Après (Temps) :
- Temps estimation : 15 min/sprint
- Fiabilité estimations : 75% (±25% d’erreur)
- Capacité : Stable (7-8 jours/sprint)
- Prévisions releases : Fiables 8 fois sur 10
Citation Lead Developer :
« Avant, on passait 45 minutes à débattre si c’était un 5 ou un 8. Maintenant, on dit “2 jours” et on passe à la suite. On a triplé notre efficacité de planning. »
Citation Product Manager :
« Avec les points, je ne savais jamais quand on allait livrer. Maintenant, je peux dire “dans 3 semaines” avec 80% de confiance. Les stakeholders adorent. »
Comment Passer Des Story Points Au Temps
Étape 1 : Analysez Vos Données Historiques
Action :
- Prenez vos 5 derniers sprints
- Pour chaque issue : points estimés vs temps réel
- Calculez votre ratio moyen (ex: 1 point = 0,5 jour)
Bénéfice : Vous avez une baseline de conversion.
Étape 2 : Annoncez Le Changement À L’Équipe
Communication :
« À partir du prochain sprint, on estime directement en jours plutôt qu’en points. Pourquoi ? Parce que ça nous permet de mieux planifier et d’avoir des prévisions fiables. »
Anticipez les objections : (voir section Objections ci-dessus)
Étape 3 : Estimez Votre Premier Sprint En Temps
Règles :
- Estimez en jours (0,5j, 1j, 1,5j, 2j…)
- Si >3 jours : décomposez
- Si incertitude >50% : décomposez
Exemple :
- Issue A : 1,5 jours
- Issue B : 2 jours
- Issue C : décomposée en C1 (1j) + C2 (1,5j) + C3 (0,5j)
Étape 4 : Suivez Estimé vs Réel
Après chaque issue :
- Temps estimé : X jours
- Temps réel : Y jours
- Écart : (Y - X) / X
Apprenez de vos erreurs :
- Quels types d’issues vous sous-estimez ?
- Quels développeurs ont besoin de coefficients d’ajustement ?
Étape 5 : Ajustez Progressivement
Sprint 1 : Erreur moyenne +40% Sprint 2 : Erreur moyenne +25% Sprint 3 : Erreur moyenne +15%
Vos estimations s’améliorent naturellement.
Points d’Action : Adopter L’Estimation Temps
- Calculez votre ratio actuel : 1 point = combien de jours ? (analysez 5 derniers sprints)
- Estimez votre prochain sprint en jours : abandonnez les points pour un sprint test
- Décomposez les grosses issues : si >3 jours d’estimation, coupez en issues plus petites
- Suivez estimé vs réel : mesurez vos écarts et apprenez
- Ajustez vos prévisions : utilisez votre % d’erreur moyen pour affiner les deadlines
Le Point Clé
Les story points créent une abstraction qui éloigne les équipes de la réalité.
Vous estimez en points, vous convertissez mentalement en temps, vous planifiez en temps, puis vous découvrez que la réalité ne correspond pas.
Le temps (en jours) confronte vos estimations au réel.
Pas d’abstraction. Pas de conversion. Pas de calibration d’équipe. Pas de débats interminables.
Juste une estimation honnête, vérifiable, et améliore avec l’expérience.
Résultat :
- ✅ Charge exacte et visible
- ✅ Prévisions fiables
- ✅ Décomposition forcée des features complexes
- ✅ Universalité (compris par tous)
- ✅ Amélioration continue mesurable
Le temps ne ment pas. Les story points, si.
Prêt à abandonner les story points et planifier avec des données réelles ? Démarrez un essai gratuit de Sinra →
Découvrez une gestion de projet où les estimations confrontent la réalité, pas où elles la masquent.