Sprint Planning Meeting : Définition, déroulement et conseils importants

Le coup d'envoi de chaque Sprint est le Sprint Planning Meeting. Il sert à définir la charge de travail de l'équipe Scrum pour le Sprint à venir. Comment le Sprint Planning Meeting doit être préparé par le Product Owner, qui y participe, comment il se déroule et ce que l'équipe doit prendre en compte - tu trouveras tout cela dans cet article.

Sprint Planning : Objectifs et participants de la réunion

Un Sprint Planning Meeting a deux objectifs. Après un Sprint Planning réussi :

• le Product Owner et l'équipe de développement sont d'accord sur l'objectif du Sprint (Outcome)
• et ils ont ensemble constitué le Sprint Backlog. Le Sprint Backlog contient tous les Product Backlog Items qui doivent être réalisés pendant le Sprint pour atteindre l'objectif du Sprint (Output).

Parfois, Outcome et Output sont également regroupés sous le terme MVP, Minimum Viable Product.

Qui invite au Sprint Planning ?

Le Product Owner invite l'équipe de développement et le Scrum Master à la session de Sprint Planning. S'il y a des parties prenantes qui souhaitent voir quel est l'objectif du Sprint et quels éléments du Backlog seront traités, le Product Owner les invite également.

Préparation du Sprint Planning Meeting

Pour que le Product Owner et l'équipe de développement atteignent les deux objectifs du Planning Meeting, certaines conditions préalables doivent être réunies. Les étapes de préparation suivantes sont donc indispensables avant le Sprint Planning en Scrum. Si tu travailles toi-même en tant que PO ou si tu te prépares actuellement au rôle de Product Owner, tu peux utiliser cette checklist ou les points listés ci-dessous.

• Le Product Owner a défini un objectif de Sprint (Outcome) et sélectionné les Product Backlog Items (PBIs) correspondants.
• Les PBIs sélectionnés ont été formulés avec suffisamment de détails – idéalement en collaboration avec l'équipe de développement, par exemple dans le cadre d'un Product Backlog Refinement.
• Les PBIs sélectionnés ont été classés dans l'ordre dans lequel l'équipe de développement les traitera. Les dépendances techniques sont prises en compte.
• L'équipe dispose d'une Definition of Done (DoD). Celle-ci fournit une compréhension commune de « quand quelque chose est terminé ».
• La capacité de l'équipe pour le prochain Sprint a été déterminée, par exemple en tenant compte de la vélocité moyenne des derniers Sprints et des éventuels congés planifiés de certains membres de l'équipe.

Le déroulement du Sprint Planning

Une fois le Sprint Planning préparé comme décrit, tu peux te lancer avec ton équipe Scrum dans le déroulement proprement dit. La réunion suit l'agenda de Sprint Planning suivant :

• Le Product Owner présente l'objectif de Sprint et les PBIs correspondants, et répond aux questions de compréhension de l'équipe. L'objectif de Sprint doit être documenté de manière bien lisible pour tous les membres de l'équipe sur le Sprint Backlog.
• Si les PBIs n'ont pas encore été estimés, vous devriez procéder à l'estimation maintenant. Si l'estimation a déjà eu lieu, ton équipe peut affiner l'estimation après la discussion détaillée sur la mise en œuvre.
• L'équipe fait une prévision auprès du Product Owner et des parties prenantes concernant les PBIs qu'elle livrera à la fin du Sprint conformément à la DoD rédigée collectivement. C'est ainsi que se forme le Sprint Backlog, qui doit documenter les PBIs auxquels l'équipe de développement s'est engagée et ceux qu'elle traitera éventuellement en plus.

Bien sûr, en Scrum, le Sprint Planning a aussi une timebox : la durée d'un Sprint Planning ne doit pas dépasser une journée (Timebox: 8 Stunden).

Distinction entre Sprint Planning 1 et 2

Notre conseil pratique : souvent, les équipes Scrum distinguent entre Sprint Planning 1 et 2 :

• Le Sprint Planning 1 traite la question : que voulons-nous aborder dans le prochain Sprint ?
• Le Sprint Planning 2 traite la question : comment voulons-nous l'aborder ?

D'ailleurs, la timebox des deux Plannings ne se divise pas en 4 heures chacun – au contraire, le Planning 1 est automatiquement assez court après un bon Refinement, tandis que la plus grande partie de la timebox est nécessaire pour le Planning 2.

Bien que ce ne soit pas obligatoire, certaines équipes de développement décomposent les Product Backlog Items en plus petits paquets de travail (Tasks) lors du Scrum Sprint Planning 2. Cette deuxième partie du Sprint Planning se déroule souvent sans le Product Owner.

Que doit encore prendre en compte une équipe lors de la planification de Sprint ?

Une équipe de développement ne pourra jamais travailler exclusivement sur les Sprint Backlog Items choisis pendant un Sprint, car dans tout environnement de travail agile, il y a des interruptions, de petites urgences et des demandes de support pressantes.

C'est pourquoi il est judicieux pour ton équipe de prévoir une sorte de marge dans les Sprints, qui prend en compte par exemple les activités suivantes :

• Résolution de problèmes opérationnels, par exemple si un serveur tombe en panne
• Correction de bugs critiques
• Support technique de premier ou deuxième niveau

De telles marges garantissent que le Scrum Sprint Planning produise un Backlog que l'équipe peut réellement accomplir, sans se laisser frustrer par les interruptions. De plus, nos études montrent que les équipes avec une marge deviennent plus performantes au fil du temps. Cela s'explique notamment par le fait que ces équipes atteignent plus souvent leurs objectifs de Sprint et vivent donc plus souvent des expériences de réussite.

Les résultats de la planification de Sprint

Si toi et ton équipe pouvez cocher les points suivants comme terminés, vous savez que votre planification de Sprint a été réussie et que vous avez tout bien fait :

• L'équipe Scrum a développé une compréhension commune de ce qui doit être accompli dans le prochain Sprint (objectif de Sprint).
• Grâce à la discussion au sein de l'équipe de développement, vous avez développé une compréhension commune de la manière dont les différents PBIs doivent être mis en œuvre.
• Vous avez créé un Sprint Backlog bien structuré, qui contient les PBIs dans l'ordre du Product Backlog, éventuellement même avec un découpage en tâches incluant les activités correspondantes.

La plus grande erreur lors du Sprint Planning Meeting

Certaines équipes de développement s'obstinent à créer le Sprint Backlog parfait en essayant d'identifier chaque petite tâche et de l'estimer avec une précision méticuleuse. Cela se produit généralement lorsque le management n'a pas encore pleinement compris la méthode de travail agile et exige de telles estimations « exactes ».

Comme une estimation trop précise lors du Sprint Planning Meeting fait perdre trop de temps, le Scrum Master doit veiller à ce que l'objectif réel du Planning ne soit pas perdu : à savoir sélectionner les bons PBIs pour le prochain Sprint et en discuter juste assez pour que l'équipe se sente prête à traiter les items.

Conclusion sur le Sprint Planning Meeting

Un Sprint Planning Meeting réussi repose sur une bonne préparation comme le Product Backlog Refinement. Le Sprint Planning Meeting fournit à son tour la condition préalable pour que chacun dans l'équipe sache ce qui doit être mis en œuvre et comment dans le prochain Sprint. Si le Sprint doit réussir et si l'équipe de développement doit traiter les PBIs avec succès et sans frustration, le Planning Meeting est absolument indispensable en Scrum.