Qu’est-ce qu’un sprint planning ? Définition et déroulement

Comment fait-on avec les méthodes agiles pour décider de ce sur quoi on travaille si le périmètre du projet évolue constamment ? On découpe le projet en petites itérations, nommées sprints.

Et c'est précisément là qu'intervient le sprint planning, qui est l'événement le plus important de votre sprint. 

Dans cet article, vous allez découvrir tout ce qu'il y a à savoir pour comprendre la notion Scrum de sprint planning, et savoir quoi faire pour faire un sprint planning de qualité.

Qu'est-ce qu'un sprint planning ? Définition

Le sprint planning est un événement Scrum qui ouvre le sprint, et qui a comme objectif de définir l'objectif de sprint et de cadrer le travail à réaliser pendant celui-ci. Cette réunion dure 8 heures maximum pour un sprint de 4 semaines.

L'ensemble de l'équipe Scrum (Product Owner, Scrum Master, et équipe de développement) se réunit lors du sprint planning, et travaille de manière collaborative pour construire un plan d'action cohérent sur la durée du sprint, et permettant d'atteindre un sprint goal.

Le sprint planning est une réunion animée par l'équipe. Ce n'est pas le Product Owner qui dicte aux membres de l'équipe de développement quoi faire dans ce sprint. Il propose un objectif de sprint à l'équipe et lui donne du sens.

L'équipe collabore et discute pour affiner cet objectif de sprint, puis décider des éléments du Product Backlog à intégrer au Sprint Backlog, afin de les réaliser en cours de sprint et d'atteindre l'objectif de sprint choisi.

Pendant le sprint planning, l'équipe Scrum peut décider d'affiner certaines user stories, de faire un product backlog refinement, d'estimer la complexité de réalisation de certains éléments via le planning poker, ou encore d'intégrer de nouveaux items dans le backlog produit ou le backlog de sprint.

En bref, cet événement Scrum qui lance le sprint s'organise en trois temps. L'équipe Scrum doit ainsi répondre aux 3 questions suivantes :

1. Pourquoi ce sprint doit être fait ?
   
2. Qu'est-ce qui doit être fait pendant ce sprint ?
   
3. Comment ce travail doit être fait ?
   

A la sortie du sprint planning, l'équipe dispose d'un plan d'action concret pour livrer un incrément respectant l'objectif de sprint.

Avantages d'un sprint planning

Pourquoi fait-on un sprint planning au début de chaque sprint ? Pourquoi cette pratique est-elle aussi importante ? 

Pour plusieurs raisons :

• L'objectif de sprint est clairement défini.
  L'équipe de développement sait ainsi sur quoi elle doit être focus pour les semaines à venir. Ce sprint goal doit être une étape permettant l'atteinte du product goal.
  
• Le travail en cours de sprint est organisé.
  L'équipe de développement choisit les éléments sur lesquels travailler pour répondre à l'objectif de sprint, et détermine le meilleur plan d'action possible pour y arriver.
  
• Le sprint planning renforce la collaboration entre l'équipe de développement et le Product Owner.
  Malgré ce que certains vous diront, NON, le Product Owner ne dit pas aux développeurs quoi faire. Il propose, l'équipe de développement choisit. Cela renforce la collaboration et facilite les échanges et le dialogue.
  
• Le Product Owner donne du sens au travail à réaliser et au sprint.
  En agile, on ne fait pas quelque chose parce que c'est écrit. On donne du sens à ce qu'on fait, et on cherche à répondre à la question : "Pourquoi ?". Le Product Owner doit donc expliquer en quoi l'objectif de sprint choisi est pertinent, à quelle problématique cela répond, et ce que cela va apporter aux parties prenantes du projet.
  
• L'équipe de développement détermine la meilleure manière d'atteindre l'objectif.
  L'équipe de développement ne se contente pas d'appliquer un plan d'action choisi par quelqu'un d'autre, comme un architecte ou un avant-vente. Ses membres déterminent eux-mêmes ce qu'ils pensent être la meilleure manière de faire, en confrontant les points de vue.
  
