Le sprint planning est la cérémonie Scrum la plus sous-estimée. Beaucoup d'équipes la réduisent à une liste de tâches distribuées au hasard. Pourtant, un sprint planning bien conduit est le facteur numéro un d'un sprint réussi — et d'une équipe qui tient ses engagements.
É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.
É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 au-delà des tickets
É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)
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.
Étape 5 : S'engager collectivement
Le sprint planning se clôture par un engagement collectif — pas du Scrum Master, pas du PO, mais de l'équipe de développement entière. Chaque membre doit pouvoir répondre "oui" à ces deux questions :
- Comprends-je ce que je dois faire cette semaine pour contribuer à l'objectif ?
- Crois-tu que cet engagement est réaliste ?
Un "oui" tiède vaut mieux qu'un "oui" forcé. Les équipes qui n'osent pas dire non en planning souffrent en revue.
La durée idéale
La règle Scrum officielle : 2 heures de planning par semaine de sprint. Pour un sprint de 2 semaines, 4 heures maximum. Avec un backlog bien raffiné, la plupart des équipes y arrivent en 2-3 heures. Si vous dépassez régulièrement, votre backlog manque de préparation.
Sprint planning avec Manifst
Manifst inclut un assistant de sprint planning qui calcule automatiquement la capacité de l'équipe, suggère les stories en fonction de la vélocité historique et permet de lancer une session de Planning Poker intégrée sans quitter l'outil. Une fois le planning validé, le sprint démarre en un clic et le kanban est peuplé automatiquement.