Sprint Planning

Le Sprint Planning est la cérémonie d'ouverture de chaque itération Scrum qui réunit l'équipe de développement, le Product Owner et le Scrum Master pour planifier le travail des 1 à 4 semaines à venir. Cette session collaborative transforme les éléments du Product Backlog en un Sprint Backlog actionnable avec un objectif de sprint clair. Le Sprint Planning constitue le moment clé où l'équipe s'engage sur un ensemble de livrables réalistes alignés avec la vision produit.

Fondements du Sprint Planning

Deux questions centrales : 'Que peut-on livrer dans ce sprint ?' et 'Comment accomplir le travail sélectionné ?'
Durée time-boxée : maximum 8 heures pour un sprint d'un mois, proportionnellement réduite pour des sprints plus courts
Collaboration tripartite : Product Owner définit les priorités, équipe évalue la faisabilité, Scrum Master facilite
Engagement collectif basé sur la vélocité historique et la capacité disponible de l'équipe

Avantages du Sprint Planning

Alignement stratégique : garantit que chaque sprint contribue directement aux objectifs produit prioritaires
Engagement partagé : l'équipe s'approprie le périmètre négocié plutôt que de subir des affectations imposées
Réduction des risques : identification précoce des dépendances, blocages techniques et besoins de clarification
Prévisibilité améliorée : la pratique régulière affine les estimations et la compréhension de la vélocité
Transparence totale : toutes les parties prenantes comprennent ce qui sera livré et pourquoi

Déroulement d'une session

Une session de Sprint Planning efficace suit une structure en deux phases distinctes. La première partie se concentre sur la sélection des User Stories prioritaires du Product Backlog, tandis que la seconde décompose ces stories en tâches techniques concrètes.

sprint-planning-agenda.md

# Sprint Planning - Template d'Agenda

## Phase 1 : QUOI (3-4h pour sprint de 2 semaines)
- Review de l'objectif de sprint proposé par le PO
- Présentation des User Stories prioritaires (top 10-15)
- Questions de clarification sur les critères d'acceptation
- Sélection collaborative basée sur la vélocité
- Validation du Sprint Goal

## Phase 2 : COMMENT (2-3h)
- Décomposition des stories en tâches techniques
- Identification des dépendances et risques
- Assignation volontaire ou collective des tâches
- Vérification de la capacité d'équipe
- Création du Sprint Backlog dans l'outil (Jira, Azure DevOps...)

## Livrables
- Sprint Goal validé et visible
- Sprint Backlog complet avec estimations
- Definition of Done confirmée
- Dépendances documentées

Mise en œuvre d'un Sprint Planning efficace

Préparer le Product Backlog : le PO raffine les 10-15 premières stories avec critères d'acceptation clairs 48h avant
Vérifier la capacité : calculer les jours disponibles en soustrayant congés, formations et engagements externes
Définir le Sprint Goal : formuler un objectif inspirant et mesurable qui donne du sens au sprint
Sélectionner les stories : tirer du backlog jusqu'à atteindre 80-90% de la vélocité moyenne (garder une marge)
Décomposer en tâches : chaque story devient 3-8 tâches de moins d'une journée pour faciliter le suivi quotidien
Identifier les risques : noter explicitement les dépendances externes, les inconnues techniques et les points bloquants
Obtenir l'engagement : chaque membre confirme verbalement sa compréhension et son accord sur le périmètre

Conseil pro : La règle du 80%

Ne planifiez jamais 100% de votre vélocité théorique. Les équipes performantes visent 70-80% pour absorber les imprévus (bugs de production, clarifications nécessaires, sous-estimations). Cette marge évite le burn-out et permet de sur-livrer plutôt que de sous-livrer systématiquement, ce qui renforce la confiance des parties prenantes.

Anti-patterns à éviter

Sprint Planning qui devient une session d'estimation : le refinement doit avoir lieu en amont, pas pendant le planning
Product Owner absent ou non préparé : retarde la session et génère des engagements sur des stories mal comprises
Sur-planification : remplir 100% de la capacité ne laisse aucune marge pour l'imprévu et garantit l'échec
Assignation autoritaire : le Scrum Master ou le PO assigne les tâches au lieu de laisser l'équipe s'auto-organiser
Ignorer les dépendances : ne pas documenter les blocages externes crée des surprises en milieu de sprint

Outils et techniques associés

Jira, Azure DevOps, Linear : gestion du Sprint Backlog avec tableaux Kanban et burndown charts automatiques
Planning Poker (Scrum Poker) : technique d'estimation collaborative utilisant la suite de Fibonacci
Miro, Mural : tableaux blancs virtuels pour les équipes distribuées avec templates de Sprint Planning
Capacity calculators : feuilles de calcul pour estimer les jours disponibles réels par développeur
Story mapping : visualisation du parcours utilisateur pour prioriser les stories à forte valeur

Impact métier du Sprint Planning

Un Sprint Planning bien exécuté transforme l'incertitude en prévisibilité mesurable. Les organisations qui maîtrisent cette cérémonie constatent une réduction de 30-40% du gaspillage lié aux replanifications en cours de sprint et une augmentation de 25% de la satisfaction des Product Owners. En alignant systématiquement le travail technique sur la valeur métier, le Sprint Planning devient l'outil de gouvernance agile qui prouve que discipline et flexibilité ne sont pas contradictoires mais complémentaires pour livrer des produits qui répondent aux vrais besoins utilisateurs.