Le sprint planning, c'est là où l'équipe décide quoi construire. Voici comment le mener efficacement, de la préparation du backlog au calcul de capacité.
Qu'est-ce que le sprint planning ?
Le sprint planning est l'événement Scrum qui ouvre chaque sprint : toute l'équipe Scrum y décide sur quoi elle va travailler et comment. Le Scrum Guide l'organise autour de trois sujets. Pourquoi ce sprint a-t-il de la valeur ? L'équipe s'accorde sur un objectif de sprint. Que peut-on réaliser pendant ce sprint ? Les développeurs sélectionnent des éléments en haut du Product Backlog, en s'appuyant sur leurs performances passées (leur vélocité) et sur leur capacité pour le sprint à venir. Comment le travail choisi sera-t-il réalisé ? Les développeurs découpent les éléments en unités de travail plus petites, souvent des tâches d'une journée ou moins. L'objectif de sprint, les éléments sélectionnés et ce plan forment ensemble le sprint backlog. L'événement dure au maximum huit heures pour un sprint d'un mois, et en général moins pour des sprints plus courts. Il fonctionne mieux quand le backlog a été affiné et estimé en amont, par exemple en Planning Poker : la réunion sert alors à choisir et à planifier, pas à découvrir les stories.
Qui participe ?
- Product Owner : présente les items du backlog par priorité et répond aux questions sur le périmètre et les critères d'acceptation.
- Développeurs : déterminent combien de stories ils peuvent s'engager à livrer en fonction de sa capacité et de sa vélocité passée.
- Scrum Master : facilite la réunion, respecte le timebox et lève les impediments.
Les trois rôles sont essentiels. Un sprint planning sans Product Owner mène à des incompréhensions de périmètre. Un sprint planning sans l'équipe complète mène à des engagements irréalistes.
Comment préparer le sprint planning ?
Le sprint planning n'est aussi bon que le backlog qui l'alimente. Le Product Owner doit s'assurer que :
- Les stories sont affinées : les critères d'acceptation sont rédigés, les dépendances identifiées, et l'équipe a déjà vu les stories au moins une fois (en refinement).
- Les stories sont priorisées : le haut du backlog reflète les priorités business actuelles.
- Les stories sont estimées : idéalement via une session de Planning Poker préalable ou une autre technique d'estimation.
Si plus de 20% des stories discutées en sprint planning sont "nouvelles" pour l'équipe, votre processus de refinement a besoin d'être amélioré.
Que se passe-t-il pendant le sprint planning ?
L'objectif de sprint répond au « pourquoi » (voir plus bas). Le « quoi » et le « comment » forment les deux parties de travail de la réunion.
Partie 1 : Quoi construire ?
Le Product Owner présente les stories prioritaires. Pour chacune :
- Le PO explique la valeur business et les critères d'acceptation.
- L'équipe pose ses questions de clarification.
- L'équipe décide si la story est prête à entrer dans le sprint.
- Si la story n'a pas été estimée, l'équipe l'estime avec Planning Poker ou une autre technique.
L'équipe tire des stories dans le sprint jusqu'à atteindre sa capacité. La capacité est basée sur la vélocité : le nombre moyen de story points complétés lors des derniers sprints.
Partie 2 : Comment le construire ?
Pour chaque story sélectionnée, l'équipe discute :
- Approche technique : décisions d'architecture, design d'API, changements de base de données.
- Découpage en tâches : diviser la story en tâches concrètes (design, implémentation, tests, review, déploiement).
- Dépendances : APIs externes, autres équipes, services partagés.
- Risques : inconnues, dette technique, préoccupations de performance.
Cette partie n'a pas besoin d'être exhaustive. Un plan de haut niveau suffit. L'équipe affinera l'approche en travaillant.
Combien de temps doit durer le sprint planning ?
Le Scrum Guide recommande un maximum de 8 heures pour un sprint d'un mois. En pratique :
| Durée du sprint | Durée du sprint planning |
|---|---|
| 1 semaine | 1-2 heures |
| 2 semaines | 2-4 heures |
| 3 semaines | 3-6 heures |
| 4 semaines | 4-8 heures |
Si votre sprint planning dépasse régulièrement ces limites, les causes les plus probables sont :
- Un refinement insuffisant en amont
- Des stories trop grosses à découper
- Des discussions de périmètre qui devraient avoir lieu en refinement, pas en planning
Combien de travail l'équipe doit-elle planifier ?
La capacité de l'équipe détermine combien de story points elle peut intégrer dans le sprint.
Utiliser la vélocité
La vélocité est le nombre moyen de story points complétés par sprint sur les 3-5 derniers sprints. Par exemple :
- Sprint 1 : 34 points
- Sprint 2 : 28 points
- Sprint 3 : 31 points
- Vélocité moyenne : ~31 points
L'équipe devrait planifier environ 31 points pour le prochain sprint. Ne planifiez pas à la vélocité maximale. Utilisez la moyenne ou un peu en dessous pour tenir compte de la variabilité. Notre guide de la vélocité en Scrum détaille le calcul, la différence avec la capacité et la prévision de release.
Ajuster la disponibilité
Réduisez la capacité quand :
- Des membres de l'équipe sont en congés ou malades
- Des jours fériés tombent dans le sprint
- Des membres sont partagés entre plusieurs projets
- Le sprint inclut de la dette technique ou du travail d'infrastructure
Formule simple : si l'équipe compte normalement 5 membres et qu'un est absent la moitié du sprint, réduisez la capacité planifiée d'environ 10%.
Quand estimer avec le Planning Poker ?
Le Planning Poker est le plus efficace quand il est utilisé avant le sprint planning, pendant le refinement. De cette façon :
- Les stories arrivent au sprint planning déjà estimées
- Le sprint planning se concentre sur la sélection et la planification, pas l'estimation
- La session est plus courte et plus concentrée
Si l'estimation n'a pas été faite en amont, intégrez-la dans la Partie 1 du sprint planning. Utilisez Planning Poker pour les stories que l'équipe n'a pas encore vues, et un consensus rapide pour le travail familier.
Consultez notre guide complet du Planning Poker pour le processus détaillé. Gardez les échéances et les avis sur la taille hors de la discussion jusqu'à ce que tout le monde ait voté : un chiffre prononcé trop tôt ancre toute l'équipe (voir le biais d'ancrage dans l'estimation).
Qu'est-ce qu'un bon objectif de sprint ?
Chaque sprint devrait avoir un objectif de sprint : une phrase unique qui décrit ce que le sprint va accomplir. L'objectif de sprint :
- Donne à l'équipe un but partagé au-delà d'une liste de tickets
- Aide à prioriser quand des compromis sont nécessaires en cours de sprint
- Fournit un signal clair de "terminé" pour les stakeholders
Exemple : "Les utilisateurs peuvent réinitialiser leur mot de passe par email" est un bon objectif de sprint. "Compléter les tickets PROJ-123, PROJ-124, PROJ-125" ne l'est pas.
Quelles sont les erreurs de sprint planning les plus courantes ?
1. Pas de refinement avant le planning
Si l'équipe découvre les stories pour la première fois pendant le sprint planning, la réunion durera deux fois plus longtemps et produira de moins bonnes estimations. Faites une session de refinement hebdomadaire pour préparer les stories 1-2 sprints à l'avance.
2. Sur-engagement
Les équipes sous pression planifient souvent plus que leur vélocité ne le permet. Cela mène à des sprints incomplets, une confiance érodée et une dette technique croissante. Planifiez de façon conservative. Finir en avance est mieux que de reporter du travail inachevé.
3. Ignorer la dette technique
Chaque sprint devrait réserver 10-20% de la capacité pour la dette technique, les corrections de bugs et le travail opérationnel. Si vous planifiez 100% de votre vélocité sur des nouvelles fonctionnalités, la qualité se dégradera avec le temps.
4. Le PO qui dicte le contenu du sprint
Le Product Owner priorise le backlog. L'équipe de développement décide combien elle peut s'engager à livrer. Cet équilibre est fondamental dans Scrum. Le PO ne devrait pas pousser l'équipe à prendre plus que sa vélocité ne le permet.
5. Sauter la Partie 2
Sélectionner des stories sans discuter du "comment" mène à des surprises en cours de sprint. Même une brève discussion technique de 5 minutes par story réduit significativement le risque.
Checklist du sprint planning
Avant la réunion :
- Le backlog est affiné et priorisé
- Les stories prioritaires ont des critères d'acceptation
- Les stories sont estimées (ou prévoir d'estimer pendant le planning)
- La disponibilité de l'équipe est connue pour le sprint
Pendant la réunion :
- Le Product Owner présente chaque story
- L'équipe pose ses questions de clarification
- L'équipe tire des stories jusqu'à la capacité (vélocité)
- L'équipe discute l'approche technique des stories sélectionnées
- L'objectif de sprint est défini
- Le sprint backlog est engagé
Après la réunion :
- Le sprint backlog est visible par tous (board, Jira, Trello)
- L'objectif de sprint est communiqué aux stakeholders
- L'équipe démarre le travail
Questions fréquentes
Combien de temps doit durer un sprint planning ? Le sprint planning dure au maximum huit heures pour un sprint d'un mois, selon le Scrum Guide, et en général moins pour des sprints plus courts. En pratique, beaucoup d'équipes en sprints de deux semaines y consacrent deux à quatre heures. Si la réunion déborde régulièrement, le backlog manque sans doute de refinement en amont.
Qui participe au sprint planning ? Toute l'équipe Scrum participe au sprint planning : le Product Owner, qui apporte le backlog ordonné et le contexte métier, les développeurs, qui choisissent le travail et planifient sa réalisation, et le Scrum Master, qui facilite. L'équipe peut aussi inviter d'autres personnes, comme des experts ou des parties prenantes, pour la conseiller.
Que produit le sprint planning ? Le sprint planning produit le sprint backlog. Selon le Scrum Guide, il réunit trois éléments : l'objectif de sprint, les éléments du Product Backlog sélectionnés pour le sprint et le plan des développeurs pour les livrer. L'objectif de sprint est le seul engagement ; le plan peut évoluer à mesure que l'équipe apprend pendant le sprint.
Le sprint backlog peut-il changer pendant le sprint ? Oui, le sprint backlog peut changer pendant le sprint. Les développeurs le mettent à jour à mesure qu'ils en apprennent davantage, et le périmètre peut être clarifié ou renégocié avec le Product Owner. La limite est l'objectif de sprint : aucun changement ne doit le mettre en danger. Si l'objectif devient obsolète, seul le Product Owner peut annuler le sprint.
Essayez Planning Poker pour votre prochain sprint
L'estimation est le fondement d'un bon sprint planning. Créez une session Planning Poker gratuite avec votre équipe et commencez à estimer en quelques secondes. Sans inscription.
