Cette page rassemble la Sprint Planning Checklist francophone la plus complète : préparation amont, déroulement de la réunion, sortie formalisée, et vérifications dédiées au Product Owner, au Scrum Master et aux Developers. Elle complète le Sprint Planning Template (structure réutilisable) et le Sprint Planning Example (cas concrets) pour garantir qu'aucun point critique n'est oublié.
Pourquoi utiliser une checklist de Sprint Planning ?
Le Sprint Planning est l'événement qui ouvre chaque Sprint Scrum. Sa qualité conditionne tout le Sprint : un Sprint Goal flou, un Sprint Backlog mal calibré ou une capacité fantaisiste produisent mécaniquement un Sprint sous-tension et une Sprint Review douloureuse.
Une Sprint Planning checklist ne remplace pas le facilitateur, ne se substitue pas à l'expérience de l'équipe et n'est pas prescrite par le Scrum Guide. C'est un aide-mémoire opérationnel, qui apporte trois bénéfices :
- Réduire les oublis : capacité non recalculée, Definition of Done non revue, dépendance non identifiée. Chacun de ces oublis coûte des heures dans le Sprint.
- Accélérer l'événement : une Sprint Planning bien préparée tient largement dans sa timebox. Une mal préparée la dépasse systématiquement.
- Industrialiser l'amélioration continue : la checklist est un objet d'inspection en Sprint Retrospective. On ajoute une ligne quand on s'est planté, on en retire une quand elle devient superflue.
Flux et chronologie
Checklist — avant le Sprint Planning (préparation)
La préparation se déroule sur les 2 à 3 jours précédents. Elle est portée principalement par le Product Owner et le Scrum Master, avec la participation active des Developers lors du dernier refinement.
✓ Préparation (J-3 à J-1)
- Le Product Backlog est ordonné et raffiné en haut (au moins 2 Sprints d'avance).Critique
- Les PBI candidats respectent la Definition of Ready (si l'équipe en utilise une).Critique
- Les estimations sont à jour, partagées en équipe lors du dernier refinement.Critique
- Le Sprint Goal candidat est formulé par le Product Owner.Critique
- La capacité du Sprint est calculée (congés, support, formations, jours fériés).Critique
- Les dépendances externes connues sont identifiées et tracées.
- Le Product Goal courant est visible et rappelé.
- L'agenda de l'événement est partagé 24 h avant.
- La disponibilité du Scrum Team complet est confirmée sur toute la timebox.Critique
- Les outils sont prêts : board Jira / Trello / Linear, support de prise de notes, salle ou visio.
- Les experts à inviter ponctuellement (UX, sécurité, architecte) sont prévenus.
- La Definition of Done est connue de tous et accessible.
Checklist — pendant la Sprint Planning (réunion)
La Sprint Planning suit la séquence Why → What → How prescrite par le Scrum Guide. La checklist ci-dessous garantit que chacune des trois phases produit ses sorties.
✓ Ouverture (5 à 10 min)
- Le Scrum Master rappelle la timebox et le rôle de chacun.
- Le Product Owner présente le contexte et le Sprint Goal candidat.Critique
- Le Product Goal est rappelé pour ancrer le Sprint dans la stratégie produit.
✓ Why — Sprint Goal (15 à 45 min)
- Le Sprint Goal est compris par tous les Developers.Critique
- Les questions de clarification ont été posées et répondues.
- Le Sprint Goal est unique, ambitieux et atteignable.Critique
- Le Sprint Goal est aligné avec le Product Goal.
✓ What — sélection des Product Backlog Items (60 à 120 min)
- Les Developers ont sélectionné les PBI cohérents avec le Sprint Goal.Critique
- Le volume sélectionné est confronté à la capacité disponible.Critique
- Chaque PBI sélectionné est compris (acceptance criteria, contraintes).
- Les risques et dépendances par PBI sont nommés.
- La somme des estimations est compatible avec la vélocité historique.
- Les PBI non sélectionnés restent dans le Product Backlog (rien n'est perdu).
✓ How — plan de réalisation (45 à 90 min)
- Un plan initial est défini pour livrer le Sprint Goal.Critique
- Les premiers jours du Sprint sont décomposés (tâches, owners pressentis).
- La Definition of Done est rappelée et appliquée à chaque PBI.Critique
- Les binômes / pairs / dépendances internes sont planifiés.
- Les actions de déblocage sur dépendances externes sont assignées avec une date.
✓ Clôture (10 min)
- Le Sprint Goal est relu et validé collectivement.Critique
- Le Sprint Backlog initial est figé (PBI + plan).Critique
- Les engagements implicites (DoD, valeurs Scrum) sont rappelés.
- Le premier Daily Scrum est planifié (lieu, heure, format).
Checklist — après le Sprint Planning
La Sprint Planning ne s'arrête pas à la fin de la timebox : il faut formaliser et diffuser ce qui a été décidé pour que le Sprint démarre proprement.
✓ Formalisation et diffusion (dans l'heure qui suit)
- Le Sprint Goal est écrit en haut du board / outil.Critique
- Le Sprint Backlog est créé dans l'outil (Jira, Trello, Linear...).Critique
- Les PBI sont rattachés au Sprint, avec leurs sous-tâches initiales.
- Les actions de déblocage externes sont envoyées (mails, tickets, Slack).
- La note de Sprint Planning (5 lignes) est partagée aux stakeholders concernés.
- La date et l'heure du premier Daily Scrum sont confirmées dans les calendriers.
✓ Validation finale
- Chaque Developer connaît la première tâche qu'il prendra à J1.Critique
- Aucune dépendance bloquante n'est laissée sans action de déblocage.
- Le PO confirme sa disponibilité tout au long du Sprint.
- Le SM a planifié les autres événements (Sprint Review, Retrospective).
- L'équipe a un mécanisme clair pour adapter le Sprint Backlog en cours de Sprint.
Vérifications spécifiques au Product Owner
✓ Product Owner
- J'ai ordonné le Product Backlog selon la valeur business.Critique
- Mes PBI candidats sont raffinés (acceptance criteria, dépendances).
- J'ai formulé un Sprint Goal candidat clair et engageant.Critique
- Je suis disponible pendant toute la Sprint Planning, sans interruption.Critique
- Je peux répondre aux questions de clarification métier sans devoir consulter ailleurs.
- J'ai pré-identifié les stakeholders pertinents pour la Sprint Review qui suivra.
- Mon Sprint Goal candidat est aligné avec le Product Goal.
- Je suis prêt à ajuster le Sprint Goal si les Developers proposent une meilleure formulation.
Vérifications spécifiques au Scrum Master
✓ Scrum Master
- L'agenda et la timebox sont partagés en amont.
- L'environnement de réunion (salle / visio / board) est fonctionnel.Critique
- Je facilite la séquence Why → What → How sans la court-circuiter.
- Je rappelle le temps restant à intervalles réguliers.
- Je détecte les signaux faibles (sur-engagement, Sprint Goal flou).
- Je veille à ce que chaque Developer s'exprime.
- Je rappelle la Definition of Done et les valeurs Scrum si nécessaire.
- Je m'assure que les sorties (Sprint Goal + Sprint Backlog) sont effectivement produites.Critique
Vérifications spécifiques aux Developers
✓ Developers
- Nous connaissons notre capacité réelle (congés, support, formations).Critique
- Nous avons participé au dernier refinement et compris les PBI candidats.
- Nous sélectionnons librement le volume de travail que nous embarquons.Critique
- Nous challengeons le Sprint Goal si nous le trouvons flou ou inatteignable.
- Nous identifions les dépendances techniques et externes.
- Nous produisons un plan initial — réaliste, pas exhaustif.
- Nous appliquons la Definition of Done à chaque PBI sélectionné.Critique
- Nous nous engageons collectivement sur le Sprint Goal, pas individuellement sur des tâches.Critique
Tableau des responsabilités — qui vérifie quoi, et quand ?
| À vérifier | Responsable | Moment | Niveau |
|---|---|---|---|
| Product Backlog ordonné et raffiné | Product Owner | Avant | Critique |
| Capacité de l'équipe estimée | Developers + SM | Avant | Critique |
| Sprint Goal candidat formulé | Product Owner | Avant | Critique |
| Disponibilité du Scrum Team complet | Scrum Master | Avant | Critique |
| Dépendances externes identifiées | Developers + PO | Avant | Important |
| Sprint Goal validé collectivement | Scrum Team | Pendant (Why) | Critique |
| Cohérence sélection PBI ↔ Sprint Goal | Developers | Pendant (What) | Critique |
| Sélection compatible avec la capacité | Developers | Pendant (What) | Critique |
| Plan initial partagé | Developers | Pendant (How) | Critique |
| Definition of Done rappelée | Scrum Master | Pendant (How) | Important |
| Sprint Goal écrit visiblement | Scrum Master | Après | Important |
| Sprint Backlog créé dans l'outil | Developers | Après | Critique |
| Actions de déblocage envoyées | PO + SM | Après | Important |
| Note diffusée aux stakeholders | Product Owner | Après | Facultatif |
Erreurs fréquentes vs bonnes pratiques
| Dimension | Bonne pratique | Erreur fréquente |
|---|---|---|
| Préparation | Refinement régulier + capacité calculée à l'avance | Tout improviser en début d'événement |
| Sprint Goal | Formulé en amont par le PO, retravaillé en séance | Bricolé à partir des PBI sélectionnés |
| Sélection PBI | Décidée par les Developers selon leur capacité | Imposée par le PO ou le management |
| Plan | Initial, réaliste, vivant | Exhaustif, figé, sur-détaillé |
| Definition of Done | Rappelée et appliquée | Oubliée jusqu'à la Sprint Review |
| Sortie | Sprint Goal + Sprint Backlog visibles | Liste de tickets sans cap commun |
| Diffusion | Note 5 lignes envoyée dans l'heure | Aucune trace écrite |
| Premier Daily | Planifié immédiatement | Improvisé le lendemain |
Conseils Scrum Guide
Le Scrum Guide 2020 fixe quelques règles non négociables que votre checklist doit intégrer :
- La Sprint Planning a deux sorties obligatoires : Sprint Goal et Sprint Backlog. Tout point de la checklist doit converger vers ces deux artefacts.
- La timebox maximale est de 8 heures pour un Sprint d'un mois, à proratiser. Une checklist trop longue qui pousserait au dépassement de timebox est une checklist mal calibrée.
- La séquence officielle est Why → What → How. Ne pas inverser : le Sprint Goal vient avant la sélection de PBI, qui vient avant le plan.
- Le Sprint Goal est un engagement du Sprint Backlog. Il ne se résume pas à la somme des PBI.
- Seuls les Developers décident du volume embarqué. Le PO ordonne et clarifie ; il n'impose pas.
Pièges PSM I liés à la Sprint Planning
Piège n°1 — Le PO décide du nombre de PBI
Faux. Le Product Owner ordonne le Product Backlog et formule le Sprint Goal candidat, mais ce sont les Developers qui sélectionnent — librement — le volume qu'ils peuvent embarquer pour atteindre le Sprint Goal.
Piège n°2 — Pas de Sprint Goal ? On commence quand même
Faux. La Sprint Planning ne se termine pas sans Sprint Goal. Si l'équipe n'y arrive pas, c'est généralement le signe d'un Product Backlog mal raffiné ou trop hétérogène. On retravaille la sélection.
Piège n°3 — Le Scrum Master valide le Sprint Backlog
Faux. Le Scrum Master facilite et coache. Le Sprint Backlog appartient aux Developers. Le SM n'a aucun pouvoir de validation sur le périmètre du Sprint.
Piège n°4 — Le management impose la vélocité
Faux. La vélocité est un indicateur d'aide à la décision interne à l'équipe. Aucune partie prenante extérieure ne fixe la capacité d'un Sprint. Confondre engagement et exigence externe est un anti-pattern courant.
Piège n°5 — Le Sprint Backlog est figé pour le reste du Sprint
Faux. Le Sprint Backlog est un artefact vivant. Les Developers peuvent ajouter, retirer ou réordonner des tâches en cours de Sprint, tant que le Sprint Goal reste viable. Seul le Sprint Goal est stable.
FAQ — Sprint Planning Checklist
Les 11 questions ci-dessous synthétisent les interrogations les plus fréquentes autour d'une Sprint Planning Checklist. Elles sont également exposées en JSON-LD pour aider Google et les moteurs IA à comprendre le contenu de cette page.