• A la fin du sprint planning, toute l'équipe est confiante dans sa capacité à atteindre l'objectif.
  A la sortie du sprint planning, l'équipe Scrum dispose d'un plan d'action concret et parlant à tous. Tout le monde doit être en confiance dans sa capacité et la capacité de l'équipe à réussir son objectif de sprint.
  
• Les items sélectionnés sont découpés en tâches techniques et opérationnelles.
  Le sprint planning permet également à l'équipe de développement de découper en tâches techniques opérationnelles les éléments qui ont été positionnés dans le sprint backlog, et qui devront être réalisés en cours de sprint.
  
• Les éléments du Product Backlog et du Sprint Backlog sont affinés et estimés.
  Enfin, l'équipe peut également détailler des user stories ou des éléments des backlogs, ou encore estimer la complexité de réalisation de tel ou tel élément.
  

Qui participe au sprint planning ?

Tous les membres de l'équipe Scrum participent au sprint planning, sans exception : Product Owner, Scrum Master, et les membres de l'équipe de développement. Dans certains cas, l'équipe peut également inviter les parties prenantes du projet, pour renforcer la collaboration.

Par exemple, l'équipe de développement peut inviter les utilisateurs finaux du produit lros du sprint planning, afin de valider avec eux l'objectif de sprint et d'obtenir leur engagement et leur disponibilité pour le sprint à venir.

Si les parties prenantes du projet sont peu disponibles dans les prochaines semaines, ce n'est peut-être pas le meilleur moment pour lancer un sprint autour d'une fonctionnalité qui va nécessiter énormément d'échanges et de collaboration.

Qui organise et anime le sprint planning ?

Bien que le Product Owner a un rôle de leader lors du sprint planning Scrum, il n'en est pas l'animateur. C'est l'équipe Scrum au complet qui échange et collabore afin de faire émerger l'objectif de sprint et le sprint backlog contenant le travail à réaliser.

Le guide Scrum n'étant pas prescriptif sur le sujet, votre équipe peut très bien décider de donner l'animation du sprint planning au Scrum Master, au Product Owner ou à l'un des membres de l'équipe de développement.

Personnellement, je préfère éviter que le Product Owner anime la réunion, car on retombe trop souvent dans un schéma de chefferie de projet classique : Le Product Owner dicte, les autres appliquent.

Le sprint planning a obligatoirement lieu en début de sprint, toujours dans le même lieu et à la même heure. Il serait idiot de commencer à faire des actions dans le cadre d'un sprint sans avoir réfléchi au préalable à l'objectif qu'on souhaite atteindre et au plan d'action que l'on va dérouler pendant le sprint.

Quelle durée pour un sprint planning ?

Le sprint planning est un événement Scrum qui est décrit dans le guide Scrum et est timeboxé à 8 heures pour un sprint d'une durée de 1 mois.

Cela signifie que le sprint planning dure au maximum 8 heures (donc une journée de travail), pour un sprint de 4 semaines, et cette durée s'adapte proportionnellement pour des sprints plus courts.

Voici un tableau récapitulant la durée idéale du sprint planning en fonction de la durée de vos sprints.

Quand a lieu le sprint planning ?

Le sprint planning ouvre le sprint, et a donc lieu le premier jour du sprint, à la première heure.

Il n'est pas concevable de commencer à travailler sur quelque chose si l'objectif du sprint n'a pas été défini, et si l'on ne s'est pas mis d'accord sur la meilleure manière d'atteindre cet objectif.

Quel est le rôle du Scrum Master pendant le sprint planning ?

Pendant le sprint planning, le Scrum Master a plusieurs rôles :

