Le Sprint Planning (ou planification de sprint) est le premier événement de chaque Sprint en Scrum. Il donne sa direction au Sprint, aligne toute la Scrum Team sur un Sprint Goal commun et produit le Sprint Backlog. Ce guide complet, mis à jour pour 2026, est conçu pour devenir la meilleure ressource francophone sur le Sprint Planning et pour vous aider à réussir toutes les questions PSM I qui s'y rapportent.
- Product Goal
- Sprint Planning
- Sprint Goal
- Sprint Backlog
- Sprint
- Increment
Le Sprint Planning transforme le Product Goal en Sprint Goal, Sprint Backlog et Increment livrable.
Qu'est-ce que le Sprint Planning ? Selon le Scrum Guide 2020
Définition officielle
D'après le Scrum Guide 2020 : « le Sprint Planning initie le Sprint en posant le travail à effectuer pour le Sprint. Ce plan est créé par la collaboration de toute la Scrum Team. »
Autrement dit, le Sprint Planning est un atelier collaboratif qui transforme la stratégie produit (Product Goal) et le Product Backlog en un plan concret et exécutable pour les 1 à 4 semaines à venir.
Objectifs
- Définir un Sprint Goal unique et porteur de valeur.
- Sélectionner les Product Backlog Items qui contribuent à ce Sprint Goal.
- Construire un plan de livraison initial partagé.
- Aligner toute la Scrum Team sur le « pourquoi » du Sprint.
- Identifier les hypothèses, dépendances et risques connus.
Pourquoi cet événement existe
Sans Sprint Planning, le Sprint démarre sans direction. Les Developers travailleraient sur des éléments dispersés, sans engagement commun ni possibilité d'inspection cohérente lors du Daily Scrum. Le Sprint Planning matérialise l'empirisme Scrum : transparence, inspection, adaptation.
Pourquoi le Sprint Planning est indispensable
| Dimension | Valeur créée |
|---|---|
| Alignement | Toute la Scrum Team comprend et adhère au même objectif. |
| Prévisibilité | Un plan crédible permet aux stakeholders de savoir à quoi s'attendre. |
| Focus | Un Sprint Goal unique évite la dispersion pendant le Sprint. |
| Inspection | Le Daily Scrum peut mesurer les progrès vers un but clair. |
| Adaptation | Le plan (le Sprint Backlog) évolue au fil des apprentissages. |
Qui participe au Sprint Planning ?
Le Sprint Planning est un événement de la Scrum Team. Sa présence complète est requise.
| Rôle | Rôle pendant le Sprint Planning |
|---|---|
| Product Owner | Présente le Product Goal, propose un objectif de valeur, clarifie les PBI. |
| Developers | Évaluent la capacité, sélectionnent les PBI, construisent le plan. |
| Scrum Master | Facilite l'événement, garantit la timebox et le respect de Scrum. |
| Scrum Team (globale) | Co-construit et valide le Sprint Goal. |
Qui ne participe pas
Les parties prenantes externes ne participent pas par défaut. La Scrum Team peut inviter un expert (architecte, designer, expert métier) pour clarifier un point, mais aucun invité ne décide à la place de l'équipe.
Les entrées du Sprint Planning
Un Sprint Planning efficace repose sur des entrées de qualité. Le Scrum Guide cite explicitement le Product Backlog, le dernier Increment, la capacité prévisionnelle des Developers et leurs performances passées.
| Entrée | Rôle |
|---|---|
| Product Backlog | Fournit les PBI ordonnés et raffinés candidats au Sprint. |
| Product Goal | Rappelle l'objectif long terme du produit. |
| Definition of Done | Contraint la sélection en fixant les critères de « Done ». |
| Capacité prévisionnelle | Jours ouvrés × Developers − congés × focus effectif. |
| Vélocité historique (story points) | Aide à estimer combien les Developers peuvent prendre. |
| Retours du Sprint précédent | Sprint Review et Retrospective informent la sélection et le plan. |
| Dernier Increment | État réel du produit sur lequel le nouveau Sprint s'appuie. |
Indicatif uniquement. Scrum n'impose aucune formule ; l'objectif est d'aider les Developers à prévoir raisonnablement.
Les trois questions du Sprint Planning
Le Scrum Guide 2020 structure le Sprint Planning autour de trois sujets.
1. Pourquoi ce Sprint a-t-il de la valeur ?
Le Product Owner propose comment le produit pourrait augmenter en valeur pendant ce Sprint. Toute la Scrum Team collabore pour définir un Sprint Goal qui communique clairement pourquoi ce Sprint est précieux pour les parties prenantes.
2. Que peut-on réaliser pendant ce Sprint ?
En discutant avec le Product Owner, les Developers sélectionnent les Product Backlog Items qu'ils pensent pouvoir livrer, dans le respect de la Definition of Done. La sélection appartient aux Developers.
3. Comment le travail choisi sera-t-il effectué ?
Pour chaque PBI sélectionné, les Developers planifient le travail nécessaire : décomposition en tâches, dépendances, ordre d'exécution. Le Scrum Guide recommande des unités de travail suffisamment petites pour tenir en moins d'un jour.
| Sujet | Question | Responsable principal |
|---|---|---|
| Why | Pourquoi ce Sprint est-il précieux ? | Co-construit (PO propose, tous réagissent) |
| What | Que peut-on livrer ? | Developers (sélection) |
| How | Comment le livrer ? | Developers (décomposition) |
Activer les nouveaux utilisateurs pour les nouveaux utilisateurs mobiles, en réduisant le délai d'inscription.
Un bon Sprint Goal est orienté valeur, unique, mesurable et compris par toute la Scrum Team.
Déroulement étape par étape
Le PO rappelle la direction stratégique et l'objectif produit long terme.
Étape 1 — Présentation du Product Goal
Le Product Owner rappelle où le produit doit aller à moyen terme. Cela donne du sens au Sprint Goal qui sera défini.
Étape 2 — Sélection des Product Backlog Items
Les Developers examinent les PBI candidats au sommet du Product Backlog. Ils posent des questions au PO pour clarifier périmètre et attentes.
Étape 3 — Définition du Sprint Goal
Toute la Scrum Team formule ensemble un Sprint Goal. Il doit être unique, mesurable et compréhensible par les stakeholders.
Étape 4 — Découpage technique
Les Developers décomposent les PBI en tâches réalisables. Ce découpage peut rester macro pour les derniers PBI et sera affiné pendant le Sprint.
Étape 5 — Construction du Sprint Backlog
L'artefact final est constitué : Sprint Goal + PBI sélectionnés + plan initial.
Étape 6 — Validation collective
La Scrum Team confirme collectivement le plan. Le Sprint peut démarrer : Daily Scrum, développement, Sprint Review et Retrospective suivront.
- PBI-1 · Formulaire d'inscription simplifié
- PBI-2 · Validation email en un clic
- PBI-3 · Bandeau d'aide contextuel
Les livrables
| Livrable | Nature | Propriété |
|---|---|---|
| Sprint Goal | Engagement unique du Sprint (commitment). | Toute la Scrum Team. |
| Sélection de PBI | Product Backlog Items retenus pour ce Sprint. | Developers. |
| Plan d'action | Découpage initial en tâches, ordre, dépendances. | Developers. |
| Sprint Backlog | L'ensemble Sprint Goal + PBI + plan. | Developers. |
Quelle est la durée ? (Sprint Planning timebox)
Le Sprint Planning timebox est explicitement fixé par le Scrum Guide 2020.
| Durée du Sprint | Timebox max (Scrum Guide) | Durée typique observée |
|---|---|---|
| 1 mois (4 semaines) | 8 heures | 6 à 8 heures |
| 3 semaines | ≈ 6 heures | 4 à 6 heures |
| 2 semaines | ≈ 4 heures | 2 à 4 heures |
| 1 semaine | ≈ 2 heures | 1 à 2 heures |
Exemple complet de Sprint Planning
Prenons une équipe fictive travaillant sur une application bancaire mobile. Sprint de 2 semaines, 10 jours ouvrés, 6 Developers, 3 jours de congés cumulés, focus estimé à 70 %.
Contexte
- Product Goal : « Devenir la banque mobile la plus rapide à ouvrir un compte en Europe. »
- Vélocité moyenne : 32 story points par Sprint.
- Capacité prévisionnelle : (6 × 10) − 3 = 57 j·dev · 0,7 ≈ 40 j·dev de développement.
Product Backlog candidat
| Rang | PBI | Estimation |
|---|---|---|
| 1 | Formulaire d'inscription en 3 écrans | 8 SP |
| 2 | Validation d'identité automatisée (KYC) | 13 SP |
| 3 | Alerte SMS de sécurité | 5 SP |
| 4 | Reprise d'inscription interrompue | 5 SP |
| 5 | A/B test sur la page d'accueil | 8 SP |
| 6 | Migration ancien SDK analytics | 13 SP |
Décision
Les Developers, en discussion avec le PO, retiennent les PBI 1, 2, 3 et 4 pour un total de 31 SP, cohérent avec la vélocité. Les PBI 5 et 6 sont reportés au Sprint suivant.
Sprint Goal
« Permettre à un nouvel utilisateur mobile d'ouvrir son compte, KYC compris, en moins de 5 minutes. »
Sprint Backlog
Sprint Goal + les 4 PBI sélectionnés + un plan initial (les Developers découpent chaque PBI en 4 à 6 tâches). Le Sprint peut commencer.
Les erreurs fréquentes
| Erreur | Conséquence | Correction |
|---|---|---|
| Sprint trop chargé | Non-atteinte du Sprint Goal, dette, démotivation. | Se baser sur la capacité réelle, pas sur le souhait du PO. |
| Micro-management | Auto-management cassé. | Le SM protège l'espace de décision des Developers. |
| Le PO impose les tâches | Sélection non responsable. | Le PO propose, les Developers sélectionnent. |
| Absence de Sprint Goal | Sprint sans direction. | Bloquer le « What » tant que le « Why » n'est pas tranché. |
| Pas de discussion | Malentendus qui remontent en Sprint Review. | Poser des questions, clarifier les hypothèses. |
| Transformer le Sprint Planning en session d'estimation | Timebox explosée, plan pauvre. | L'estimation se fait au refinement. |
| Backlog non raffiné | Événement long et confus. | Investir dans le refinement continu. |
| Sprint Goal orienté livrables | Focus sur les tâches, pas la valeur. | Formuler un Sprint Goal orienté résultat client. |
Sprint Planning vs Product Backlog Refinement
| Critère | Sprint Planning | Refinement |
|---|---|---|
| Nature | Événement Scrum officiel. | Activité continue. |
| Timebox | 8 h max pour un Sprint d'un mois. | ≤ 10 % de la capacité (recommandé). |
| Objectif | Produire le Sprint Backlog. | Préparer les futurs PBI. |
| Fréquence | 1 fois par Sprint. | Régulière, tout au long du Sprint. |
| Sortie principale | Sprint Goal + Sprint Backlog. | PBI clarifiés, découpés, estimés. |
Le refinement alimente le Sprint Planning. Un backlog bien raffiné rend le Sprint Planning fluide et court. Voir Product Backlog Refinement.
Sprint Planning à distance
Sprint Planning à distance : les règles Scrum restent identiques, seuls les outils changent.
- Miro : atelier visuel, timeline, cartes PBI.
- Jira : sélection depuis le Product Backlog, création du Sprint Backlog.
- Azure DevOps : équivalent Microsoft, très utilisé en entreprise.
- Microsoft Teams / Zoom : visioconférence, sous-salles pour le découpage.
Conseils pour réussir son Sprint Planning
- Arriver avec un Product Backlog raffiné jusqu'aux 3 prochains Sprints.
- Rappeler le Product Goal avant toute discussion.
- Poser un Sprint Goal avant de discuter du contenu.
- Faire décider la sélection par les Developers.
- Découper les 3 premiers PBI en détail, laisser les suivants macro.
- Documenter les hypothèses et dépendances.
- Terminer dès que l'alignement est réel, pas à la fin de la timebox.
- Formaliser un Sprint Backlog visible par tous.
- Consulter la checklist complète Sprint Planning.
Les 15 pièges PSM I sur le Sprint Planning
10 questions PSM I corrigées
10 questions originales dans le style Scrum.org, avec correction détaillée. Ces questions n'ont pas été copiées de l'examen officiel.
À lire aussi
Source officielle : Scrum Guide 2020.