Préparer et conduire une réunion utile grâce au Sprint Planning

Sur une mission récente, j'ai vu une équipe consacrer une bonne partie de son Sprint Planning à découvrir des tickets qu'elle aurait dû comprendre avant la réunion. Le problème n'était pas Scrum. Le problème était la préparation. Un Sprint Planning utile réunit toute la Scrum Team pour définir un objectif, prévoir le travail réalisable et construire le plan permettant aux Developers de produire un Increment conforme à la Definition of Done.

Qu'est-ce qu'un Sprint Planning ?

Le Sprint Planning est l'événement Scrum qui lance le Sprint. Toute la Scrum Team y travaille collectivement sur trois sujets : pourquoi le Sprint est utile, ce qui peut être réalisé et comment le travail choisi sera réalisé. Le résultat est le Sprint Backlog, qui comprend l'Objectif de Sprint, les éléments sélectionnés du Product Backlog et le plan de réalisation.

Cette formulation est importante, car le Sprint Planning n'est pas une réunion où un responsable distribue des tickets. Le Guide Scrum précise que le plan qui en résulte est créé par un travail collaboratif de toute la Scrum Team. Le Scrum Master aide la Scrum Team à comprendre et appliquer Scrum, mais il ne définit pas seul l'Objectif de Sprint et ne répartit pas les tâches entre les Developers.

Qui participe au Sprint Planning ?

La Scrum Team complète participe : Product Owner, Scrum Master et Developers. Le Product Owner veille à ce que les éléments importants du Product Backlog soient prêts à être discutés et explique la valeur recherchée. Les Developers évaluent ce qu'ils peuvent réaliser et construisent le plan de travail. Le Scrum Master facilite le cadre Scrum et aide à garder une réunion productive.

La Scrum Team peut inviter d'autres personnes lorsque leur expertise apporte un éclairage utile, par exemple sur une contrainte technique, réglementaire ou métier. Ces personnes conseillent l'équipe. Elles ne prennent pas les décisions à la place de la Scrum Team ou des Developers.

Quel est le rôle de chacun pendant la réunion ?

Le point à retenir ici est la responsabilité collective. Le Sprint Goal n'est pas « celui du Scrum Master », et les tâches ne sont pas distribuées comme dans un planning hiérarchique.

Comment préparer un Sprint Planning efficace ?

Un Sprint Planning se prépare avant la réunion. Le Product Backlog doit être suffisamment clair pour discuter des éléments susceptibles d'entrer dans le Sprint, tandis que les Developers doivent connaître leur disponibilité, les contraintes prévisibles et les dépendances connues. Cette préparation réduit le temps passé à découvrir le besoin au lieu de décider du Sprint.

Le Guide Scrum ne définit pas de « Definition of Ready » ni de checklist obligatoire avant le Sprint Planning. L'affinement du Product Backlog est une activité utile, mais ce n'est pas un événement Scrum formel. Atlassian recommande néanmoins de maintenir le backlog à jour et suffisamment affiné pour faciliter la planification.

1. Préparer les éléments du Product Backlog

Pour les éléments susceptibles d'être sélectionnés, vérifiez avant la réunion :

• le besoin utilisateur ou métier à traiter ;
• la valeur recherchée ;
• les principaux critères d'acceptation, lorsqu'ils sont utilisés par l'équipe ;
• les dépendances connues avec d'autres travaux, équipes, systèmes ou fournisseurs ;
• les risques et inconnues importantes ;
• la taille approximative du travail.

Les critères d'acceptation sont une pratique utile pour préciser ce qui doit être vérifié, mais ils ne font pas partie des éléments obligatoires définis par le Guide Scrum. La référence formelle pour déterminer si l'Increment est conforme reste la Definition of Done. Il faut donc éviter de transformer une checklist interne en nouvelle règle Scrum.

Une story trop grosse, ambiguë ou dépendante d'une décision encore inexistante mérite d'être clarifiée avant le Sprint Planning. Sinon, la réunion risque de devenir une séance de découverte technique.

2. Vérifier les dépendances

Une dépendance n'est pas forcément un bloqueur. Mais si une story ne peut avancer qu'après la livraison d'une API, une validation métier ou une intervention d'une autre équipe, la contrainte doit apparaître avant la prévision du Sprint.