• Il s'assure que le sprint planning se déroule correctement.
  Le Scrum Master s'assure que le sprint planning se déroule conformément à ce que dit Scrum. Il aide ainsi l'équipe à la mise en place de l'événement et vérifie qu'il est bien timeboxé.
  
• Il fait en sorte que l'équipe Scrum comprenne le but du sprint planning.
  Il explique ou réexplique à l'ensemble des membres de l'équipe Scrum quel est l'objectif du sprint planning, à savoir : cadrer le travail à réaliser dans le sprint.
  
• Il peut animer le sprint planning, bien que ce ne soit pas obligatoire.
  L'équipe Scrum peut décider de déléguer l'animation du sprint planning au Scrum Master. Mais ce n'est pas obligatoire. Le Product Owner ou un membre de l'équipe de développement pourrait aussi animer l'événement.
  
• Il donne des conseils et bonnes pratiques à l'équipe Scrum.
  Enfin, le Scrum Master répond aux questions de l'équipe, les coache, et leur prodigue conseils et bonnes pratiques.
  

Quel est le rôle du Product Owner pendant le sprint planning ?

Le Product Owner est un rôle crucial dans le sprint planning :

• Il propose à l'équipe un objectif de sprint à atteindre.
  Le Product Owner propose à l'équipe un objectif de sprint en fonction du travail déjà accompli et des derniers feedbacks remontés lors de la dernière sprint review, afin d'améliorer le produit et de maximiser sa valeur.
  
• Il présente le Product Backlog ordonnancé selon la priorisation et la valeur des différents items le composant.
  Il montre et détaille à l'équipe de développement les différents éléments composant le Product Backlog à date, en commençant par ceux apportant le plus de valeur ou ayant un rapport avec l'objectif de sprint.
  
• Il porte la voix des parties prenantes du projet.
  Il est le porte-parole du client et des utilisateurs finaux, et explique à l'équipe pourquoi le travail à réaliser est important et ce que ça va apporter aux utilisateurs finaux du produit.
  
• Il échange et collabore avec l'équipe de développement.
  Il collabore avec les développeurs tout au long du sprint planning afin qu'ils puissent construire leur sprint backlog, déterminer quoi faire durant le sprint, ainsi que la meilleure manière de le faire.
  
• Il peut animer le sprint planning.
  Enfin, le Product Owner peut animer le sprint planning, bien que je ne le recommande pas, afin d'éviter de retomber dans un schéma classique du "product owner tout-puissant", qui dicte aux autres quoi faire.
  

Comment se déroule un sprint planning ?

Un sprint planning se déroule en 9 étapes :

1. Le Product Owner propose un objectif à l'équipe.
   Le Product Owner propose au début du sprint planning un objectif de sprint à atteindre à l'équipe, en fonction des derniers retours obtenus lors de la sprint review du précédent sprint.
   
2. Si l'objectif n'est pas réalise, l'équipe cherche un compromis.
   Si les développeurs pensent que l'objectif n'est pas atteignable en 1 sprint, une discussion s'engage avec le Product Owner afin de retravailler l'objectif de sprint.
   
3. L'équipe de développement et le Product Owner regardent les éléments réalisables dans le cadre du sprint.
   Ils inspectent ensuite le Product Backlog afin d'identifier les items permettant de répondre au sprint goal. Ces élements sont "tirés" par l'équipe de développement afin de les intégrer au Sprint Backlog, et de les réaliser dans le cadre du sprint.
   
4. L'équipe de développement crée au besoin de nouveaux items dans les backlogs.
   Les développeurs ont tout loisir de créer autant d'items supplémentaires que nécessaires afin de réaliser l'objectif dans le sprint.
   
5. Le Product Owner et l'équipe de développement peuvent réaliser un backlog refinement, ou une estimation des user stories.
   Si nécessaire, une session d'affinage des récits utilisateurs, ou d'estimation de la complexité de réalisation (story points) peut être effectuée pendant le sprint planning.
   
