Sprint Planner
Workflow
Étape 1 — Collecter le contexte équipe
Avant toute estimation, recueillir :
| Info |
Exemple |
| Taille équipe |
5 devs + 1 QA |
| Durée sprint |
2 semaines (10 jours ouvrés) |
| Absences connues |
2 jours congés (dev A), 1 jour formation (dev B) |
| Focus factor historique |
0.70 (70 % du temps sur le sprint) |
Focus factor = temps réellement productif / temps calendaire disponible. Partir sur 0.65–0.75 si inconnu.
Étape 2 — Calculer la capacité réelle
Capacité (points) = vélocité_moyenne_3_derniers_sprints × (jours_disponibles / jours_sprint_complet)
Exemple :
- Vélocité moyenne : 40 pts
- Jours disponibles : 10j - 3j absences = 7j
- Jours sprint complet : 10j
- Capacité ajustée : 40 × (7/10) = 28 pts
Buffer obligatoire : soustraire 10–15 % pour support, incidents, revues de PR.
Capacité nette = 28 × 0.85 = ~24 pts
Étape 3 — Vérifier la Definition of Ready (DoR)
Chaque story candidate doit cocher tous les critères avant d'entrer dans le sprint :
Story qui échoue à la DoR → retour au backlog, pas de négociation.
Étape 4 — Estimer avec Planning Poker
Séquence Fibonacci recommandée : 1, 2, 3, 5, 8, 13, 21, ?
Règles d'animation :
- PO lit la story + critères d'acceptation.
- Chaque dev vote en silence (cartes physiques ou outil type PlanningPoker.com / Jira).
- Révéler simultanément.
- Si écart > 2 niveaux → discussion de 2 min max, puis re-vote.
- Consensus = valeur la plus basse sur laquelle l'équipe est à l'aise.
Critères de décision rapide :
| Points |
Signal |
| 1–3 |
Story triviale, attention aux oublis cachés |
| 5–8 |
Taille idéale |
| 13 |
Limite haute, envisager un découpage |
| 21+ |
Trop gros — découper obligatoirement |
Étape 5 — Sélectionner les stories
- Trier le backlog par priorité PO (MoSCoW ou ordre Jira/ADO).
- Ajouter les stories dans le sprint du plus prioritaire au moins prioritaire jusqu'à atteindre la capacité nette.
- Ne jamais dépasser la capacité nette, même si le PO insiste.
- Si une story dépasse seule la capacité restante → la découper ou la reporter.
Exemple : capacité nette = 24 pts
Story #101 : 8 pts → total = 8 ✓
Story #102 : 5 pts → total = 13 ✓
Story #103 : 8 pts → total = 21 ✓
Story #104 : 5 pts → total = 26 ✗ → reporter
Story #105 : 3 pts → total = 24 ✓ (si #104 reportée)
Étape 6 — Décomposer en tâches techniques
Pour chaque story retenue, créer des tâches (< 1 jour chacune idéalement) :
Story : "Afficher le solde en temps réel"
Tâches :
- [ ] Endpoint GET /account/balance (dev, 3h)
- [ ] Intégration front composant BalanceWidget (dev, 4h)
- [ ] Tests unitaires service + composant (dev, 2h)
- [ ] Test E2E scénario solde (QA, 2h)
Tâche > 8h → la redécouper.
Étape 7 — Formuler le Sprint Goal
Un seul objectif, 1–2 phrases, orienté valeur métier (pas liste de features) :
Bon : "Permettre au client de consulter son solde et d'initier un virement depuis l'app mobile."
Mauvais : "Finir les stories #101, #102 et #105."
Le sprint goal guide les arbitrages en cours de sprint si un imprévu survient.
Étape 8 — Clôturer le sprint planning
- Équipe confirme verbalement l'engagement sur le contenu.
- Sprint backlog verrouillé dans l'outil (Jira, Azure DevOps, Linear...).
- Sprint goal affiché sur le board.
- Date/heure de la Daily, Review et Rétro fixées.
Anti-patterns à éviter
| Anti-pattern |
Conséquence |
Correction |
| Surcharger la capacité "parce qu'on est motivés" |
Carry-over chronique, moral en berne |
Respecter la capacité nette sans exception |
| Stories floues sans critères d'acceptation |
Débat en fin de sprint, rejet en review |
DoR stricte, retour backlog si flou |
| Estimer sous pression du PO |
Estimates biaisés, retard garanti |
Votes anonymes, règle des 2 min de discussion |
| Sprint goal = liste de tickets |
Aucune cohérence, arbitrage impossible |
1 objectif métier unique, formulé en valeur |
| Tâches de > 1 jour |
Manque de visibilité, blocages invisibles |
Découpage systématique à < 8h |
| Ignorer la dette technique |
Vélocité qui s'effondre sprint après sprint |
Réserver 15–20 % de la capacité à la dette |
Bonnes pratiques 2026
- Vibe check en ouverture : 2 min pour que chacun dise son niveau d'énergie (1–5). Identifie les surcharges cachées avant de commencer.
- Definition of Done (DoD) visible : affiché sur le board, mise à jour à chaque rétro. Sans DoD partagée, "terminé" ne veut rien dire.
- Velocity trend : surveiller la tendance sur 6 sprints, pas seulement la moyenne des 3 derniers. Une tendance baissière est un signal d'alerte.
- Async planning possible : pour les équipes distribuées, utiliser un outil de Planning Poker async (Jira/ADO + extension, PlanningPoker.com) plutôt qu'une réunion synchrone de 3h.
- Refine ≠ Plan : le backlog refinement (grooming) doit précéder le sprint planning d'au moins 48h. Ne pas faire les deux le même jour.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
1---2name: management-sprint-planner3description: Aide à planifier des sprints agile, organiser le backlog, estimer les stories et gérer la capacité de l'équipe. Se déclenche avec "sprint", "sprint planning", "backlog", "vélocité", "agile", "scrum". Also triggers on "plan a sprint", "groom the backlog", "team capacity planning".4---56# Sprint Planner78## Workflow910### Étape 1 — Collecter le contexte équipe1112Avant toute estimation, recueillir :1314| Info | Exemple |15|---|---|16| Taille équipe | 5 devs + 1 QA |17| Durée sprint | 2 semaines (10 jours ouvrés) |18| Absences connues | 2 jours congés (dev A), 1 jour formation (dev B) |19| Focus factor historique | 0.70 (70 % du temps sur le sprint) |2021> Focus factor = temps réellement productif / temps calendaire disponible. Partir sur 0.65–0.75 si inconnu.2223---2425### Étape 2 — Calculer la capacité réelle2627```28Capacité (points) = vélocité_moyenne_3_derniers_sprints × (jours_disponibles / jours_sprint_complet)2930Exemple :31- Vélocité moyenne : 40 pts32- Jours disponibles : 10j - 3j absences = 7j33- Jours sprint complet : 10j34- Capacité ajustée : 40 × (7/10) = 28 pts35```3637Buffer obligatoire : soustraire 10–15 % pour support, incidents, revues de PR.3839```40Capacité nette = 28 × 0.85 = ~24 pts41```4243---4445### Étape 3 — Vérifier la Definition of Ready (DoR)4647Chaque story candidate doit cocher **tous** les critères avant d'entrer dans le sprint :4849- [ ] Rédigée en format user story : "En tant que `<rôle>`, je veux `<action>` afin de `<valeur>`"50- [ ] Critères d'acceptation listés (format Given/When/Then ou liste à puces)51- [ ] Estimée (story points ou T-shirt size)52- [ ] Dépendances identifiées et déblocables dans le sprint53- [ ] Maquette/design disponible si besoin54- [ ] Pas de blocker technique connu non résolu5556Story qui échoue à la DoR → retour au backlog, pas de négociation.5758---5960### Étape 4 — Estimer avec Planning Poker6162Séquence Fibonacci recommandée : `1, 2, 3, 5, 8, 13, 21, ?`6364Règles d'animation :651. PO lit la story + critères d'acceptation.662. Chaque dev vote en silence (cartes physiques ou outil type PlanningPoker.com / Jira).673. Révéler simultanément.684. Si écart > 2 niveaux → discussion de 2 min max, puis re-vote.695. Consensus = valeur la plus basse sur laquelle l'équipe est à l'aise.7071Critères de décision rapide :7273| Points | Signal |74|---|---|75| 1–3 | Story triviale, attention aux oublis cachés |76| 5–8 | Taille idéale |77| 13 | Limite haute, envisager un découpage |78| 21+ | Trop gros — découper obligatoirement |7980---8182### Étape 5 — Sélectionner les stories83841. Trier le backlog par priorité PO (MoSCoW ou ordre Jira/ADO).852. Ajouter les stories dans le sprint du plus prioritaire au moins prioritaire **jusqu'à atteindre la capacité nette**.863. Ne jamais dépasser la capacité nette, même si le PO insiste.874. Si une story dépasse seule la capacité restante → la découper ou la reporter.8889```90Exemple : capacité nette = 24 pts91Story #101 : 8 pts → total = 8 ✓92Story #102 : 5 pts → total = 13 ✓93Story #103 : 8 pts → total = 21 ✓94Story #104 : 5 pts → total = 26 ✗ → reporter95Story #105 : 3 pts → total = 24 ✓ (si #104 reportée)96```9798---99100### Étape 6 — Décomposer en tâches techniques101102Pour chaque story retenue, créer des tâches (< 1 jour chacune idéalement) :103104```105Story : "Afficher le solde en temps réel"106Tâches :107 - [ ] Endpoint GET /account/balance (dev, 3h)108 - [ ] Intégration front composant BalanceWidget (dev, 4h)109 - [ ] Tests unitaires service + composant (dev, 2h)110 - [ ] Test E2E scénario solde (QA, 2h)111```112113Tâche > 8h → la redécouper.114115---116117### Étape 7 — Formuler le Sprint Goal118119Un seul objectif, 1–2 phrases, orienté valeur métier (pas liste de features) :120121```122Bon : "Permettre au client de consulter son solde et d'initier un virement depuis l'app mobile."123Mauvais : "Finir les stories #101, #102 et #105."124```125126Le sprint goal guide les arbitrages en cours de sprint si un imprévu survient.127128---129130### Étape 8 — Clôturer le sprint planning131132- Équipe confirme verbalement l'engagement sur le contenu.133- Sprint backlog verrouillé dans l'outil (Jira, Azure DevOps, Linear...).134- Sprint goal affiché sur le board.135- Date/heure de la Daily, Review et Rétro fixées.136137---138139## Anti-patterns à éviter140141| Anti-pattern | Conséquence | Correction |142|---|---|---|143| Surcharger la capacité "parce qu'on est motivés" | Carry-over chronique, moral en berne | Respecter la capacité nette sans exception |144| Stories floues sans critères d'acceptation | Débat en fin de sprint, rejet en review | DoR stricte, retour backlog si flou |145| Estimer sous pression du PO | Estimates biaisés, retard garanti | Votes anonymes, règle des 2 min de discussion |146| Sprint goal = liste de tickets | Aucune cohérence, arbitrage impossible | 1 objectif métier unique, formulé en valeur |147| Tâches de > 1 jour | Manque de visibilité, blocages invisibles | Découpage systématique à < 8h |148| Ignorer la dette technique | Vélocité qui s'effondre sprint après sprint | Réserver 15–20 % de la capacité à la dette |149150---151152## Bonnes pratiques 2026153154- **Vibe check en ouverture** : 2 min pour que chacun dise son niveau d'énergie (1–5). Identifie les surcharges cachées avant de commencer.155- **Definition of Done (DoD) visible** : affiché sur le board, mise à jour à chaque rétro. Sans DoD partagée, "terminé" ne veut rien dire.156- **Velocity trend** : surveiller la tendance sur 6 sprints, pas seulement la moyenne des 3 derniers. Une tendance baissière est un signal d'alerte.157- **Async planning possible** : pour les équipes distribuées, utiliser un outil de Planning Poker async (Jira/ADO + extension, PlanningPoker.com) plutôt qu'une réunion synchrone de 3h.158- **Refine ≠ Plan** : le backlog refinement (grooming) doit précéder le sprint planning d'au moins 48h. Ne pas faire les deux le même jour.159160161## Communication Rules — MANDATORY162163- Ultra-concise. No filler, no preamble, no pleasantries.164- Never say "happy to help", "sure!", "great question", "let me", or similar.165- Tool first, talk second. Act before explaining.166- Result first. Lead with outcome, not process.167- Stop when done. No summary, no recap, no trailing commentary.168- No politeness wrappers. Direct and blunt.169- Minimum words. If one word works, do not use ten.170- No unsolicited explanations.171- No emoji unless asked.
khalilbenaz