Pour chaque dépendance importante, posez trois questions : de quoi dépend le travail, qui doit fournir cet élément et quand cette information ou cette livraison sera-t-elle disponible ? Cette vérification évite de remplir le Sprint Backlog avec un travail qui restera bloqué dès le premier jour. Atlassian recommande également d'identifier et de communiquer les dépendances afin d'améliorer la planification et de limiter les retards.

3. Calculer la capacité disponible

La capacité donne une estimation du temps réellement disponible pour travailler sur le Sprint. Elle ne doit pas être confondue avec la vélocité et ne constitue pas une règle Scrum officielle. C'est un outil pratique pour éviter de planifier comme si toute l'équipe était disponible à 100 %.

Une méthode simple consiste à calculer :

Capacité disponible = jours réellement disponibles × heures de travail ciblées par jour × nombre de Developers concernés

Exemple : quatre Developers disposent chacun de 8 jours réellement disponibles sur un Sprint et consacrent environ 6 heures par jour au travail planifiable. La capacité théorique obtenue est de 192 heures.

Ce chiffre n'est pas une promesse. Il faut ensuite tenir compte du support, des réunions, des incidents prévisibles, des formations ou d'autres activités qui réduisent la disponibilité réelle.

La vélocité historique peut servir de repère supplémentaire lorsque l'équipe utilise les story points. Elle ne doit pas devenir un quota à atteindre ni un indicateur individuel. Le Guide Scrum demande aux Developers de tenir compte notamment de leurs performances passées, de leur capacité à venir et de la Definition of Done pour établir leur prévision.

Astuce de Chloé. Affichez avant la réunion les absences, formations, astreintes et autres engagements connus. La discussion sur la capacité devient alors une vérification rapide plutôt qu'un calcul improvisé au milieu du Sprint Planning.

Quels sont les trois sujets officiels du Sprint Planning ?

Le Guide Scrum structure le Sprint Planning autour de trois thèmes : « Pourquoi ce Sprint est-il important ? », « Que peut-on faire durant ce Sprint ? » et « Comment le travail choisi sera-t-il réalisé ? ». Cette séquence donne d'abord une direction, puis un périmètre prévisionnel, puis un plan de réalisation.

1. Pourquoi ce Sprint est-il important ?

Le Product Owner présente la manière dont le produit pourrait gagner en valeur et en utilité pendant le Sprint. Toute la Scrum Team collabore ensuite à la définition de l'Objectif de Sprint, qui doit être finalisé avant la fin du Sprint Planning.

Un bon Sprint Goal décrit le résultat recherché plutôt qu'une simple liste de tickets.

Exemple : « Réduire les abandons lors du paiement sur mobile en simplifiant le parcours de commande. »

À l'inverse, « terminer les tickets 142 à 158 » ne constitue pas un objectif utile. Cela décrit un périmètre, mais pas la raison pour laquelle ce travail compte.

L'Objectif de Sprint joue ensuite le rôle de filtre. Si une demande apparaît pendant le Sprint, l'équipe peut se demander si elle contribue à l'objectif. Le périmètre peut évoluer et être clarifié ou renégocié avec le Product Owner, tant que l'Objectif de Sprint reste protégé.

2. Que peut-on faire durant ce Sprint ?

Les Developers sélectionnent, avec le Product Owner, les éléments du Product Backlog qu'ils pensent pouvoir réaliser. La discussion permet aussi d'affiner leur compréhension du travail et d'augmenter leur confiance dans la prévision.

Il ne s'agit donc pas de remplir le Sprint jusqu'à sa capacité maximale. Une prévision raisonnable vaut mieux qu'un Sprint surchargé dont une partie importante restera inachevée.

Le choix repose notamment sur la compréhension du travail, les performances passées, la capacité à venir et la Definition of Done.

3. Comment le travail choisi sera-t-il réalisé ?

Pour chaque élément sélectionné, les Developers planifient le travail nécessaire pour produire un Increment conforme à la Definition of Done. Le Guide Scrum indique que ce travail peut notamment être décomposé en éléments d'une journée ou moins, mais laisse la méthode à la discrétion des Developers.

C'est ici qu'il faut corriger une confusion fréquente : les tâches ne sont pas simplement réparties entre les membres par le Scrum Master ou le Product Owner. Les Developers construisent eux-mêmes le plan et décident de la manière de transformer les éléments sélectionnés en Increment de valeur.

