Le sprint planning est la réunion qu'un équipe Scrum tient au début de chaque sprint pour répondre à trois questions : que livrera ce sprint (Sprint Goal), quels éléments du backlog entrent (Sprint Backlog), et comment chacun sera construit (découpage et approche). À la fin de la réunion, l'équipe démarre avec un objectif de sprint clair et une liste de tâches exécutable.
La version 30 secondes
- Fréquence : une fois par sprint, fixée au premier jour de l'itération ;
- Durée : sprint de deux semaines → 2 h maximum ; sprint d'une semaine → 1 h ;
- Participants : toute l'équipe Scrum — développeurs, Product Owner, Scrum Master ;
- Résultat : 1 Sprint Goal + 1 Sprint Backlog (découpé en tâches exécutables) ;
- Critère de réussite : à la sortie de la réunion, chaque membre peut dire de mémoire « voilà ce qu'on construit ce sprint-ci. »
Où se situe le sprint planning dans le cycle
Sprint Planning (jour 1)
↓
Daily Standup × 9 jours
↓
Sprint Review (démo) + Sprint Retrospective
↓
Sprint Planning suivant
Le planning consomme les produits de l'étape précédente : le Product Backlog et les actions d'amélioration de la dernière rétrospective. Comment les deux réunions s'articulent : voir le guide de la sprint retrospective.
La préparation avant la réunion (la moitié de son efficacité)
| Élément de préparation |
Responsable |
Standard |
| Product Backlog trié |
Product Owner |
Les candidats du haut sont assez clairs — pas besoin d'expliquer le contexte en direct |
| Candidats affinés |
Product Owner + équipe dev |
1,5 à 2× la capacité du haut de liste est découpé/estimé |
| Capacité de l'équipe calculée |
Scrum Master |
Jours-homme effectifs après congés, réunions et astreintes |
| Report du sprint précédent tranché |
Équipe dev |
Éléments inachevés : retour au backlog ou intégration à ce sprint — décidé avant la réunion |
| Definition of Done prête |
Équipe |
Tout le monde s'accorde sur ce que « terminé » signifie |
Sans backlog préparé, le planning devient une réunion de clarification des besoins — la cause la plus fréquente de dépassement.
Modèle d'ordre du jour (exemple 2 h pour un sprint de deux semaines)
| Heure |
Séquence |
Ce qui se passe |
| 0:00–0:10 |
Fixer l'objectif |
Le PO propose le résultat métier visé ; l'équipe converge vers un Sprint Goal en une phrase (ex. « les admins peuvent exporter les rapports ») |
| 0:10–0:50 |
Choisir les éléments |
Parcourir le backlog dans l'ordre : cet élément entre-t-il ? Soustraire jusqu'à saturation de la capacité |
| 0:50–1:40 |
Découper les tâches |
Pour chaque élément retenu, découper des tâches de 0,5 à 1 jour et noter l'approche technique ; trancher sur place les risques techniques discutés |
| 1:40–1:55 |
Risques et dépendances |
Dépendances externes (API tierces, maquettes, autres équipes), planning d'astreinte, priorité des bugs connus |
| 1:55–2:00 |
Confirmer et s'engager |
Rappeler le Sprint Goal et la liste ; tout le monde confirme ; nommer les tâches de lancement du premier jour |
Comment calculer les trois entrées clés
1. La capacité
Jours-homme effectifs = membres × jours ouvrés − congés − charge des réunions − ajustement astreinte
Exemple : équipe de 5, 10 jours ouvrés, 3 jours de congés au total, réunions récurrentes ≈ 2 jours-homme → 45 − 3 − 2 = 40 jours-homme effectifs.
2. La vélocité
Prendre la moyenne ou la médiane des story points terminés sur les 3 à 5 derniers sprints (la médiane résiste mieux aux à-coups). Équipe nouvelle sans historique ? Estimer à partir de la capacité : 1 jour-homme ≈ 1 unité de travail utile, puis passer aux story points après deux sprints. Idées reçues sur la vélocité : voir la FAQ.
3. L'estimation
- Le Planning Poker est l'outil habituel : tous révèlent leur carte en même temps ; les éléments très dispersés sont discutés puis réestimés ;
- Règle de granularité : les éléments au-dessus de 8 points sont découpés avant d'entrer dans le sprint ;
- Les points estiment un effort relatif, pas des heures — ne jamais s'en servir pour évaluer individuellement les personnes.
Erreurs courantes et remèdes
| Erreur |
Conséquence |
Remède |
| Planifier à 100 % de la capacité |
Zéro marge ; un bug surprise fait tout capoter |
Planifier à 80 % de la capacité ; garder de la place pour les défauts imprévus et le coût de coordination |
| Le PO n'expose les besoins qu'à l'oral pendant la réunion |
La réunion devient une clarification des besoins |
Affiner les éléments avant la réunion ; pendant, confirmer — pas former |
| Choisir des éléments sans les découper |
Le « comment » s'improvise en plein sprint, trop tard |
Découper en tâches de 0,5 à 1 jour et valider l'approche technique |
| L'objectif est une liste d'éléments, pas un résultat métier |
L'équipe est redevable du « terminé », pas de l'« utile » |
Le Sprint Goal doit être une phrase orientée métier |
| Les bugs du sprint précédent jamais priorisés |
Le plan du nouveau sprint est chamboulé par des défauts surprise |
Trancher le sort des bugs reportés pendant la réunion (voir section suivante) |
Où rangent-on les bugs du sprint ?
Une partie souvent zappée du planning : quels défauts ce sprint traitera et dont la mécanique de triage tourne. À rendre explicite en réunion :
La liste des bugs reportés et leur sort (corriger / rétrograder / fermer) ;
Le flux des nouveaux bugs pendant le sprint : triage → qualification (P0 traité le jour même, P1 dans ce sprint, P2 au backlog). Méthode : le guide du bug triage ;
Une entrée unique pour les rapports de bug : les retours des testeurs ou utilisateurs doivent emporter étapes de reproduction, captures et erreurs Console — pas dispersés dans les groupes de discussion.
Le point 3 est le levier caché de la vitesse du sprint : un rapport complet permet au développeur d'attaquer tout de suite, sans allers-retours. L'approche BugCapturer : chaque soumission attache automatiquement une capture/enregistrement annoté, l'URL, l'environnement navigateur et les erreurs Console/Network (voir la fonction diagnostic), et les rapports sont poussés automatiquement dans un canal Slack / Microsoft Teams — au planning, on qualifie les défauts directement depuis les rapports du canal, sans brûler du temps de réunion à rétablir « c'était quoi, ce problème, au juste ? ».
FAQ
Q : Qu'est-ce qu'un sprint planning ?
R : La réunion de planification au début de chaque sprint en Scrum ; elle décide du périmètre (quoi) et de l'approche (comment), et produit le Sprint Goal et le Sprint Backlog.
Q : Qu'est-ce que le sprint planning vu par un business analyst (BA) ?
R : Le BA veille sur la testabilité et les critères d'acceptation : les éléments retenus portent des conditions d'acceptation et des cas limites explicites, et il traduit les besoins des parties prenantes en éléments de backlog.
Q : Combien de temps doit durer le planning ?
R : Règle empirique : 1 h maximum par semaine de sprint — sprint d'une semaine : 1 h, de deux semaines : 2 h. Les dépassements traduisent en général une affinage insuffisant en amont.
Q : Comment une équipe distancielle fait-elle son planning ?
R : Visio + tableau partagé (Jira/Linear/Trello) comme d'habitude ; pendant le découpage, écrire en parallèle sur un whiteboard collaboratif — environ deux fois plus rapide que de lire les éléments en série.
Q : À mi-sprint, on s'aperçoit que le plan était trop petit. Que faire ?
R : Ne rien fourrer en cours de sprint. Noter et prioriser au prochain planning ; l'urgent passe par la voie de triage P0.