La réunion de planification du sprint, étape par étape

La réunion de planification de sprint est la réunion qui marque le début d’un sprint. Au cours de celle-ci, l’équipe s’accorde sur un objectif de sprint et détermine la part du backlog qu’elle est en mesure de mener à bien de manière réaliste — transformant ainsi une liste hiérarchisée en un plan auquel l’équipe adhère pleinement. Un backlog n’est qu’une liste de souhaits tant que personne n’a décidé de ce qui sera développé ensuite. C’est cette décision qui constitue la réunion de planification de sprint.

Si cela est bien mené, cela prend une heure ou deux et l’équipe repart en sachant ce qu’elle doit faire et pourquoi. Si cela est mal mené, cela se transforme en une séance de lecture du backlog où le Product Owner attribue des tickets et où tout le monde acquiesce — et cet « engagement » s’effrite discrètement dès le mercredi.

Pourquoi, quoi et comment

Le Guide Scrum articule la planification du sprint autour de trois questions, qu’il convient de conserver dans cet ordre :

• En quoi ce sprint est-il utile ? La réponse réside dans l’objectif du sprint : une phrase autour de laquelle toute l’équipe peut se rallier. Mettez-vous d’accord sur cet objectif avant de vous attaquer au backlog. Définir un objectif de sprint est un savoir-faire à part entière.
• Que peut-on réaliser au cours de ce sprint ? Les développeurs sélectionnent, parmi les éléments figurant en tête du backlog, ceux qui contribuent à l’objectif, jusqu’à ce qu’ils atteignent la limite de leur capacité. Il s’agit d’une prévision, et non d’une promesse faite sous serment.
• Comment le travail sélectionné sera-t-il réalisé ? L’équipe décompose les éléments prioritaires en un plan suffisamment détaillé pour pouvoir démarrer : tâches, approche, risques évidents. Il ne s’agit pas de détailler chaque élément jusqu’à la dernière sous-tâche, mais d’en faire suffisamment pour commencer en toute confiance.

Le résultat est un backlog de sprint : l’objectif, les éléments sélectionnés et le plan de mise en œuvre.

Définissez d’abord le périmètre, puis élaborez le plan

La meilleure habitude structurelle qui soit consiste à mener la planification en deux étapes distinctes plutôt qu’en une seule, floue.

La première partie concerne le périmètre. Le Product Owner présente l’objectif et les éléments candidats par ordre de priorité. L’équipe pose des questions pour obtenir des précisions, vérifie que chaque élément répond à la définition de « prêt », puis sélectionne le travail à traiter jusqu’à ce que sa capacité soit épuisée. Arrêtez-vous là. La tentation d’ajouter « juste une petite story de plus » est précisément ce qui conduit à un surchargement des sprints.

La deuxième partie consiste à établir un plan. L’équipe examine alors en détail les éléments qu’elle a sélectionnés : elle les décompose en tâches, identifie les dépendances et se met d’accord sur la répartition des tâches. C’est à ce stade que l’on découvre que l’histoire qui semblait valoir un « 3 » représente en réalité une semaine de travail, cachée derrière un critère d’acceptation vague.

En séparant ces deux aspects, on évite que la réunion ne tourne en rond entre « Devrions-nous intégrer cela ? » et « Comment pourrions-nous le mettre en œuvre ? » pour chaque point abordé.

Ce dont vous avez besoin dans la pièce

La planification du sprint ne fonctionne que si les éléments nécessaires sont déjà prêts. La réunion sert à transformer ces éléments en un plan ; elle ne les élabore pas sur le moment.

• Un backlog affiné et hiérarchisé. Les éléments prioritaires devraient déjà être bien compris et leur volume estimé de manière approximative. Si la réunion de planification est la première occasion pour l’équipe de découvrir une story, c’est que vous effectuez le raffinage du backlog lors de la mauvaise réunion — et celle-ci risque de s’éterniser. Le raffinage sert à alimenter la planification ; la planification, quant à elle, consiste à prendre des décisions.
• Un chiffre de capacité réel. Pas « deux semaines multipliées par la taille de l’équipe », mais les heures réellement disponibles après déduction des congés, des réunions, des rotations de soutien et des interruptions. Voir la planification de la vélocité et de la capacité.
• Toute l’équipe. Ce sont les développeurs qui établissent les prévisions ; ils doivent donc être présents. Une planification effectuée par procuration donne lieu à des engagements dont personne ne se sent responsable.

Qui en est responsable ?

