Le Sprint Planning

Après la Rétrospective de Sprint (Sprint Retrospective) et le Daily Scrum Meeting, place à une nouvelle cérémonie: le Sprint Planning. Avant le début d’un sprint, l’équipe se réunit pour décider ensemble le contenu des développements du sprint à venir. Quels sont les enjeux de cette cérémonie et comment bien la mener?

Pourquoi un Sprint Planning?

Le point de départ du Sprint Planning, c'est de définir un objectif de sprint. Mais pour comprendre cette notion d'objectif, il faut remonter la pente du cycle de vie du produit. Pour atteindre la vision produit, c'est-à-dire la projection de ce que doit être le produit, le Product Owner structure une stratégie produit.

Autrement dit, il définit comment il peut accomplir cette vision. La stratégie se décline dans une roadmap pour piloter les évolutions du produit sur une période donnée (de quelques mois à plusieurs années).

Cela signifie que chaque sprint doit apporter sa pierre à l'édifice pour réaliser la vision. Les développements suivent donc un objectif de sprint. L’incrément produit, qui est le résultat concaténé du sprint et de tous les sprints précédents, représente la concrétisation de la vision.
Avoir un objectif de sprint permet à l'équipe de ne pas s'éparpiller dans différentes directions et de prioriser le travail sur un axe majeur. Également de faciliter la communication sur les avancées du produit.

💡Tips

Il est intéressant en tant que Product Owner de présenter régulièrement sa roadmap à l'équipe pour qu'elle puisse anticiper les problématiques à venir. Cela donnera de la visibilité à tous les membres de l'équipe.

Pour en savoir plus sur les autres cérémonies telles que la Rétrospective de Sprint et le Daily Scrum Meeting.

Des notions clés pour comprendre le Sprint Planning

A ce stade, il est intéressant d'introduire les notions de complexité, vélocité et capacité.

La complexité d'une User Story, c'est l'effort nécessaire pour la développer. Elle dépend des connaissances de développeur et des risques identifiés au moment de son estimation. Si vous souhaitez devenir un expert de l’estimation, c’est ici.

Chaque sprint, l'équipe de développement dispose d'une capacité. Elle prend en compte les disponibilités et les absences pour adapter la charge de travail au contexte du sprint. C'est sur la base de la capacité que l'équipe embarque des pièces de travail à réaliser pendant le sprint, afin de répondre au fameux objectif de sprint.

La vélocité, c'est la comparaison entre l'engagement pris en début de sprint et les éléments du backlog effectivement réalisés à la fin du sprint. Elle sert à l’équipe pour améliorer la prédictibilité du travail qu’elle peut accomplir par sprint. C’est sur la base de la vélocité passée qu’on peut ré-estimer la capacité pour les sprints suivants.

Le déroulé du Sprint Planning

Chaque sprint, l’équipe fixe un objectif. Le Product Owner présente sa stratégie produit en introduction de la cérémonie à l'ensemble de l'équipe pour donner un cadre à la prochaine période de travail. Cela servira de base à la définition de l’objectif de sprint. Parfois, il est connu avant le planning, car les User Stories sont étudiées durant les refinements, ce qui donne des indications sur les prochaines échéances.

Il est possible de discuter des répercussions de l'objectif de sprint sur le travail à accomplir et de le remettre en question. Il est vrai que le Product Owner est responsable du produit et de son backlog. Mais l'équipe toute entière est responsable du bon fonctionnement du produit. Par exemple, si la dette technique devient problématique, l'objectif de sprint pourra être adapté pour tenir compte de ce paramètre.

Une fois que l'objectif est fixé et validé par l'équipe, comment peut il-être atteint ? Il faut déterminer quelles User Stories ou quel autre élément du backlog seront embarqués dans le sprint.

Il est important de ne pas limiter le Sprint Planning au choix des User Stories. Certes, elles sont centrales mais pas nécessairement représentatives du travail de l'équipe pendant un sprint. Ce travail peut, par exemple, inclure la correction de bugs ou la réflexion sur des grands sujets techniques. En priorité, les pièces de travail intégrées seront celles qui permettront d'atteindre l'objectif de sprint. Puis en fonction de la capacité, d'autres éléments pourront être inclus dans le backlog de sprint.

Après la définition du backlog pour le sprint, les développeurs découpent les pièces de travail du sprint en sous-tâches techniques et s'attribuent ces différents éléments. Le Product Owner est invité à cette seconde phase, mais sa présence n'est pas obligatoire car sa valeur ajoutée est théoriquement faible dans cet exercice.

L’équipe est maintenant prête à débuter le sprint !

Que vaut l'engagement de l'équipe?

L'engagement de l'équipe se fait en connaissance de cause, autrement dit en prenant en compte les risques identifiés au moment du planning. Cela ne constitue en aucun cas une obligation de résultat.

L'équipe s'engage à donner le maximum pour atteindre l'objectif de sprint. Cela n'implique pas forcément de réaliser l'intégralité du travail prévu lors du planning. L'équipe sera jugée à l'aune de ce qu'elle a développé, découvert et appris à l'issue du sprint. Tant qu’elle atteint l’objectif de sprint, elle accomplit sa mission.

💡Tips

Plus une équipe se connaît, plus elle est capable de réduire le temps du sprint planning. Idéalement, si des refinements réguliers ont eu lieu, la première phase du planning (choix des pièces de travail) devrait durer moins d’une heure. Le coût d’une cérémonie longue sera justement un manque d’engagement et des discussions interminables.

A retenir

Le Sprint planning est une cérémonie essentielle, car c’est elle qui déterminera la qualité de ce qui sera produit pendant l’itération. Un planning bien et anticipé, c’est un sprint réussi.
Préparez-le autant que possible!