Articles

Comment mener des réunions de Sprint Planning qui fonctionnent vraiment

Le Sprint Planning est la cérémonie Scrum qui lance chaque sprint. L'équipe décide quoi construire, pourquoi c'est important, et comment elle compte s'y prendre. Quand ça fonctionne, tout le monde repart aligné. Quand ça ne fonctionne pas, on se retrouve avec deux heures de confusion suivies de deux semaines de chaos. La plupart des équipes pratiquent le Sprint Planning (environ 86 % selon la Scrum Alliance), mais beaucoup le traitent comme une simple lecture du backlog plutôt qu'une véritable conversation de planification. Voici comment bien faire les choses.

Ce que le Sprint Planning produit concrètement

Le résultat du Sprint Planning est le Sprint Backlog, qui comporte trois parties :

• Un Sprint Goal, une déclaration concise expliquant pourquoi ce sprint est important
• Les éléments de backlog sélectionnés que l'équipe s'engage à terminer
• Un plan de livraison décrivant comment l'équipe compte transformer ces éléments en un incrément fonctionnel

Le Sprint Goal est la partie que la plupart des équipes oublient, et c'est pourtant la plus importante. Sans lui, le sprint devient un assemblage hétéroclite de tâches sans direction cohérente.

Qui doit être présent

Toute l'équipe Scrum participe :

Rôle	Ce qu'il fait lors du Sprint Planning
Product Owner	Présente les éléments de backlog priorisés, propose le Sprint Goal, négocie le périmètre
Scrum Master	Facilite la réunion, fait respecter le timebox, lève les blocages
Développeurs	Sélectionnent le travail qu'ils peuvent s'engager à réaliser, planifient l'implémentation, découpent les stories en tâches

Des experts métier ou des parties prenantes peuvent être invités lorsque leur avis est nécessaire, mais ils sont là en tant qu'invités, pas en tant que décideurs. Un anti-pattern courant : n'envoyer qu'un ou deux membres de l'équipe pour « représenter » les développeurs. Si les personnes qui font le travail ne participent pas à la conversation de planification, les engagements qu'on leur impose tiennent rarement.

La structure de la réunion

La réunion suit un déroulement naturel, de la définition de l'objectif à la planification des tâches.

1. Définir le Sprint Goal

   Le Product Owner propose pourquoi ce sprint est important et quelle valeur il doit apporter. L'équipe travaille ensemble pour affiner cela en un Sprint Goal clair. Si vous avez besoin d'un point de départ, essayez un générateur de sprint goal. Commencez ici, pas par le backlog. L'objectif donne une direction à tout le reste.

2. Vérifier la capacité

   Avant de sélectionner quoi que ce soit, vérifiez la disponibilité réelle. Qui est en vacances ? Qui est d'astreinte ? Une approche fiable : prenez la moyenne de la vélocité de vos trois derniers sprints avec un calculateur de vélocité de sprint, puis ajustez en fonction des changements de capacité connus.

3. Sélectionner les éléments du backlog

   Le Product Owner passe en revue les éléments les plus prioritaires (qui devraient déjà être affinés et estimés). Les développeurs sélectionnent ce qu'ils sont confiants de pouvoir terminer, compte tenu de leur capacité et de la Definition of Done. C'est une négociation, pas une attribution imposée d'en haut.

4. Découper en tâches

   Pour chaque élément sélectionné, les développeurs décomposent le travail en tâches plus petites, idéalement réalisables en une journée ou moins. C'est là que la complexité cachée et les dépendances remontent à la surface avant de devenir des surprises en milieu de sprint.

5. Confirmer le Sprint Backlog

   L'équipe passe en revue l'ensemble : Sprint Goal, éléments sélectionnés, plan de livraison. Chacun doit quitter la réunion en étant capable d'expliquer de quoi parle le sprint et sur quoi il travaille en premier.

Combien de temps cela doit-il durer

Le Scrum Guide fixe des maximums, pas des objectifs :

Durée du sprint	Temps de planification maximum
1 semaine	2 heures
2 semaines	4 heures
3 semaines	6 heures
4 semaines	8 heures

En pratique, la plupart des équipes qui font des sprints de 2 semaines terminent la planification en 60 à 90 minutes lorsque le backlog a été bien affiné au préalable. Si vous atteignez systématiquement la durée maximale, c'est un problème d'affinage, pas un problème de planification.

