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 peut raisonnablement mener à bien, 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 précisément cette décision qui est prise lors de 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 où cet « engagement » s’effrite discrètement dès le mercredi.

Pourquoi, quoi et comment

Le Guide Scrum articule la planification de 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, en partant du haut du backlog, les éléments 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 se lancer 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 « encore une seule » petite story est précisément ce qui conduit à un surengagement 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, en les décomposant en tâches, en identifiant les dépendances et en se mettant d’accord sur la répartition des tâches. C’est à ce stade que vous découvrez que cette story, 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 place ? » 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 transforme ces éléments en un plan ; elle ne les élabore pas sur le moment.

• Un backlog affiné et hiérarchisé. Les éléments prioritaires doivent déjà être bien compris et leur ampleur estimée de manière approximative. Si la réunion de planification est la première occasion pour l’équipe de prendre connaissance d’une story, cela signifie que vous effectuez le raffinage du backlog lors de la mauvaise réunion, et celle-ci risque de s’éterniser. Le raffinage sert à alimenter le processus ; la planification 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 des intermédiaires donne lieu à des engagements dont personne n’assume la responsabilité.

Qui s’en charge ?

Le Scrum Master joue un rôle de facilitateur : 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 prennent en charge et de la manière dont ils vont la mettre en œuvre.

Ce dernier point est important : les prévisions reviennent à ceux qui effectuent le travail. Un plan imposé et accepté en silence ne constitue pas un engagement. Il s’agit simplement d’une liste d’attente.

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 un plafond, 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. Planifiez 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 doit durer la réunion de planification du sprint ?

Prévoyez environ deux heures par semaine de sprint ; cela correspond donc à peu près à deux heures pour un sprint d’une semaine, quatre heures pour un sprint de deux semaines, et jusqu’à huit heures pour un mois. Il s’agit d’un plafond, et non d’un objectif. Si vous avez systématiquement besoin de la totalité du temps alloué, 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.