Cette page rassemble trois exemples concrets de Sprint Planning (banque, e-commerce, mobile), un déroulement détaillé de la réunion avec dialogue réaliste entre Product Owner, Scrum Master et Developers, ainsi qu'une checklist finale et des questions PSM I corrigées. Vous y trouverez tout ce qu'il manque dans la théorie : des Sprint Goals concrets, des User Stories nommées, des capacités chiffrées et le Sprint Backlog obtenu.
Qu'est-ce qu'un Sprint Planning ? (rappel court)
Le Sprint Planning est l'événement Scrum qui ouvre chaque Sprint. Sa raison d'être : permettre au Scrum Team de répondre à trois questions, dans cet ordre — pourquoi ce Sprint a-t-il de la valeur (Sprint Goal), quoi peut être livré (Product Backlog Items sélectionnés), comment le travail va-t-il être réalisé (plan).
Sa timebox maximale est de 8 heures pour un Sprint d'un mois (à proratiser). Le Sprint Planning produit deux sorties : le Sprint Goal et le Sprint Backlog initial.
Pourquoi s'appuyer sur un exemple concret ?
La théorie Scrum est minimaliste : le Scrum Guide tient en 13 pages. C'est sa force, mais aussi sa difficulté principale pour les équipes qui débutent. Un sprint planning example bien construit apporte ce que la théorie ne donne pas :
- Une incarnation : un vrai Sprint Goal, des User Stories nommées, des chiffres de capacité, un Sprint Backlog tangible.
- Une mécanique visible : on voit comment la capacité, l'estimation et la priorisation se combinent pour produire un engagement réaliste.
- Des points de repère : combien d'items pour quelle taille d'équipe, quelle granularité pour un Sprint Goal, à quoi ressemble un plan Sprint.
- Une base de discussion avec votre équipe : « pourquoi notre Sprint Planning ne ressemble-t-elle pas à cela ? » est souvent la meilleure question d'amélioration continue.
Les trois exemples ci-dessous couvrent des domaines très différents — banque, e-commerce, mobile — pour montrer que la structure de la Sprint Planning reste universelle, même si le contenu varie radicalement.
Exemple n°1 — Sprint Planning d'une application bancaire
Contexte : une banque en ligne déploie une nouvelle fonctionnalité de virement instantané SEPA. Le Scrum Team est composé d'un Product Owner, d'un Scrum Master et de 5 Developers (3 back-end, 1 front-end, 1 mobile). Le Sprint dure 2 semaines.
Sprint Goal
« Permettre à un client particulier de réaliser un virement instantané SEPA de bout en bout depuis son espace web sécurisé, avec une exécution traçable et conforme. »
Capacité disponible
| Élément | Valeur |
|---|---|
| Developers | 5 |
| Jours ouvrés sur le Sprint | 10 |
| Jours de congés / formation | 4 (sur la totalité de l'équipe) |
| Support / astreinte estimé | 1 j/personne |
| Capacité nette | ≈ 41 jours-personne |
| Focus Factor retenu | 70 % |
User Stories sélectionnées
| ID | User Story | Estimation | Owner |
|---|---|---|---|
| PBI-101 | En tant que client, je peux initier un virement SEPA instantané depuis mon espace web. | 8 SP | Dev back-end 1 |
| PBI-102 | En tant que client, je peux valider mon virement par OTP (3D Secure interne). | 5 SP | Dev back-end 2 |
| PBI-103 | En tant que back-office, je peux consulter la trace d'exécution d'un virement instantané. | 5 SP | Dev back-end 3 |
| PBI-104 | En tant que client, je suis informé en temps réel du statut de mon virement. | 8 SP | Dev front-end |
| PBI-105 | En tant que client mobile, je suis notifié du résultat de mon virement (push). | 5 SP | Dev mobile |
| PBI-106 | En tant que conformité, l'exécution respecte la réglementation TIPS / SCT Inst. | 3 SP | Dev back-end 1 + PO |
Sprint Backlog obtenu
- Sprint Goal : virement instantané SEPA de bout en bout, traçable et conforme.
- 6 PBI sélectionnés pour un total de 34 story points (cohérent avec la vélocité moyenne de 36 SP).
- Plan : architecture validée en J1, intégration TIPS J2-J5, OTP en parallèle, parcours front J6-J8, tests bout en bout J9, recette PO J10.
- Definition of Done : tests unitaires + intégration verts, revue de code croisée, conformité validée, déployable en pré-production.
Exemple n°2 — Sprint Planning d'un site e-commerce
Contexte : une plateforme e-commerce mode souhaite améliorer son taux de conversion sur la page panier. Scrum Team : 1 PO, 1 SM, 4 Developers full-stack. Sprint de 2 semaines.
Sprint Goal
« Réduire l'abandon de panier en simplifiant le parcours de checkout et en proposant le paiement express Apple Pay / Google Pay. »
Capacité disponible
| Élément | Valeur |
|---|---|
| Developers | 4 |
| Jours ouvrés sur le Sprint | 10 |
| Jours de congés | 2 (1 Developer absent 2 jours) |
| Support / bugs production | ≈ 1,5 j/personne |
| Capacité nette | ≈ 32 jours-personne |
| Focus Factor retenu | 75 % |
User Stories sélectionnées
| ID | User Story | Estimation | Valeur |
|---|---|---|---|
| PBI-201 | En tant qu'acheteur, je peux finaliser ma commande en moins de 3 clics. | 8 SP | Conversion |
| PBI-202 | En tant qu'acheteur, je peux payer en Apple Pay sur mobile. | 5 SP | Conversion mobile |
| PBI-203 | En tant qu'acheteur, je peux payer en Google Pay sur Android. | 5 SP | Conversion mobile |
| PBI-204 | En tant qu'acheteur, je vois immédiatement les erreurs de paiement (CB refusée, 3DS). | 3 SP | UX |
| PBI-205 | En tant que marketing, je peux suivre le taux d'abandon par étape (analytics). | 5 SP | Mesure |
| PBI-206 | Refactor du composant Panier (dette technique bloquant les 3 stories). | 5 SP | Tech |
Sprint Backlog obtenu
- Sprint Goal : réduire l'abandon de panier via checkout simplifié + paiements express.
- 6 PBI sélectionnés (31 SP), avec le refactor en pré-requis technique des stories suivantes.
- Plan : refactor du composant Panier J1-J2, Apple Pay + Google Pay J3-J6, parcours simplifié J5-J8, gestion d'erreurs J8-J9, analytics J9, tests + recette J10.
- Risque identifié : validation Apple Pay côté Apple Developer Account → dépendance externe à débloquer en J1.
Exemple n°3 — Sprint Planning d'une application mobile
Contexte : une startup lance une application mobile de coaching sportif. Scrum Team : 1 PO, 1 SM, 3 Developers mobile (iOS, Android, back-end). Sprint de 1 semaine (rythme intensif d'avant-MVP).
Sprint Goal
« Permettre à un utilisateur de créer un compte, choisir son programme d'entraînement et recevoir sa première séance personnalisée. »
Capacité disponible
| Élément | Valeur |
|---|---|
| Developers | 3 |
| Jours ouvrés sur le Sprint | 5 |
| Jours de congés | 0 |
| Réunions externes (investisseurs) | 0,5 j/personne |
| Capacité nette | ≈ 13,5 jours-personne |
| Focus Factor retenu | 70 % |
User Stories sélectionnées
| ID | User Story | Estimation | Plateforme |
|---|---|---|---|
| PBI-301 | En tant qu'utilisateur, je peux créer un compte (email + mot de passe). | 3 SP | iOS + Android |
| PBI-302 | En tant qu'utilisateur, je peux choisir mon objectif (perte de poids, prise de masse, endurance). | 2 SP | iOS + Android |
| PBI-303 | En tant qu'utilisateur, je vois mon premier programme d'entraînement personnalisé. | 5 SP | iOS + Android |
| PBI-304 | En tant que serveur, je calcule un programme initial à partir des préférences. | 5 SP | Back-end |
| PBI-305 | En tant qu'utilisateur, je peux démarrer ma première séance et la marquer comme terminée. | 3 SP | iOS + Android |
Sprint Backlog obtenu
- Sprint Goal : onboarding complet jusqu'à la première séance personnalisée.
- 5 PBI sélectionnés (18 SP) — le PO a renoncé à inclure la story « partage social » pour ne pas diluer le Sprint Goal.
- Plan : API back-end J1-J2, écrans compte + objectif iOS/Android J1-J3, écran programme + séance J3-J5, intégration end-to-end J4-J5.
- Pair-programming iOS / Android en J1 pour aligner l'architecture de navigation et éviter la divergence.
Déroulement complet d'une Sprint Planning (dialogue réaliste)
Voici comment se déroule, minute après minute, la Sprint Planning de l'équipe bancaire de l'exemple n°1. Le format est volontairement conversationnel pour illustrer les vraies dynamiques d'équipe que vous rencontrerez sur le terrain.
Ouverture (5 min)
Scrum Master« Bonjour à tous. Sprint #42, durée 2 semaines, timebox 4 h. Je suis là pour faciliter, pas pour décider. Le PO va nous présenter le Sprint Goal candidat, puis nous discuterons capacité et sélection. On démarre ? »
Product Owner« Parfait. Le Sprint Goal que je propose : permettre à un client de réaliser un virement instantané SEPA de bout en bout depuis son espace web, traçable et conforme. Le contexte business : nos concurrents ont lancé le virement instantané ce trimestre, on perd des clients. »
1. Pourquoi — Sprint Goal (30 min)
Developer 1« Quand tu dis “de bout en bout”, ça inclut le mobile ? »
Product Owner« Pour ce Sprint, web prioritaire. Le mobile peut recevoir la notification, mais pas initier le virement. »
Developer 2« Et la traçabilité côté conformité, c'est nous qui livrons l'interface back-office ? »
Product Owner« Oui — c'est PBI-103. Sans cette trace, on ne peut pas mettre en production, donc c'est dans le périmètre. »
Scrum Master« Tout le monde comprend pourquoi ce Sprint Goal a de la valeur ? Pas de question bloquante ? On peut passer au quoi ? »
2. Capacité (15 min)
Scrum Master« Capacité brute : 5 Developers × 10 jours = 50 j/p. Congés / formations : 4 j. Support : ~5 j. Capacité nette : ≈ 41 j/p. »
Developer 3« On a aussi le RUN sur le batch nuit. Je dirais 1 jour par personne, pas plus. »
Scrum Master« OK, on retient 41 j/p net avec un Focus Factor de 70 %. Tout le monde est aligné ? »
3. Quoi — Sélection des PBI (90 min)
Product Owner« Je vous propose ces 6 PBI dans cet ordre de priorité. PBI-101 puis 102 puis 106 sont indispensables au Sprint Goal. 103, 104, 105 enrichissent la valeur. »
Developer 1« PBI-101 à 8 SP, c'est ok ? On a refait l'estimation au refinement la semaine dernière. »
Developer 2« Oui, validé. Mais attention, PBI-106 (conformité) dépend du retour de l'équipe juridique. Si on ne l'a pas en J3, on est bloqué. »
Scrum Master« Je note ce risque. Action : PO contacte juridique demain matin. »
Developer 3« Avec ces 6 PBI on est à 34 SP. Vélocité moyenne : 36. C'est dans la cible. »
Product Owner« Si on a du temps en plus, je pousserais PBI-107 (bénéficiaires favoris) — mais ce n'est pas dans le Sprint Goal. »
Developer 1« Mettons-le en stretch, hors Sprint Backlog. On l'embarquera si on est en avance. »
4. Comment — Plan (60 min)
Developer 1« Pour PBI-101, j'attaque l'intégration TIPS J1. Avant ça, je sécurise les credentials avec l'archi. »
Developer 2« Je prends l'OTP en parallèle. Pas de dépendance avec TIPS, on peut avancer simultanément. »
Developer 3« Trace conformité après l'intégration TIPS — j'enchaîne en J5. »
Developer 4 (front)« Je peux commencer les écrans dès J3 avec des mocks, puis brancher l'API en J6. »
Developer 5 (mobile)« Notification push : 1 jour de dev + 1 jour de test stores. Je vise J7-J8. »
Scrum Master« Une chose qui m'inquiète : on ne parle pas encore de la Definition of Done. Quelqu'un veut la rappeler ? »
Developer 1« Vrai : tests unitaires + intégration, revue de code croisée, conformité validée, déployable en pré-production. C'est toujours d'actualité. »
Clôture (10 min)
Scrum Master« Sprint Goal validé, Sprint Backlog à 34 SP, plan partagé, 1 risque externe identifié. On clôt la Sprint Planning à 3 h 30 — on a 30 min d'avance. »
Product Owner« Merci à tous. Je suis disponible toute la semaine pour clarifier toute question. »
Erreurs fréquentes en Sprint Planning
| Erreur | Conséquence | Correction |
|---|---|---|
| Sprint trop ambitieux | Sur-engagement, dette technique cumulée, démotivation après 2-3 Sprints. | Confronter systématiquement la somme des estimations à la capacité nette. Mieux vaut sous-engager et livrer. |
| Absence de Sprint Goal | Sprint Backlog incohérent, Daily Scrum sans boussole, Sprint Review difficile à animer. | Le PO arrive avec un Sprint Goal candidat écrit. Aucun Sprint ne démarre sans Goal. |
| Product Owner absent ou flou | Les Developers extrapolent les priorités, le Sprint Backlog dérive. | Le PO est obligatoire pendant tout le Sprint Planning Meeting. À défaut, on reporte l'événement. |
| User Stories incomplètes (DoR non respectée) | Refinement à chaud, Sprint Planning qui s'éternise, sélection à l'aveugle. | Tenir un refinement régulier (1 h par semaine au minimum) pour amener des PBI prêts. |
| Mauvaise estimation | Vélocité instable, capacité fictive, conflit en Sprint Review. | Estimer en équipe pendant le refinement, recalibrer en Sprint Retrospective. |
| Capacité oubliée | Engagement comme si l'équipe était au complet alors que 30 % est absente. | Recalculer la capacité à chaque Sprint (congés, support, formations, jours fériés). |
| Confusion Sprint Goal / liste de tâches | Sprint Goal = somme des PBI. Si on en retire un, le Goal s'effondre. | Le Sprint Goal doit être atteignable même si certains PBI sont coupés. |
| Sprint Planning > timebox | Fatigue, baisse de qualité des décisions. | Vérifier le refinement amont, structurer l'agenda, le SM rappelle le temps restant. |
Bonnes pratiques
Conseils pour réussir sa Sprint Planning
- Démarrez à l'heure. Une Sprint Planning qui commence avec 15 minutes de retard finit en surchauffe.
- Vidéoprojetez l'agenda et le Sprint Goal en continu. Tout le monde voit où on en est.
- Limitez les invités externes : experts en visio à la demande, pas en spectateurs permanents.
- Faites pause toutes les 90 minutes. La fatigue dégrade la qualité des engagements.
- Terminez par un check d'engagement explicite : « Sommes-nous tous d'accord pour viser ce Sprint Goal avec ce Sprint Backlog ? »
- Conservez 5 à 10 minutes de slack en fin d'événement pour les actions post-planning (notifications Jira, mise à jour du board, planning du premier Daily Scrum).
Questions PSM I typiques sur la Sprint Planning
Question 1
Pendant la Sprint Planning, qui décide du nombre de Product Backlog Items à embarquer dans le Sprint ?
- A. Le Product Owner.
- B. Le Scrum Master.
- C. Les Developers.
- D. Le management.
Réponse : C. Seuls les Developers décident de ce qu'ils peuvent embarquer pour atteindre le Sprint Goal. Le PO ordonne le Product Backlog mais n'impose pas le volume.
Question 2
Quelle est la timebox maximale d'une Sprint Planning pour un Sprint d'un mois ?
- A. 2 heures.
- B. 4 heures.
- C. 8 heures.
- D. Aucune limite officielle.
Réponse : C. 8 heures maximum, à proratiser pour les Sprints plus courts.
Question 3
Le Product Owner ne se présente pas à la Sprint Planning. Que devrait faire le Scrum Master ?
- A. Démarrer sans lui, les Developers connaissent les priorités.
- B. Annuler le Sprint et reporter à plus tard.
- C. Aider l'organisation à comprendre la nécessité de la présence du PO et reporter l'événement si nécessaire.
- D. Remplacer le PO et prioriser à sa place.
Réponse : C. Le Scrum Master ne décide pas à la place du PO. Son rôle est d'amener l'organisation à respecter Scrum.
Question 4
Quelles sont les sorties obligatoires d'une Sprint Planning ?
- A. Un Sprint Goal et un Sprint Backlog.
- B. Un Sprint Goal, un Sprint Backlog et une Definition of Done à jour.
- C. Un Sprint Backlog et un plan détaillé heure par heure.
- D. Un Sprint Goal seulement.
Réponse : A. Sprint Goal + Sprint Backlog. La Definition of Done est un engagement préexistant, pas une sortie de l'événement.
Question 5
Le Sprint Backlog peut-il évoluer après la Sprint Planning ?
- A. Non, il est figé pendant tout le Sprint.
- B. Oui, mais seul le Product Owner peut le modifier.
- C. Oui, les Developers peuvent l'ajuster tant que le Sprint Goal est préservé.
- D. Oui, uniquement pendant le Daily Scrum.
Réponse : C. Le Sprint Backlog est un artefact vivant. Seul le Sprint Goal reste stable.
Checklist finale d'une Sprint Planning réussie
- ☐ Le Product Owner est présent du début à la fin.
- ☐ Un Sprint Goal candidat a été présenté en ouverture.
- ☐ La capacité de l'équipe a été calculée et discutée.
- ☐ Tous les PBI sélectionnés respectent la Definition of Ready.
- ☐ La somme des estimations est compatible avec la capacité nette.
- ☐ Chaque PBI sélectionné contribue clairement au Sprint Goal.
- ☐ Les dépendances externes sont nommées, datées, avec une action de déblocage.
- ☐ Un plan initial (qui fait quoi, quand) est partagé — sans être figé.
- ☐ La Definition of Done a été rappelée et partagée.
- ☐ Tous les Developers ont validé explicitement l'engagement collectif.
- ☐ La Sprint Planning a respecté sa timebox.
- ☐ Un compte rendu léger (Markdown / Notion / Excel) est accessible à l'équipe.
FAQ — Sprint Planning : exemples concrets
Retrouvez ci-dessous les dix questions les plus fréquemment posées sur les exemples de Sprint Planning (nombre d'items, durée, participants, estimation, préparation, transposition d'un exemple à une autre équipe…).
À lire aussi
Source officielle : Scrum Guide 2020.