Où l'estimation s'inscrit dans le processus

C'est là que beaucoup d'équipes se trompent. L'estimation devrait avoir lieu avant le Sprint Planning, pendant l'affinage du backlog, et non au début de la réunion elle-même. Mike Cohn, le créateur du Planning Poker, identifie deux bons moments pour estimer :

1. Après les ateliers de rédaction de stories, quand un lot de 20 à 50 nouveaux éléments a besoin d'être dimensionné
2. Pendant les sessions d'affinage régulières, au fur et à mesure que les éléments sont clarifiés tout au long du sprint

Et un mauvais moment : au début du Sprint Planning. À ce stade, il est trop tard pour que le Product Owner ajuste les priorités en fonction des nouvelles estimations, et les développeurs qui basculent mentalement en mode exécution ont du mal avec le dimensionnement relatif de haut niveau. Quand le haut du backlog arrive au Sprint Planning déjà estimé, la réunion devient un exercice de sélection (« quelle part de ce travail estimé correspond à notre capacité ? ») plutôt qu'un débat sur les estimations. C'est la différence entre une session de 90 minutes et une session de 3 heures. Si votre équipe utilise le Planning Poker pour l'estimation, menez ces sessions pendant l'affinage. Des outils comme Kollabe prennent en charge l'estimation asynchrone pour que les équipes puissent estimer à leur rythme sans bloquer tout le groupe.

Les erreurs qui font dérailler le Sprint Planning

Un backlog mal préparé. Arriver en planification avec des stories vagues et non affinées est la cause numéro un de réunions longues et frustrantes. Si les critères d'acceptation ne sont pas clairs avant la réunion, ils ne le deviendront pas pendant celle-ci. Pas de Sprint Goal. Sans objectif, il n'y a aucun moyen de prendre des décisions d'arbitrage quand le périmètre se resserre. On se retrouve avec une liste de tâches déconnectées au lieu d'un sprint cohérent. Surengagement. Si vous reportez régulièrement 30 à 40 % du travail non terminé au sprint suivant, vous prenez plus que ce que l'équipe peut livrer. La plupart des équipes perdent 15 à 25 % de leur sprint en travail imprévu, réunions et tâches annexes. Intégrez-le dans vos calculs. Sauter le « comment ». Sélectionner des stories sans discuter de l'implémentation signifie que les surprises surgiront en milieu de sprint. Même cinq minutes de discussion sur l'approche permettent d'éviter la plupart de ces problèmes. Le traiter comme une réunion de suivi. Le Sprint Planning est tourné vers l'avenir. Si vous passez du temps à faire le point sur ce qui s'est passé lors du dernier sprint, cela relève de la sprint review ou de la rétrospective.

Améliorer le Sprint Planning au fil du temps

Si vous ne devez améliorer qu'une chose, concentrez-vous sur l'affinage du backlog. Le Scrum Guide recommande de consacrer 5 à 10 % du temps total du sprint à l'affinage. Quand les stories arrivent en planification avec des critères d'acceptation clairs, des dépendances identifiées et des estimations existantes, la réunion se déroule pratiquement toute seule. Au-delà de cela :

• Partagez les éléments candidats 1 à 2 jours avant pour que les développeurs puissent réfléchir aux approches en amont
• Commencez par le Sprint Goal, pas par le backlog. Il apporte du focus et facilite les décisions de périmètre
• Laissez les développeurs maîtriser le « comment ». Le Product Owner négocie ce qui sera construit, les développeurs décident comment
• Réservez de la capacité pour la dette technique. Les équipes expérimentées allouent jusqu'à 20 % de leur sprint aux bugs et au refactoring
• Intégrez les actions issues de la rétrospective. Si l'équipe s'est engagée à changer quelque chose lors du dernier sprint, cela doit apparaître dans le plan de ce sprint

Le Sprint Planning dans une vue d'ensemble

Le Sprint Planning est une cérémonie dans un cycle, et il fonctionne mieux quand les autres font aussi leur part. Les rétrospectives font émerger des améliorations de processus qui alimentent le plan du sprint suivant. Les sprint reviews révèlent les retours des parties prenantes qui façonnent les priorités. Les daily standups adaptent le plan au fur et à mesure que les choses évoluent. Et l'affinage du backlog prépare la matière première qui rend le Sprint Planning efficace. Quand le reste du cycle est sain, le Sprint Planning devient la réunion la plus courte, pas la plus longue.