| name | sprint-planner |
| description | 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". |
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.
