Le guide complet du sprint planning

Le sprint planning est un point clé du cadre Scrum, qui aide l’équipe à se préparer au sprint à venir. C’est l’événement qui marque le coup d’envoi du sprint. 

Alors, quand faut-il organiser la réunion de sprint planning ? Quels sujets y sont abordés ? Qui y participe ? Dans ce guide, nous répondons à toutes ces questions et vous donnons des conseils pour rendre cette réunion plus efficace.

Le sprint planning est l’un des cinq événements Scrum. Au cours de cette réunion, l’équipe discute des priorités et de l’objectif du sprint, c’est-à-dire ce qu’elle cherche à accomplir pendant le sprint. La réunion doit fournir suffisamment de contexte pour permettre à l’équipe de livrer l’incrément de sprint et d’apporter de la valeur aux parties prenantes d’ici la fin de l’itération. 

Comprendre les plans de sprint

Si l’expression « plan de sprint » est couramment utilisée pour désigner le résultat d’une séance de planification, il ne s’agit pas d’un terme agile officiel. Ce que les équipes élaborent en réalité, c’est le backlog du sprint, à savoir le plan en temps réel de l’itération. 

L’objectif de ce processus est de créer une roadmap comprenant à la fois les données d’entrée et les résultats attendus du sprint à venir. Les données d’entrée sont les facteurs qui déterminent la faisabilité du plan. Il peut s’agir de l’historique de la vélocité des sprints précédents et du nombre d’éléments du backlog achevés, des calendriers des congés de l’équipe, etc. Les résultats du sprint planning sont l’objectif du sprint et le backlog du sprint.

Les équipes qui n’utilisent pas la méthode Scrum peuvent organiser une réunion similaire appelée « planification d’itération ». Cette réunion vise aussi à aider l’équipe à évaluer la priorité et la faisabilité des tâches à venir et à définir un objectif pour l’itération.

La réunion de sprint planning a généralement lieu le premier jour du sprint, mais certaines équipes préfèrent l’organiser la veille.

Les principaux participants à la réunion de planification du sprint doivent être le product owner et les développeurs.

Le product owner est responsable de la définition des objectifs et de la finalité du sprint. C’est lui qui prend la parole en premier lors de la réunion pour présenter le travail à accomplir. Il faut garder à l’esprit que ce n’est toutefois pas lui qui impose le travail effectué lors du sprint : c’est l’équipe qui le sélectionne en fonction de ce qui est réalisable.

Les développeurs sont chargés de définir les modalités et le calendrier. Au cours de la deuxième partie de la réunion, ils commencent à structurer le travail présenté par le product owner. Pour ce faire, ils décomposent plus finement les tâches à accomplir et évaluent le niveau d’effort, la description et le format des éléments du backlog. Ils définissent ainsi le backlog du sprint, c’est-à-dire les éléments extraits du backlog produit, ainsi que les détails relatifs à leur traitement. 

Vous vous demandez peut-être qui dirige la réunion de sprint planning ? Eh bien, personne ne « dirige » la réunion. Les membres de l’équipe travaillent ensemble, sous la modération discrète du Scrum master. C’est à ce dernier qu’il revient de rétablir l’équilibre et de rappeler à l’équipe ce qui est réaliste, notamment si le product owner cherche à imposer des tâches ou si les développeurs n’avancent pas assez vite.

Le Guide Scrum recommande, pour un sprint d’un mois, de consacrer au maximum huit heures à la planification. Si vous effectuez un sprint de deux semaines, le temps alloué au sprint planning ne doit pas dépasser quatre heures. Autrement dit, « la règle générale est de prévoir deux heures de sprint planning par semaine de sprint ». 

Au-delà de la durée du sprint, d’autres facteurs peuvent influencer le temps consacré au sprint planning. Par exemple, depuis combien de temps l’équipe travaille-t-elle sur ce projet ? S’agit-il d’un nouveau projet ou est-il sur le point d’être achevé ? Un affinage efficace du backlog et une animation adéquate permettent également de réduire la durée des réunions (à trois heures ou moins). 

Une réunion de sprint planning de huit heures est souvent le signe d’une préparation insuffisante.

L’ordre du jour d’une réunion de sprint planning comprend généralement une introduction, un examen du backlog produit, la définition de l’objectif du sprint, la création du backlog du sprint, un examen du backlog du sprint et une conclusion.

Introduction

