# Sprint Planner > 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". - Skill: `khalilbenaz/sprint-planner` (Agent Skill) - Install (CLI): `npx skillmds@latest add khalilbenaz/sprint-planner` - Raw SKILL.md: https://api.skillmd.com/api/skills/khalilbenaz/sprint-planner/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: khalilbenaz (https://skillmd.com/u/khalilbenaz) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/khalilbenaz/sprint-planner --- # 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 : - [ ] Rédigée en format user story : "En tant que ``, je veux `` afin de ``" - [ ] Critères d'acceptation listés (format Given/When/Then ou liste à puces) - [ ] Estimée (story points ou T-shirt size) - [ ] Dépendances identifiées et déblocables dans le sprint - [ ] Maquette/design disponible si besoin - [ ] Pas de blocker technique connu non résolu 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 : 1. PO lit la story + critères d'acceptation. 2. Chaque dev vote en silence (cartes physiques ou outil type PlanningPoker.com / Jira). 3. Révéler simultanément. 4. Si écart > 2 niveaux → discussion de 2 min max, puis re-vote. 5. 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 1. Trier le backlog par priorité PO (MoSCoW ou ordre Jira/ADO). 2. Ajouter les stories dans le sprint du plus prioritaire au moins prioritaire **jusqu'à atteindre la capacité nette**. 3. Ne jamais dépasser la capacité nette, même si le PO insiste. 4. 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.