Le Scrum Master anime la réunion : il veille au respect du délai imparti, veille à ce que les deux phases restent distinctes et empêche la réunion de dériver vers la recherche de solutions pour chaque cas particulier. Le Product Owner définit l’objectif et présente le backlog classé par ordre de priorité, et répond sur-le-champ aux questions « pourquoi » et « quoi ». Les développeurs décident de la charge de travail qu’ils souhaitent prendre en charge et de la manière dont ils vont la mettre en œuvre.

Ce dernier point est important : les prévisions relèvent de la responsabilité de ceux qui effectuent le travail. Un plan imposé d’en haut et accepté en silence n’est pas un engagement — c’est une simple liste d’attentes.

Combien de temps cela devrait-il prendre ?

Le Guide Scrum prévoit un temps maximum de huit heures pour la planification d’un sprint d’un mois, et proportionnellement moins pour les sprints plus courts — soit environ deux heures par semaine de sprint. Un sprint de deux semaines devrait représenter environ quatre heures, souvent moins une fois que l’équipe a trouvé un rythme régulier.

Considérez cela comme une limite maximale, et non comme un objectif. Les équipes qui ont systématiquement besoin de tout le temps imparti passent presque toujours du temps à affiner leurs plans pendant la réunion de planification. Améliorez les données d’entrée, et la réunion se raccourcira d’elle-même. Si vous souhaitez un détail minute par minute, le chapitre Ordre du jour de la réunion de planification de sprint en présente un.

Où cela tourne mal

Trois types de défaillances sont à l’origine de la plupart des réunions de planification infructueuses.

La séance de lecture. Le Product Owner présente les tickets et l’équipe écoute. Aucune décision n’est prise, car personne ne décide : il s’agit simplement d’un briefing. La planification doit donner l’impression que c’est l’équipe qui choisit, et non qu’on lui attribue des tâches.

Le surengagement. La capacité est considérée comme un objectif ambitieux. L’équipe prend sa meilleure cadence jamais atteinte comme seuil minimal et y ajoute un peu pour faire preuve d’ambition. Puis, un problème technique, un arrêt maladie et une tâche sous-estimée transforment le sprint en course effrénée. Prévoyez en vous basant sur un chiffre modeste, et non sur un chiffre héroïque.

Planifier sans objectif. L’équipe sélectionne un ensemble hétéroclite de tickets sans lien entre eux, et lorsque le sprint devient serré, il n’y a aucun critère permettant de déterminer lesquels abandonner — du coup, tout prend un peu de retard et rien n’est livré dans les meilleures conditions. C’est l’objectif qui vous indique quels tickets abandonner en cas de pression.

Préparez les données d’entrée, faites la distinction entre le périmètre et le plan, et laissez l’équipe s’approprier les prévisions. La suite de ce guide aborde chaque élément en détail — commencez par consulter l’ordre du jour ou téléchargez le modèle de planification de sprint.

Foire aux questions

Qu’est-ce que la planification de sprint ?

La planification de sprint est l’événement Scrum qui marque le début d’un sprint. L’équipe définit un objectif de sprint, sélectionne les éléments du backlog qu’elle prévoit de mener à bien et esquisse la manière dont le travail sera réalisé. Elle répond ainsi à trois questions : pourquoi ce sprint est-il utile, que va-t-on développer et comment ?

Combien de temps la réunion de planification du sprint devrait-elle durer ?

Prévoyez environ deux heures par semaine de sprint — soit environ deux heures pour un sprint d’une semaine, quatre pour un sprint de deux semaines, et jusqu’à huit pour un mois. Il s’agit d’un plafond, et non d’un objectif. Si vous avez systématiquement besoin de la totalité de ce temps imparti, cela signifie généralement que le backlog n’était pas prêt dès le départ.

Quelles sont les étapes clés de la planification d’un sprint ?

Vérifiez la capacité réelle de l’équipe pour le sprint ; convenez d’un objectif de sprint ; sélectionnez les éléments du backlog qui contribuent à cet objectif jusqu’à ce que vous atteigniez la capacité maximale ; décomposez les éléments prioritaires en un plan réalisable ; et assurez-vous que l’équipe adhère à cette prévision. Définissez d’abord le périmètre, puis élaborez le plan — dans cet ordre.

Qui anime la réunion de planification du sprint ?

Le Scrum Master anime la réunion et veille au respect des délais impartis. Le Product Owner fournit un backlog hiérarchisé et affiné, et en explique la raison d’être. Les développeurs décident de la charge de travail qu’ils peuvent assumer et de la manière dont ils vont la mettre en œuvre : c’est à eux qu’il revient d’établir les prévisions, et non au Product Owner de les attribuer.