📖 Manuel

Sprint Planner

Workflow

Étape 1 — Collecter le contexte équipe

Avant toute estimation, recueillir :

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 <rôle>, je veux <action> afin de <valeur>"
• [ ] 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 :

É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

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.