Le Sprint Planning est l'événement qui ouvre le sprint. La Scrum Team y traite trois sujets : pourquoi ce sprint a de la valeur, ce qui peut y être fait et comment le travail choisi sera réalisé. Il ne s'agit ni d'une distribution de tâches ni d'une promesse figée sur une liste de stories.
La Scrum Team formule un Sprint Goal. À partir du Product Backlog ordonné et de sa capacité disponible, les Developers prévoient les items qu'ils pensent pouvoir accomplir et construisent le Sprint Backlog. Pour un sprint d'un mois, la timebox maximale est de huit heures ; elle est généralement plus courte pour un sprint plus court.
Étape 1 : Préparer le backlog en amont
Le sprint planning commence avant la réunion. Le Product Owner doit avoir :
- Raffiné et priorisé les user stories du backlog (lors du backlog grooming)
- Rédigé des critères d'acceptation clairs sur les stories candidates
- Résolu les questions métier bloquantes
Une story arrivant au planning sans critères d'acceptation est une dette immédiate. L'équipe va perdre du temps à clarifier ce qui aurait dû l'être en amont, ou pire : elle va livrer quelque chose qui ne correspond pas aux attentes.
Un repère de préparation, pas une règle Scrum
Le Scrum Guide ne prescrit ni Definition of Ready ni quota de 10 % d'items « prêts ». L'objectif pratique est de disposer d'assez d'éléments compris, ordonnés et suffisamment petits pour discuter sereinement de l'objectif et du plan du sprint. Un backlog vide ou trop flou transforme le planning en clarification improvisée.
Étape 2 : Définir l'objectif du sprint
Avant de sélectionner les stories, l'équipe doit s'accorder sur un sprint goal : une phrase qui résume la valeur que le sprint doit délivrer. Par exemple : "Permettre aux utilisateurs de s'inscrire et de se connecter de façon autonome."
L'objectif du sprint est fondamental pour deux raisons :
- Il guide les décisions en cas d'imprévu ("cette story contribue-t-elle à notre objectif ?")
- Il donne du sens au travail de l'équipe en plus des tickets
Sprint goal vs liste de stories
Un sprint goal n'est pas une liste. "Terminer les stories US-42, US-43 et US-44" n'est pas un objectif, c'est un inventaire. Un bon sprint goal décrit un résultat observable pour l'utilisateur ou le métier, même si les stories sélectionnées changent légèrement en cours de sprint.
Étape 3 : Calculer la capacité de l'équipe
La capacité n'est pas simplement "nombre de jours × 8 heures". Il faut déduire :
- Les congés et jours fériés
- Le temps réunions hors sprints (stand-ups, interviews, formations)
- Un facteur de charge réaliste (généralement 60-70 % du temps disponible)
Si votre vélocité historique sur les 3 derniers sprints est de 42, 38 et 45 points, votre prévision raisonnable pour le prochain sprint est autour de 40 points : pas 50 parce que vous êtes optimistes.
Étape 4 : Sélectionner et découper les stories
L'équipe sélectionne les stories en partant du haut du backlog priorisé jusqu'à remplir la capacité. Pour chaque story :
- Le PO présente brièvement la story et ses critères d'acceptation
- L'équipe pose ses questions de clarification (max 5 minutes)
- Si la story dépasse 5-8 points et n'a pas été découpée, elle est scindée maintenant
- L'équipe identifie les tâches techniques nécessaires (en heures ou en sous-tâches)
Quand utiliser le planning poker ici ?
Le planning poker est idéal à cette étape si les estimations n'ont pas été faites lors du grooming. Chaque développeur vote simultanément pour éviter l'effet de mimétisme. Si les estimations sont déjà faites, contentez-vous de les confirmer ou d'ajuster si la story a évolué depuis le raffinement.
Étape 5 : Construire un plan collectif
Le Sprint Planning se clôture lorsque les Developers disposent d'un plan initial pour créer l'Increment et atteindre le Sprint Goal. Chacun doit pouvoir expliquer :
- la valeur recherchée par le Sprint Goal ;
- comment le travail prévu contribue à cet objectif ;
- quels risques ou dépendances devront être inspectés rapidement.
Le Sprint Backlog est une prévision élaborée par et pour les Developers. Il évolue à mesure qu'ils en apprennent davantage ; seul le Sprint Goal constitue leur engagement pour le sprint.
Rendre le Sprint Goal visible
Noter le Sprint Goal dans l'outil et le partager rend l'objectif commun visible sans transformer les items sélectionnés en contrat figé. Cette distinction protège à la fois la transparence et la capacité d'adaptation.
La durée idéale
Le Guide Scrum 2020 fixe une timebox maximale de huit heures pour un sprint d'un mois et indique que l'événement est généralement plus court pour un sprint plus court. Pour deux semaines, deux à quatre heures constituent un repère fréquent, à adapter au produit et à l'équipe.
Les 5 erreurs qui sabotent un sprint planning
1. Arriver sans backlog raffiné
Le planning n'est pas un atelier de conception. Si l'équipe passe plus de 20 % du temps à comprendre les stories (plutôt qu'à les planifier), le grooming a failli.
2. Planifier à 100 % de la capacité
Les imprévus existent toujours. Une capacité planifiée à 80-85 % laisse de la marge pour les bugs urgents, les questions inattendues, et les retards de dépendances externes.
3. Confondre estimation et planification des heures
Les story points estiment la complexité relative, pas la durée en heures. L'erreur est de demander "combien d'heures ça prend ?" au lieu de "quelle est la complexité relative ?" Les deux questions n'ont pas les mêmes réponses : ni les mêmes effets sur l'équipe.
4. Laisser une seule personne parler
Si le Scrum Master ou le PO monopolise le planning, l'équipe de développement n'est pas engagée : elle est assignée. Un bon planning est un dialogue où chaque développeur pose des questions, exprime des risques et propose des découpages.
5. Ne pas vérifier la Definition of Done
Rappeler la DoD en début de sprint planning : surtout avec les nouvelles recrues : évite les incompréhensions en fin de sprint sur ce qui compte vraiment comme "terminé".
Sprint planning en équipe distribuée
Les équipes remote ont les mêmes besoins, avec des contraintes supplémentaires : fuseaux horaires, connexions instables, difficulté à lire le langage corporel. Quelques adaptations :
- Partagez le backlog à l'avance : envoyez les stories candidates 24h avant pour que chacun arrive avec des questions préparées.
- Utilisez un outil de planning poker en ligne : les votes simultanés sont encore plus critiques à distance pour éviter l'influence sociale.
- Enregistrez le sprint goal par écrit dans votre outil, visible de tous, dès la fin du planning.
- Limitez la durée à 2h max : la concentration en visioconférence est plus fragile qu'en présentiel.
Sprint planning avec Manifst
L'assistant de sprint planning Manifst calcule les jours ouvrés du sprint, préremplit les membres actifs et permet d'ajuster leur disponibilité. Il affiche également la vélocité des trois derniers sprints et propose cette moyenne comme cible modifiable.
L'équipe choisit manuellement les tickets du backlog. Manifst additionne les points, signale les tickets sans estimation, les dépendances bloquantes, une concentration excessive de charge et un dépassement de la cible ou du ratio historique SP/JH.
Les points peuvent être ajustés dans le planning ; pour une estimation collaborative, une session de Planning Poker distincte reste disponible dans le même projet. Une fois le planning validé, les tickets sont rattachés au sprint et le kanban est prêt. Voir les sprints Manifst.
Essayez Manifst gratuitement et conduisez votre prochain sprint planning en moins de 2 heures.