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 le premier événement de chaque sprint dans le framework Scrum. Pendant cette réunion, l'équipe Scrum répond à deux questions :
- Quoi livrer dans ce sprint ?
- Comment le livrer ?
Le résultat est un sprint backlog : un ensemble de user stories que l'équipe s'engage à compléter, accompagné d'un plan pour les réaliser.
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.
- Équipe de développement : détermine combien de stories elle peut 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.
Avant la réunion : la préparation compte
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é.
Les deux parties du sprint planning
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.
Timebox
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
Calcul de capacité
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é.
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%.
Où le Planning Poker s'intègre
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é.
L'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.
Erreurs 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
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.