Le plan n'est pas figé non plus. Le Sprint Backlog est mis à jour pendant le Sprint lorsque l'équipe apprend quelque chose de nouveau. L'objectif est de conserver une représentation honnête du travail restant.

La gestion des tâches reste donc compatible avec Scrum, à condition de ne pas transformer le Sprint Backlog en planning hiérarchique verrouillé.

Comment utiliser les story points pendant le Sprint Planning ?

Les story points ne font pas partie des règles obligatoires de Scrum. Lorsqu'une équipe les utilise, ils servent à comparer l'effort relatif de différents éléments en tenant compte notamment de leur taille, de leur complexité, des risques et des incertitudes. Ils ne correspondent pas directement à un nombre d'heures ou de jours.

Par exemple, une story évaluée à 8 points n'est pas nécessairement une story de « 8 heures ». Une autre story évaluée à 8 points peut demander davantage de temps calendaire, selon les personnes disponibles, les interruptions ou les dépendances. Les deux travaux sont simplement considérés comme proches en effort relatif selon l'échelle utilisée par l'équipe.

Le Planning Poker peut servir à faire émerger les écarts de compréhension, mais lui non plus n'est pas imposé par Scrum. Atlassian présente les story points comme une méthode d'estimation relative et rappelle qu'ils ne doivent pas servir à établir des calendriers détaillés ou à mesurer la productivité individuelle.

Quel ordre du jour utiliser pour un Sprint Planning de deux semaines ?

Le Guide Scrum fixe une durée maximale de huit heures pour un Sprint d'un mois. Pour un Sprint plus court, l'événement est généralement plus court. La règle « deux heures par semaine de Sprint » peut servir de repère pratique, mais elle ne doit pas être présentée comme une règle officielle de Scrum.

Pour un Sprint de deux semaines, voici un ordre du jour opérationnel de quatre heures maximum. Il s'agit d'un exemple d'organisation, pas d'une prescription Scrum.

Si le backlog est très bien préparé, la réunion peut être nettement plus courte. À l'inverse, un produit complexe ou une forte incertitude peuvent demander davantage de discussion, sans dépasser la timebox applicable.

Quels sont les livrables attendus à la fin du Sprint Planning ?

Le principal résultat de la réunion est le Sprint Backlog. Dans le Guide Scrum, celui-ci rassemble trois éléments : l'Objectif de Sprint, les éléments du Product Backlog sélectionnés pour le Sprint et le plan permettant de les livrer.

L'Increment lui-même n'est pas un livrable du Sprint Planning. Il est produit pendant le Sprint et doit respecter la Definition of Done pour être considéré comme utilisable.

Quelles erreurs rendent un Sprint Planning inutile ?

Certaines erreurs reviennent suffisamment souvent pour devenir de vrais anti-patterns.

• Découvrir le backlog en séance : si les besoins, dépendances ou inconnues majeures apparaissent pour la première fois pendant le Planning, la préparation est trop légère.
• Définir le Sprint Goal seul : le Product Owner apporte la valeur recherchée, mais l'Objectif de Sprint est défini en collaboration par toute la Scrum Team.
• Laisser le Scrum Master répartir les tâches : les Developers construisent leur propre plan de réalisation.
• Remplir le Sprint au maximum : la capacité n'est pas une cible à atteindre à tout prix.
• Convertir les story points en heures : un point est une mesure relative d'effort, pas une durée déguisée.
• Confondre vélocité et capacité : la première donne un repère historique, la seconde regarde la disponibilité prévisible du Sprint.
• Ignorer les dépendances : une story techniquement prête mais bloquée par une autre équipe n'est pas une prévision réaliste.
• Faire des critères d'acceptation une règle Scrum : ils peuvent aider à clarifier une story, mais la Definition of Done reste l'engagement formel lié à l'Increment.
• Planifier chaque heure du Sprint : Scrum traite des problèmes complexes. Le plan doit être assez détaillé pour démarrer, puis évoluer avec ce que l'équipe apprend.
• Utiliser les estimations pour évaluer les personnes : les story points servent à estimer le travail, pas à comparer la performance individuelle.

Le signal d'alerte le plus simple est celui-ci : si le Sprint Planning ressemble à une réunion où quelqu'un attribue à chacun sa liste de tâches, l'équipe s'est probablement éloignée de l'esprit du cadre Scrum. Le bon point de départ reste l'Objectif de Sprint, puis une prévision collective et enfin un plan construit par les Developers.