Au début de la réunion, le Scrum master peut présenter brièvement l’objectif et la durée prévue de la réunion. 

L’équipe peut également aborder l’organisation du prochain sprint ou de la prochaine itération, notamment les membres disponibles, les jours de travail de l’équipe, etc.

Examen du backlog produit

Ensuite, le product owner présente l’ensemble des éléments classés du backlog produit. C’est à ce moment-là que l’équipe clarifie le périmètre et la valeur, les critères d’acceptation ainsi que les éventuelles dépendances. Une grande partie de cette discussion a normalement eu lieu lors de l’affinage du backlog, mais de nouveaux éléments et de nouvelles informations ont pu apparaître depuis. 

Objectif du sprint

Au cours de cette phase de la réunion, les membres de l’équipe définissent ensemble un objectif général pour l’itération. Plutôt que de se concentrer sur un certain nombre de tâches, ils doivent identifier la valeur spécifique qu’ils entendent apporter aux parties prenantes. 

Création du backlog du sprint

Au besoin, l’équipe sélectionne les éléments du backlog produit qui contribuent à la réalisation de son objectif et les décompose en sous-éléments afin d’élaborer un plan. Elle doit identifier les dépendances, les risques et les obstacles potentiels, et planifier la manière dont le travail sera accompli au cours de l’itération.

Examen du backlog du sprint 

À ce stade, l’équipe passe en revue le backlog du sprint et s’assure que tout le monde est sur la même longueur d’onde. C’est le moment d’identifier les manques, les préoccupations ou les actions restant à traiter. 

Conclusion

Prévoyez quelques minutes pour bien clore la réunion. En évitant d’y mettre fin brusquement en plein milieu d’une discussion, vous aiderez l’équipe à avoir confiance dans le plan de sprint.

Prêt à aller au-delà des bases du sprint planning agile et à découvrir comment animer efficacement ces réunions ? Bryan Stallings et Jessica Guistolise, deux coachs expérimentés en agile, nous ont révélé leurs bonnes pratiques pour des sprint planning plus efficaces qui intéresseront particulièrement les Scrum masters !  

Préparer un backlog produit bien structuré et organisé 

Si vous abordez le sprint planning avec un backlog produit non affiné et non classé, vous risquez de vous retrouver dans une réunion interminable, consacrée à l’affinage du backlog. Les product owners devraient affiner et classer le sprint et demi (ou l’itération et demie) à venir avant de commencer le sprint planning. N’allez pas plus loin que cela, sinon l’équipe oubliera les discussions autour de ces éléments lorsque leur tour viendra. Visez plutôt juste ce qu’il faut, juste à temps.

N’oubliez pas que, même si vous arrivez avec un backlog bien défini et structuré, il se peut que des éléments supplémentaires, issus d’une revue ou d’une rétrospective de sprint, viennent s’ajouter au sprint. 

Donner à l’équipe accès au backlog produit avant le sprint planning

En plus de bien se préparer au sprint planning, il peut être utile de donner à l’équipe de la visibilité sur le backlog produit avant cette réunion afin de réduire la pression. Si elle n’a pas eu l’occasion d’examiner le backlog en amont, elle risque d’être prise au dépourvu lors de la réunion, ce qui peut entraîner une aversion au risque et des estimations surévaluées.

Pensez à utiliser un outil visuel comme Lucid pour partager votre backlog produit. Les membres de l’équipe peuvent y ajouter des post-its, des réactions émojis, etc., et ce support visuel pourra ensuite servir de source de vérité.

Exemple de backlog produit dans Lucidspark. Créer votre propre copie de ce modèle 

Définir des attentes réalistes avec le product owner

Une erreur courante chez les product owners consiste à reporter au sprint en cours le même nombre de tâches que lors du sprint précédent. Ils devraient plutôt présenter à la réunion l’équivalent d’une itération et demie. Ainsi, il y aura suffisamment de tâches à aborder et à intégrer au sprint au cas où des questions en suspens empêcheraient l’équipe de travailler sur certaines d’entre elles. Ou bien, si l’on estime que les tâches du sprint prendront moins de temps que prévu, le product owner disposera de tâches supplémentaires dans le backlog.

Tenir compte des activités hors développement

N’oubliez pas de prévoir du temps pour les activités autres que le développement, telles que les réunions, les formations et les autres tâches organisationnelles. Le fait d’intégrer ces activités aide l’équipe à établir un planning plus réaliste et à éviter de se surcharger.

