Un Sprint Planning Template structure votre Sprint Planning Meeting pour en faire un événement court, décisionnel et engageant. Cette page rassemble plusieurs modèles gratuits (Markdown, Excel, Google Sheets, Word, PDF), un agenda type, un exemple complet et une checklist Sprint Planning pour les équipes Scrum francophones — du débutant qui prépare son PSM I au Scrum Master expérimenté qui veut industrialiser ses Sprints.
Pourquoi utiliser un template de Sprint Planning ?
Un Sprint Planning sans modèle dérive très vite : on improvise l'ordre du jour, on oublie la capacité, on confond Sprint Goal et liste de tickets. Un bon Agile Sprint Planning Template apporte quatre bénéfices concrets :
- Cadrer l'événement dès la première minute : Sprint Goal candidat, participants, capacité, ordre des sujets.
- Garantir la complétude : aucun élément clé (DoD, dépendances, risques) n'est oublié.
- Accélérer la préparation : le Product Owner et les Developers savent exactement ce qui sera attendu d'eux.
- Faciliter la transparence : un même format Sprint après Sprint permet de comparer, d'inspecter et d'adapter en Sprint Retrospective.
Ce guide s'adresse aux Scrum Masters, Product Owners, Developers, coachs Agile, chefs de projet en transition et candidats au Sprint Planning du PSM I. Les modèles sont volontairement génériques pour s'adapter à toutes les tailles d'équipe.
Template Sprint Planning prêt à copier (Markdown)
Le format Markdown est idéal pour Notion, Confluence, GitHub, GitLab, Obsidian ou n'importe quel éditeur de texte. Copiez-collez le modèle suivant, dupliquez-le à chaque Sprint et remplissez-le en direct pendant le Sprint Planning Meeting.
# Sprint Planning — Sprint #__ Date : __________ Durée prévue : __h Scrum Master : __________ Product Owner : __________ ## 1. Objectif du Sprint (Why) - Sprint Goal : ______________________________________________ - Lien avec le Product Goal : ________________________________ ## 2. Participants - Product Owner : __________ - Developers : __________ - Scrum Master : __________ - Invités ponctuels (UX, archi, conformité) : __________ ## 3. Capacité disponible - Jours ouvrés du Sprint : __ - Congés / formations / support : __ - Capacité nette (en jours-personne) : __ - Hypothèses de Focus Factor : __ % ## 4. Product Backlog sélectionné (What) | # | Item | Estimation | Valeur | DoR ? | |---|------|------------|--------|-------| | 1 | | | | | | 2 | | | | | | 3 | | | | | ## 5. Plan de livraison (How) - Découpage en sous-tâches : ______________ - Approche technique clé : ______________ - Définition de Done (rappel) : ______________ ## 6. Risques & dépendances - Risques identifiés : ______________ - Dépendances externes : ______________ - Mitigations prévues : ______________ ## 7. Décisions - Décision 1 : ______________ - Décision 2 : ______________ ## 8. Actions à mener avant le Daily Scrum de demain - [ ] __________ - [ ] __________
Template Sprint Planning Excel
Excel reste la référence pour calculer la capacité, agréger les estimations et suivre le Focus Factor d'un Sprint à l'autre. Le tableau type ci-dessous tient sur une seule feuille et se reproduit en quelques minutes. Pour un Sprint Planning Excel robuste, structurez-le en 3 zones : en-tête, capacité, contenu du Sprint.
| Colonne | Type | Description |
|---|---|---|
| A. ID | Texte | Identifiant du Product Backlog Item (ex. PBI-142). |
| B. Titre | Texte | Intitulé court et orienté valeur. |
| C. Estimation | Nombre | Story points ou jours-personne. |
| D. Owner | Liste | Developer responsable principal. |
| E. DoR | Booléen | Definition of Ready respectée ? (Oui/Non). |
| F. Sprint Goal lié | Texte | Comment l'item contribue au Sprint Goal. |
| G. Dépendances | Texte | Équipes / systèmes externes. |
| H. Risques | Texte | Risque technique, métier, juridique. |
| I. Statut | Liste | À faire / En cours / En revue / Done. |
Ajoutez en haut du fichier un bandeau capacité : nombre de jours ouvrés, congés, support, capacité nette. Une simple cellule =SOMME(C2:C50) compare la somme des estimations à la capacité — le code couleur (vert / orange / rouge) suffit à prévenir le sur-engagement.
Template Sprint Planning Google Sheets
Google Sheets reprend exactement la même structure que la version Excel, avec deux avantages : collaboration temps réel pendant le Sprint Planning Meeting et historique automatique des modifications. C'est le Sprint Planning Google Sheetsidéal pour les équipes distribuées.
Quelques ajouts utiles spécifiques à Google Sheets :
- Validation de données : restreindre la colonne « Statut » à une liste fermée (À faire, En cours, En revue, Done).
- Mise en forme conditionnelle sur la capacité : rouge si la somme des estimations dépasse la capacité nette.
- Filtres dynamiques par Developer pour vérifier la charge individuelle sans surcharger qui que ce soit.
- Liens hypertextes directs vers les tickets Jira, Linear, GitHub correspondants.
Template Sprint Planning Word
Word reste pertinent dans deux situations : équipes qui doivent archiver leurs Sprint Backlog dans un SI documentaire ancien (GED, SharePoint on-prem), et organisations soumises à des contraintes réglementaires fortes (banque, santé, défense). Pour ces cas, un Sprint Planning Word simple suffit : 1 page, 8 sections numérotées.
| Section | Contenu | Longueur cible |
|---|---|---|
| 1. En-tête | Numéro de Sprint, dates, équipe, durée. | 3 lignes |
| 2. Sprint Goal | Phrase unique formulée par le PO. | 1 phrase |
| 3. Capacité | Capacité nette et hypothèses. | 5 lignes |
| 4. Product Backlog sélectionné | Tableau à 4 colonnes. | 1 tableau |
| 5. Plan | Approche, découpage, DoD rappelée. | 5 à 10 lignes |
| 6. Risques & dépendances | Liste à puces. | 5 à 10 puces |
| 7. Décisions | Décisions prises pendant l'événement. | 5 puces |
| 8. Actions | Tâches préparatoires post-événement. | 5 puces |
Template Sprint Planning PDF
Le Sprint Planning PDF est utile pour deux usages : version « lecture seule » archivée à la fin de l'événement, ou support imprimé pour les équipes qui aiment afficher leur Sprint Backlog au mur. La règle d'or : générer le PDF à partir d'un document Markdown, Excel ou Word — jamais saisir directement dans un PDF, par nature peu modifiable.
Pour fabriquer un PDF lisible, gardez :
- Une page maximum pour le Sprint Goal et la capacité.
- Une page pour le tableau des Product Backlog Items sélectionnés.
- Une page pour les risques, dépendances et décisions.
Exemple complet de Sprint Planning (Sprint Planning Example)
Mise en situation : l'équipe Scrum « CheckoutPro » développe le module panier-paiement d'un site e-commerce généraliste. Sprint de 2 semaines, équipe composée de 5 Developers, 1 Product Owner et 1 Scrum Master. Voici un exemple réaliste de Sprint Planning produit avec le template Markdown.
1. Contexte du Sprint
- Product Goal : atteindre un taux de conversion mobile de 3,5 % d'ici fin de trimestre.
- Sprint Goal : « Permettre à un visiteur mobile non connecté de finaliser un achat par carte bancaire en moins de 90 secondes. »
- Capacité : 10 jours ouvrés × 5 Developers = 50 jours-personne, -8 jours (congés + support) = 42 jours-personne nets.
2. Cinq Product Backlog Items sélectionnés
| # | Item | Estim. | Owner |
|---|---|---|---|
| PBI-201 | Refactor du panier en composant unique mobile-first. | 8 j | Léa |
| PBI-202 | Intégration Stripe Payment Element en checkout invité. | 10 j | Yann |
| PBI-203 | Validation côté serveur : adresse, CB, anti-fraude basique. | 8 j | Karim |
| PBI-204 | Mesure de la conversion via événements analytics. | 5 j | Marc |
| PBI-205 | Tests end-to-end Cypress sur les 3 parcours critiques. | 6 j | Sofia |
Total : 37 jours-personne engagés sur 42 disponibles. La marge de 5 jours couvre les imprévus (incidents production, support N3, refinement).
3. Décisions prises pendant le Sprint Planning
- PBI-202 est découpé en deux sous-livraisons fonctionnelles pour permettre une mise en production progressive en feature flag.
- La Definition of Done est étendue pour ce Sprint : ajout d'un seuil de performance Lighthouse mobile ≥ 90.
- Une dépendance avec l'équipe Anti-fraude est identifiée (PBI-203). Le PO contactera leur PO sous 24 h.
- La revue intermédiaire informelle est planifiée à mi-Sprint avec deux Product Managers du tunnel d'achat.
Checklist Sprint Planning
Cette Sprint Planning Checklist couvre les trois moments clés : préparation (avant le Sprint), animation (pendant l'événement), suivi (après le Sprint Planning). Le Scrum Master peut la diffuser au Product Owner et aux Developers la veille de l'événement.
| Quand | Action | Responsable |
|---|---|---|
| Avant le Sprint | Product Backlog raffiné jusqu'au niveau « prêt » sur 2-3 Sprints. | Product Owner |
| Avant le Sprint | Sprint Goal candidat formulé en 1 phrase claire et mesurable. | Product Owner |
| Avant le Sprint | Capacité estimée (congés, support, formations). | Scrum Master |
| Avant le Sprint | Definition of Done relue par tout le Scrum Team. | Scrum Master |
| Avant le Sprint | Outil de Sprint Planning (template) dupliqué et accessible. | Scrum Master |
| Pendant le Sprint | Rappel du Product Goal et du Sprint Goal candidat dès l'ouverture. | Product Owner |
| Pendant le Sprint | Sélection des Product Backlog Items par les Developers seuls. | Developers |
| Pendant le Sprint | Création du plan de livraison initial (au moins pour les premiers jours). | Developers |
| Pendant le Sprint | Identification explicite des risques et dépendances. | Scrum Team |
| Pendant le Sprint | Validation collective du Sprint Goal final. | Scrum Team |
| Après le Sprint | Sprint Backlog publié et accessible à tous les stakeholders. | Scrum Master |
| Après le Sprint | Première Daily Scrum positionnée le lendemain matin. | Scrum Master |
| Après le Sprint | Sprint Goal affiché visuellement (board, mur, en-tête de chaîne Slack). | Scrum Team |
Bonnes pratiques & erreurs fréquentes
La majorité des Sprint Plannings ratés partagent les mêmes anti-patterns. Le tableau ci-dessous résume les principales erreurs et la façon de les corriger en réutilisant votre template.
| Erreur | Conséquence | Correction |
|---|---|---|
| Pas de Sprint Goal | Sprint Backlog dispersé, Daily Scrum sans cap. | Le PO arrive avec un Sprint Goal candidat écrit. |
| Capacité ignorée | Sur-engagement systématique, dette croissante. | Renseigner la capacité dans le template avant la sélection. |
| Items pas prêts (DoR non respectée) | Refinement à chaud, événement qui s'éternise. | Bloquer le refinement régulier au moins une fois par semaine. |
| PO qui impose le Sprint Backlog | Les Developers se désengagent, le Sprint Goal n'est pas tenu. | Le PO propose la valeur, les Developers décident du combien. |
| Aucune trace écrite | Mémoire collective fragile, peu d'amélioration continue. | Utiliser un template (Markdown, Excel, Word, Notion). |
| Sprint Planning > 4h sur un Sprint de 2 semaines | Fatigue, baisse de qualité des décisions. | Vérifier le refinement, réduire l'agenda, respecter la timebox. |
Conseils inspirés de Scrum.org
- Why → What → How : la séquence officielle est pourquoi (Sprint Goal), quoi (Backlog Items), comment (plan). Le template doit refléter cet ordre.
- Le Sprint Backlog est vivant : il évolue tout au long du Sprint. Le template d'origine est une baseline, jamais un contrat figé.
- Les Developers possèdent le plan. Aucun manager, Product Owner ou Scrum Master ne dicte comment ils livreront le Sprint Goal.
- Un seul Sprint Goal par Sprint. Si vous formulez deux objectifs déconnectés, retravaillez-en l'un ou repoussez-le.
FAQ — Sprint Planning Template
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus fréquemment posées sur le Sprint Planning Template (Excel, PDF, Sheets, Word, Notion, Miro…).
À lire aussi
Source officielle : Scrum Guide 2020.