6. L'équipe de développement détermine le nombre d'éléments à réaliser dans le cadre du sprint.
   Les développeurs choisissent quoi intégrer ou non dans le sprint, en fonction de l'objectif défini, de la vélocité de l'équipe calculée sur les précédents sprints, et du nombre de personnes présentes ou absentes pendant ce sprint.
   
7. L'équipe de développement présente un plan d'action concret au Product Owner et au Scrum Master afin d'atteindre l'objectif de sprint.
   Une fois le sprint backlog constitué, l'équipe détaille la meilleure manière de réaliser ce sprint, et soumet un plan d'action au Product Owner et au Scrum Master. Ce plan d'action pourra être revu et adapté lors des daily Scrum quotidiens.
   
8. Le Scrum Master challenge l'équipe de développement sur sa capacité à tout faire dans le sprint.
   Le Scrum Master s'assure que l'équipe sera en capacité de réaliser ce qu'elle a décidé de réaliser, en les challengeant sur le plan d'action ou sur leur capacité à faire et leur vélocité.
   
9. L'équipe Scrum procède à un vote de confiance avant de se séparer.
   Enfin, un vote de confiance à main levée est réalisé afin de déterminer le niveau de confiance (sur 5) de chacun dans la réussite de ce sprint et l'atteinte de l'objectif. S'il y a des notes basses (en-dessous de 3), il faudra les justifier et reprendre les éléments concernés en équipe avant de  clôturer le sprint planning.
   

Que se passe t-il après le sprint planning ?

A la sortie du sprint planning, l'équipe Scrum dispose d'un plan d'action concret et d'un objectif de sprint. Les développeurs commencent donc à travailler sur les éléments du sprint backog, afin de les transformer en incréments.

Pendant le sprint, l'équipe de développement tient une réunion quotidienne appelée daily Scrum, afin de faire le point sur ce qui a été fait, ce qui reste à faire, et d'adapter le plan d'action en conséquence.

Le sprint se terminera par deux réunions successives :

• La sprint review, permettent de montrer le travail réalisé et d'échanger avec le client.
• La rétrospective, permettant à l'équipe d'analyser ce qui s'est passé durant le sprint et de trouver des axes de progrès.
  

Le Product Owner peut-il imposer des user stories en sprint planning ?

Le Product Owner propose un objectif de sprint à l'équipe de développement pendant le sprint planning. Mais il ne peut en aucun cas imposer les éléments du product backlog à prendre en compte pour y répondre. C'est l'équipe de développement qui choisit.

Tout le sprint planning a été pensé dans Scrum de manière à renforcer la collaboration entre Product Owner et membres de l'équipe de développement.

Ainsi, le Product Owner propose un objectif de sprint, mais l'équipe peut le challenger, l'affiner, en proposer un nouveau, ou encore le négocier si elle juge qu'il est trop irréaliste.

Une fois le sprint goal défini, l'équipe de développement va alors choisir des éléments du product backlog permettant de répondre à cet objectif, et les intégrer à son sprint backlog.

De nouveaux items peuvent également être créés pendant le sprint planning, si ceux-ci permettent de répondre à l'objectif de sprint.

Seule l'équipe de développement peut décider de la quantité de travail à réaliser durant le sprint. Le Product Owner n'a pas son mot à dire, même si la somme des story points des éléments choisis ne correspond pas aux précédentes vélocités de l'équipe.

Peut-on commencer un sprint sans faire de sprint planning ?

Le sprint planning est un événement Scrum qui ouvre le sprint. Par conséquent, il n'est pas possible de commencer un sprint sans démarrer par un sprint planning.

De manière générale, c'est une mauvaise idée de se lancer tête baissée pour faire des choses sans réfléchir au pourquoi on le fait, et à la manière la plus efficace de le faire.

Si vous faites quand même des sprints sans avoir de sprint planning, alors vous ne faites tout simplement pas du Scrum.