Laisser l’équipe gérer le backlog de sprint

Le scrum master ne doit pas attribuer les tâches ni les éléments du backlog. Ce sont plutôt les membres de l’équipe qui doivent consulter le backlog du sprint et se demander :

• Y a-t-il une compétence que je souhaite développer ?

• Avons-nous quelqu’un qui excelle dans cette tâche ?

• Quel est le consensus sur la méthode à suivre ? 

Encourager les engagements réalistes

Les équipes ont souvent tendance à se surcharger lorsqu’elles débutent dans le sprint planning, soit parce qu’elles veulent faire plaisir, soit parce qu’elles ne sont pas suffisamment conscientes des dépendances extérieures à l’équipe. Si l’enthousiasme est toujours une bonne chose, un optimisme excessif quant à ce qui peut être accompli en un seul sprint peut nuire à l’équipe. Il est en effet plus difficile de reporter plusieurs tâches à la fin d’un sprint que d’en ajouter de nouvelles en cours de route si l’équipe en a la capacité. 

Pour éviter de se surcharger, il est important de garder à l’esprit la planification des capacités de l’équipe agile. Le Scrum master peut procéder à une mise au point en se référant aux sprints passés et en demandant à l’équipe d’« inspecter et d’adapter ». Concrètement, cela revient à demander à l’équipe d’examiner d’un œil critique ce qu’elle est en mesure d’accomplir et d’ajuster l’objectif du sprint et le backlog en conséquence. 

Instaurer un climat de sécurité et de confiance lors de la réunion

Les Scrum masters doivent contribuer à instaurer un climat de transparence et de communication ouverte lors de la réunion. Personne ne doit hésiter à faire part de ses préoccupations concernant sa charge de travail, à poser des questions ou à clarifier d’éventuels malentendus.

L’affinage du backlog relève généralement de la responsabilité du product owner et consiste à prendre connaissance des tâches à venir et à obtenir des réponses aux questions concernant les éléments du backlog produit avant de les présenter lors de la réunion de sprint planning. 

Bien que le Guide Scrum ne mentionne pas de réunion d’affinage du backlog, celle-ci est courante au sein des équipes. D’autres effectuent cette tâche de manière asynchrone.

Alors que le sprint planning vise à établir un plan pour les deux semaines à venir environ, l’incrément de programme (également appelé PI planning ou big room planning) est une session de planification générale destinée à orienter le travail de l’équipe pour les deux mois à venir. Le sprint planning offre une vision plus détaillée de la mise en œuvre du plan PI, sprint par sprint.  

Le PI planning n’est pas une exigence du Guide Scrum, mais il s’agit d’une bonne pratique pour les équipes et il est couramment utilisé lorsque plusieurs équipes travaillent ensemble sur un projet complexe. Les petites organisations ne comptant qu’une ou deux équipes Scrum n’ont pas besoin de PI planning.

Gagnez du temps et organisez des réunions de sprint planning cohérentes et dynamiques grâce aux modèles suivants proposés par Lucid, un logiciel de planification de sprint.

Modèle détaillé de sprint planning

Ce modèle regorge de ressources et guide les équipes à chaque étape de la planification du sprint. Avec les outils de facilitation, les cartes Lucid et les activités visuelles directement intégrées au modèle, vous pouvez vous assurer que votre équipe reste sur de bons rails, que le travail effectué est synchronisé avec votre outil de gestion de projet et que vous comprenez ce que pense l’équipe du plan de sprint proposé.

Cliquez sur l’image pour utiliser le modèle.

Modèle simple de sprint planning

Vous préférez une approche plus simple ? Ce modèle présente les étapes fondamentales dont les équipes ont besoin pour planifier un sprint.

Cliquez sur l’image pour utiliser le modèle.

Modèle de réunion de sprint planning et de salle d’équipe

Ce modèle reproduit l’ambiance d’une véritable salle afin de renforcer l’esprit d’équipe et la collaboration au sein de votre équipe.

Cliquez sur l’image pour utiliser le modèle.

Lucid peut vous aider à optimiser votre prochaine réunion de sprint planning, mais aussi tous vos événements agiles ! Grâce à des fonctionnalités conçues pour faciliter l’animation et la collaboration, à une zone de travail illimitée, à des modèles prêts à l’emploi et bien plus encore, Lucid simplifie la collaboration agile pour toutes les équipes, qu’elles soient hybrides, à distance ou en présentiel.