Qu’est-ce qu’une réunion de planification de sprint ?
Les équipes de développement de logiciels comptent sur les sprints pour les aider à suivre le rythme du déploiement de nouvelles versions de logiciels, appelées itérations. Avec des exigences concurrentes concernant ce qu’il faut inclure dans une itération, une équipe de développement doit être très claire sur ce sur quoi elle doit se concentrer pendant un sprint. Par exemple, certaines corrections de bugs doivent-elles primer sur le déploiement de nouvelles fonctionnalités, ou vice versa ?
Agile est également devenue populaire dans d’autres domaines et secteurs, car cette approche ciblée peut stimuler l’efficacité, la productivité et la qualité.
Avant qu’un sprint ne commence, l’équipe du projet participe à une session de planification de sprint. Cette session aboutit à deux décisions clés :
-
L’objectif du sprint : il s’agit de ce qui peut être livré pendant le sprint.
-
Le backlog du sprint : la liste des tâches à accomplir pendant le sprint pour atteindre cet objectif.
La planification de sprint est un exercice limité dans le temps, et se déroule généralement pendant une heure par semaine sur une période d’environ huit semaines.
La planification de sprint s’adapte à Scrum et à d’autres méthodes Agile
La planification de sprint joue un rôle important dans l’univers des méthodologies de développement Agile qui priorisent la réactivité, la flexibilité et l’amélioration continue, et cherchent à aider les organisations à exceller dans la gestion du travail dans un monde où les priorités et les marchés évoluent rapidement. Au fur et à mesure que les exigences des clients et la concurrence évoluent, la planification de sprint détermine le travail à accomplir ensuite.
Dans les logiciels, la planification de sprint détermine quelles modifications ou fonctionnalités de produit peuvent être livrées et comment les déployer le plus efficacement lors de la prochaine itération. Ce processus de planification garantit que l’équipe s’attaque à une quantité réaliste de travail et accomplit d’abord le travail le plus important. Après tout, il y a peu de choses qui peuvent être accomplies pendant un sprint sans compromettre la qualité.
La planification de sprint est également utilisée pour les méthodes Agile hybrides, telles que Scrumban, dérivé de Scrum et Kanban, le système de travail axé sur le visuel et orienté traction associé à Toyota. Scrumban combine des itérations de longueur fixe avec un processus de transmission standardisé, ce qui signifie que plus d’une équipe spécialisée peut travailler sur un seul élément de travail.
Pour comprendre le fonctionnement de la planification de sprint avec Scrum, il est utile d’abord de passer en revue les rôles et processus clés de la méthode. Pendant la planification du sprint, l’équipe du projet travaillera avec le product owner (la partie prenante clé de l’entreprise ou de l’organisation pour le produit) et est facilitée par un Scrum master (l’individu qui agit en tant que serviteur-leader en s’assurant que le processus coule, en coachant l’équipe et en aidant tout le monde à communiquer et à comprendre la mission).
Ces participants créent un backlog de sprint, qui est une liste de fonctionnalités ou de modifications tirées du backlog produit et qui seront développées et déployées à la fin du sprint. Le backlog de sprint est façonné par l’objectif du sprint, c’est-à-dire ce qui peut être livré pendant le sprint.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
« Une habitude super simple, mais très utile : expliquez toujours vos acronymes lorsque vous écrivez les objectifs du sprint, les feuilles de route et la définition de fini. Ne supposez jamais que tout le monde sait exactement de quoi il s’agit, surtout lorsqu’il y a de nouveaux arrivants dans l’équipe. Épargnez-vous beaucoup d’explications et l’obligation de retravailler. Les expliquer [les acronymes] vous oblige également à réévaluer la fraîcheur des concepts utilisés depuis longtemps. Vous (et votre équipe) souvenez-vous vraiment de ce qui est censé se passer du début à la fin dans votre flux E2E ? », demande-t-elle.
Vous souhaitez une approche plus agile de la gestion de projet ?
Découvrez tout ce qu’il y a à savoir sur la gestion de projet Agile, ainsi que des conseils pour vous aider à commencer à appliquer les bonnes pratiques Agile.
Obtenir le livre électronique gratuit pour appliquer mes bonnes pratiques Agile
Combien de temps une réunion de planification de sprint dure-t-elle ?
Les experts Scrum recommandent généralement de consacrer environ une heure à la planification de sprint pour chaque semaine du sprint, pour un total de huit heures au maximum. Les projets très complexes peuvent nécessiter plus de temps. Et cela peut prendre presque deux fois plus de temps selon la maturité de l’équipe Scrum.
Pour voir en quoi le temps qu’une équipe a passé ensemble est un facteur si important dans la détermination de la durée d’un sprint, nous allons examiner le travail du psychologue Bruce Tuckman qui, en 1965, a proposé l’idée que le développement de groupe se déroule selon des étapes définies :
-
Formation : lorsqu’une nouvelle équipe se réunit ou que de nouveaux membres sont intégrés à une équipe
-
Tension : quand ils commencent à se confronter sur la façon de travailler
-
Normalisation : lorsque les membres de l’équipe arrivent à un accord concernant les rôles et les relations de chacun au sein du groupe
-
Exécution : lorsqu’une équipe commence à trouver son rythme, ce qui maximise la productivité et réduit les frictions entre collègues
Il n’est donc pas étonnant que les équipes qui en sont encore aux premiers stades du développement aient besoin de plus de temps de planification pour arriver à un consensus que les équipes qui travaillent ensemble depuis plus longtemps.
Ce facteur d’acclimatation peut expliquer pourquoi la planification de sprint est considérée par certains critiques comme une perte de temps. À l’inverse, les experts Scrum disent que la planification de sprint est un précurseur essentiel de tout sprint. D’une part, la planification de sprint améliore l’efficacité d’un sprint et empêche les développeurs d’avoir les yeux plus gros que le ventre. Le processus crée également un consensus avec le chef de projet sur les livrables du sprint. De plus, cela donne aux développeurs Agile un sentiment d’autorité sur leur travail et les empêche d’avoir l’impression d’essayer constamment de concilier les exigences concurrentes avec leur propre capacité de travail.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
Définir l’objectif du sprint est essentiel à la réussite
Les experts disent que les efforts déployés dans la définition de l’objectif du sprint sont payants en aidant l’équipe à s’assurer que le sprint fournit un maximum de valeur à l’organisation et à ses clients.
L’équipe écrit l’objectif du sprint en collaboration avec le product owner, et l’énoncé de but est court (seulement quelques phrases).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Comme les objectifs en général, les bons objectifs de sprint sont SMART (spécifiques, mesurables, atteignables, réalistes et limités dans le temps). Par exemple, un bon objectif de sprint pour une équipe de développement de plateforme de freelancing en ligne pourrait être « Créer un générateur de rapports de revenus qui fournit une vérification des revenus de freelancing gagnés au cours d’une année d’imposition », ou« Créer une interface de messagerie multimédia au sein de la plateforme au lieu d’avoir des freelances et des clients qui s’appuient sur des services de messagerie tiers. » Les objectifs clairement énoncés permettent de communiquer facilement les objectifs et les progrès à ceux qui ne sont pas directement impliqués dans le sprint.
Une poignée de considérations entrent dans l’élaboration d’un objectif de sprint. Par exemple, comment les objectifs de niveau inférieur, conçus pour être atteints au sein d’un seul sprint, s’inscrivent-ils dans les objectifs stratégiques de haut niveau ou la vision à long terme d’un produit ? Quelles tâches du backlog produit sont pertinentes pour l’objectif de sprint et doivent être incluses dans le backlog de sprint ? Les objectifs de sprint sont-ils réalisables et réalistes en fonction du nombre de ressources et de développeurs disponibles ? N’oubliez pas de prendre en compte les jours fériés, les vacances des membres de l’équipe et les événements de l’entreprise lorsque vous vous penchez sur le temps disponible.
L’objectif de sprint n’est pas une simple formalité à accomplir, puis à laisser de côté une fois que le sprint est réellement en cours. En plus de définir la direction de tous les travaux à accomplir pendant le sprint, c’est également la norme selon laquelle la réussite d’un sprint est évaluée lors de l’examen post-sprint. Ainsi, il est payant d’avoir un objectif que l’équipe, compte tenu de ses ressources, peut réellement atteindre.
Définir le backlog sprint configure le plan de travail de l’équipe
Le backlog de sprint comprend une liste de tâches à accomplir pendant un sprint. Bien qu’il soit élaboré en collaboration par l’équipe Scrum et le product owner, ce dernier ne s’engage généralement pas dans le processus granuleux de planification de sprint. Par définition, les équipes Scrum s’auto-organisent, donc les membres de l’équipe dirigent le processus. Souvent, le product owner n’est pas en bonne position pour savoir comment l’équipe doit venir à bout des tâches. En fait, l’implication étroite du product owner dans cette partie de la planification peut même être contre-productive.
Au lieu de cela, le rôle du product owner consiste généralement à spécifier l’objectif du sprint, à préparer les éléments candidats pour le backlog de sprint, à indiquer les exigences pour ces éléments, et à négocier avec l’équipe de développement sur la composition du backlog jusqu’à ce que les deux parties parviennent à un consensus.
Bien sûr, le product owner se réserve le droit de poser des questions sur les éléments du backlog sprint, leur ordre et la façon dont ils sont censés être réalisés. L’équipe Scrum préparera à la fois une liste des éléments du backlog qu’elle s’engage à livrer et une liste des tâches et sous-tâches nécessaires pour accomplir ces éléments. Au cours du processus, l’équipe estime également la quantité d’efforts nécessaires pour terminer chaque élément du backlog, généralement en utilisant des termes abrégés, tels que les tailles de T-shirt ou les points d’effort.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
La quantité de travail pour un seul sprint doit rester gérable, généralement avec un temps tampon intégré. Il n’est pas rare que 20 % de la capacité de sprint soient alloués comme « temps creux ». Pour ce faire, les équipes utilisent un indicateur appelé vélocité de sprint, qui est la quantité de travail, en points d’effort, effectuée au cours d’un seul sprint. Généralement, vous utilisez des chiffres du sprint le plus récent ; cette pratique est appelée « météo de la veille », car on pense que la vélocité du sprint précédent est l’indicateur le plus précis du sprint suivant. La vélocité du sprint est ajustée en fonction de la disponibilité des membres de l’équipe et de la constitution de l’équipe Scrum.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
La planification de sprint peut être divisée en deux phases distinctes : la réunion « Quoi » et la réunion « Comment ». Au cours de la réunion « Quoi », l’objectif du sprint est défini, le backlog du sprint est créé, et la capacité de l’équipe est décidée. Au cours de la réunion « Comment », l’équipe Scrum crée la liste des tâches nécessaires pour terminer chaque élément du backlog. Dans les logiciels, ces tâches couvrent généralement la conception, la mise en œuvre, les tests et la documentation, et chacune ne doit prendre que quelques jours. Si une tâche prend plus de quelques jours, cela indique que les éléments du backlog du sprint sont trop importants pour le travail de sprint ; ils doivent peut-être être divisés.
Ensuite, l’équipe Scrum estime la quantité de travail en personnes requises pour terminer les éléments du backlog, et calcule la durée totale probable des activités du sprint. En fonction de la capacité de l’équipe Scrum, si les membres estiment qu’ils peuvent s’attaquer à plus (ou moins) de choses lors d’un sprint, ils peuvent demander un ajustement par itération pour augmenter ou réduire la portée du travail.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
Qui est présent pour les réunions Sprint ?
Une session de planification de sprint impliquera la contribution de trois parties prenantes principales : l’équipe Scrum, le Scrum master et le product owner.
L’équipe Scrum se compose des développeurs qui assument les rouages du projet. Pendant la réunion de planification du sprint, c’est le travail de l’équipe d’estimer et d’argumenter concernant ce qui peut et doit être pris en charge au cours d’un seul sprint. L’équipe Scrum s’engagera ensuite à atteindre les objectifs du sprint, à travailler sur le projet, et à s’assurer de la livraison d’une nouvelle itération qui répond aux exigences qui ont été énoncées lors de la planification du sprint.
Le Scrum master est un facilitateur, un intermédiaire et un coach pour l’équipe Scrum. Ce sont généralement des développeurs plus âgés et plus expérimentés qui comprennent comment le travail de l’équipe s’inscrit dans les objectifs stratégiques généraux, les objectifs à long terme et les relations avec les clients. Le Scrum master gère les relations externes de l’équipe (y compris la relation avec le product owner) et s’assure que l’équipe suit les principes du développement Agile. Lors de la session de planification du sprint, le Scrum master guide l’équipe Scrum pour définir des objectifs appropriés pour chaque sprint, en servant de négociateur entre les développeurs et le product owner.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
Le product owner est la principale partie prenante du projet, la personne ou la partie pour laquelle le projet est construit. La mesure dans laquelle le product owner s’implique dans la planification du sprint varie, mais il a tendance à ne pas intervenir en ce qui concerne la planification des tâches de niveau inférieur. Au lieu de cela, il se réserve le pouvoir d’indiquer l’objectif du sprint, de sélectionner et de hiérarchiser les éléments du backlog de sprint, et de spécifier les exigences d’acceptation pour chaque élément.
Quel est l’objectif de la réunion d’examen du sprint ?
Ironiquement, la planification du sprint commence par la fin du sprint précédent. À la fin de chaque sprint, organisez une réunion de révision, au cours de laquelle l’équipe Scrum passe en revue ce qu’elle a accompli et démontre comment les nouvelles fonctionnalités et fonctions fonctionnent.
Généralement, l’équipe Scrum, le product owner, le Scrum master, d’autres développeurs de l’organisation, la direction et d’autres parties prenantes assistent à l’examen du sprint. Faites en sorte que l’ambiance soit informelle et la conversation assez fluide.
Au cours de cette session, évaluez le travail de l’équipe par rapport à l’objectif de sprint qu’elle a défini lors de la réunion de planification du sprint. L’équipe a-t-elle accompli chaque élément du backlog du sprint ? Avez-vous réussi à atteindre l’objectif général du sprint ? Y a-t-il eu des leçons à appliquer au prochain sprint ?
Préparation d’une réunion de planification de sprint
Avant de vous lancer dans une réunion de sprint, il est bon de vérifier la feuille de route du produit. Ce document stratégique décrit l’évolution d’un produit au cours d’une longue série de sprints et d’itérations. Les éléments qui apparaissent finalement dans le backlog de sprint doivent être alignés sur la feuille de route du produit, il est donc bénéfique de bien avoir la feuille de route à l’esprit. Si les éléments du backlog de sprint ne sont pas alignés sur la feuille de route du produit, le produit risque de perdre sa direction.
Vous devez également organiser une réunion préalable à la planification avec des représentants de l’équipe Scrum, le Scrum master et le chef de projet. Cette réunion, organisée quelques jours avant la réunion principale de planification du sprint, donne à chacun l’occasion de nettoyer le backlog. Le nettoyage du backlog est le processus qui consiste à hiérarchiser, estimer, détailler et déterminer les critères d’acceptation des éléments du backlog. Il accélère la session de planification elle-même et permet une plus grande productivité pendant un sprint en faisant correspondre plus précisément la quantité de travail requise à la capacité disponible.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
« Je recommande d’ajouter un point de contrôle de mi-sprint ou une activité de nettoyage pour que l’équipe se réunisse avec le product owner afin de passer en revue les récits ajoutés au backlog du prochain sprint, poser des questions, et obtenir des éclaircissements bien avant la prochaine réunion de planification du sprint. [Faire] cela rendra votre planification de sprint beaucoup plus efficace et peut même diviser la durée par deux », explique-t-elle.
Télécharger le modèle de backlog produit – Excel
Télécharger le modèle de backlog de sprint – Excel
D’autres parties prenantes importantes peuvent tirer des bénéfices de leur présence à une réunion préalable à la planification, car cela donne à chacun l’occasion de s’assurer qu’il est satisfait de la hiérarchisation des éléments du backlog. C’est également le bon moment pour intégrer les concepteurs d’expérience utilisateur afin qu’ils puissent commencer à réfléchir à tous les changements de conception requis pour les éléments du backlog terminés.
Lorsqu’il s’agit d’utiliser des techniques pour déterminer la hiérarchisation des éléments du backlog, les corrections de bugs et les réparations de problèmes sont généralement les plus élevées dans le backlog de sprint. Une autre pratique courante consiste à utiliser la hiérarchisation de l’entreprise, dans laquelle vous vous demandez quel(s) élément(s) du backlog profitera/ont le plus à l’entreprise, et donc à leur attribuer la priorité la plus élevée. Il y a quelques facteurs possibles à examiner, comme le risque impliqué ou atténué par l’élément du backlog et le montant de la valeur commerciale qu’un élément est censé générer. Là où ces indicateurs font défaut, la méthode de hiérarchisation MoSCoW, qui hiérarchise chaque élément comme indispensable, essentiel, possible ou éventuel, peut également être une technique utile. Et, bien sûr, vous devez vous inspirer de l’expérience du Scrum master dans la hiérarchisation des backlogs : après tout, il est là en tant que conseiller pour l’équipe.
Une réunion préalable à la planification de ce type aide également le product owner à s’assurer que les éléments du backlog répondent à la définition de prêt de l’équipe, c’est-à-dire immédiatement exploitable. Étant donné que les sprints ne laissent pas beaucoup de place à la perte de temps, les équipes de développement auront un ensemble de critères pour les éléments du backlog qui indiqueront si les éléments sont prêts à être soumis au travail.
Généralement, vous préparez d’abord les éléments du backlog avec les valeurs les plus importantes pour la préparation. Pour une équipe typique travaillant sur des tâches typiques, la définition de prêt peut inclure tout ou partie des éléments suivants : des valeurs de points d’effort attribuées ; des interdépendances supprimées ; des exemples vérifiables en cours de création ; et des critères d’acceptation définis. Un acronyme simple pour expliquer une définition solide du prêt est INVEST : independent (indépendant), negotiable (négociable), valuable (précieux), estimable (estimable), small (petit), et testable (testable). Les récits validés à l’aide d’INVEST sont prêts à passer au backlog du sprint.
De même, le product owner peut gagner du temps pendant la réunion de planification en établissant des critères d’acceptation pour les éléments du backlog. Une description simple et objective de ce qu’une mise en œuvre d’un élément de backlog doit, devrait et pourrait accomplir accélérera les discussions sur les critères d’acceptation pendant la réunion de planification complète.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
Les étapes d’une réunion de planification de sprint
Voici comment se déroule la réunion typique de planification de sprint :
-
Brossez le tableau d’ensemble. Avant que la réunion ne commence, le Scrum master rappelle à l’équipe ce qu’ils essaient d’accomplir dans les grandes lignes et comment cela s’inscrit dans les objectifs stratégiques ou la feuille de route d’un produit. Il est également utile que le product owner soit prêt à parler de deux sprints d’éléments afin de contextualiser où le produit se dirige à moyen terme.
-
Mettre tout le monde au courant. Il est maintenant temps d’échanger toutes les informations que les personnes impliquées dans le sprint à venir devraient savoir. Les ajouts récents au backlog, les changements dans la disponibilité des membres de l’équipe ou les nouvelles contributions des parties prenantes pourraient tous être partagés à ce stade.
-
Présentez la vélocité cible pour le sprint à venir. La vélocité correspond au nombre total de récits utilisateur terminés au cours d’un sprint. Généralement, ce chiffre est dérivé du dernier sprint terminé (le principe de la météo de la veille). Si l’effectif, et non les chiffres, de l’équipe Scrum a changé depuis lors, utilisez la vélocité moyenne des trois derniers sprints. S’il s’agit du premier sprint de votre équipe, un bon chiffre approximatif est huit histoires par développeur et par sprint. Vous pourrez toujours ajuster cela plus tard.
-
Confirmez la capacité de l’équipe. La capacité de l’équipe est calculée en fonction du nombre total d’heures de travail que le sprint durera. Ainsi, pour une équipe Scrum de 10 personnes travaillant 10 heures par jour sur un projet de 10 jours, la capacité serait de 1 000 heures. Mais les équipes déduisent généralement 20 à 40 % de la capacité maximale pour donner un nombre plus réaliste qui prend en compte les temps d’arrêt, les frais généraux et les heures de travail perdues. De plus, étant donné les interdépendances inévitables entre les éléments de backlog, la capacité pratique peut être encore réduite par une sorte d’effet domino, dans lequel les tâches retardées repoussent celles qui les succèdent. Si vous vous attendez à ce que certains facteurs impactent la vélocité du sprint ou la capacité de l’équipe, enregistrez-les à ce stade.
-
Passez en revue la définition de fini. La définition de fini est un aperçu de ce à quoi ressemblera l’itération produite à la fin du sprint. Il est important que ceux qui effectuent le travail et ceux qui l’inspectent s’entendent sur une définition de fini avant le début du sprint.
-
Décidez quels éléments du backlog produit iront dans le backlog du sprint. À ce stade, l’équipe Scrum décidera également si certains éléments du backlog sont trop importants pour être terminés en un seul sprint et doivent être reportés.
-
Déterminez les besoins en ressources, définissez qui fera quoi, et estimez la charge de travail. S’il y a plus de travail que l’équipe Scrum ne peut en gérer raisonnablement, cela deviendra évident pour le Scrum master à ce stade. Attribuez le travail et assurez-vous que les tâches des individus correspondent à leur capacité.
-
Définissez les critères d’acceptation. Les critères d’acceptation sont des normes mesurables pour savoir si un élément du backlog a été terminé avec succès. La spécification de ces critères est la prérogative du chef de projet, bien que l’équipe Scrum puisse avoir une certaine marge de manœuvre pour négocier via le Scrum master.
-
Confirmez et enregistrez les hypothèses, les nouveaux problèmes ou les interdépendances identifiés lors de la planification. Ces informations doivent être intégrées au backlog produit.
-
Appelez au consensus. C’est la prérogative du Scrum master. À peu près au même moment, l’équipe Scrum et le product owner indiqueront s’ils pensent que c’est le meilleur plan possible pour le sprint.
-
Développez les tâches concernées. Si l’équipe Scrum a besoin de plus d’informations, en particulier concernant les spécificités des éléments du backlog de sprint, posez toutes les autres questions nécessaires à ce stade, afin que vous puissiez transformer les récits d’utilisateurs en tâches détaillées.
Comment organiser et mener une réunion de planification de sprint
Peut-être organisez-vous votre première réunion de planification de sprint ou cherchez à rendre vos réunions plus productives. Il est important de savoir ce qui doit être couvert, mais vous devrez également vous assurer que la logistique est déterminée et que vous avez les fournitures à portée de main.
Pour un sprint d’un mois, vous devrez prévoir environ quatre heures de temps, soit une heure de réunion pour chaque semaine de sprint. Idéalement, vous vous rencontrerez en personne, mais si vous avez des membres de l’équipe à distance, assurez-vous que votre technologie de téléconférence fonctionne bien.
Pour ceux qui se réunissent en personne, vous avez besoin d’un espace de travail assez grand pour accueillir tout le monde. Ayez un système visuel comme des pense-bêtes, un tableau blanc ou un outil électronique. (Procurez-vous quelques pense-bêtes colorés différents pour représenter les éléments du backlog.) Et, comme l’équipe va être là un certain temps, vous aurez besoin de collations et de café pour éviter que les gens ne deviennent grincheux.
Télécharger l’ordre du jour de la réunion de planification de sprint
Avant la réunion, affichez l’objectif et la vélocité du sprint dans la salle de réunion, afin que tout le monde puisse s’y référer.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Utilisez vos pense-bêtes pour documenter les éléments du backlog : chaque type d’élément est associé à un pense-bête de couleur différente. Vous aurez besoin d’au moins trois couleurs : une pour les récits utilisateur, une pour les tâches, et une pour les bugs. Les pense-bêtes remontent ensuite sur le mur ou le tableau par ordre de priorité. Vous devrez recréer ce backlog visuel pour tous les membres de l’équipe à distance.
Lorsque vous êtes prêt(e) à commencer la réunion, ouvrez en célébrant ce que l’équipe a accompli lors du dernier sprint pour que les choses commencent du bon pied. Ensuite, le Scrum master ou le product owner présentera les récits candidats pour le backlog de sprint, y compris tout ce qui reste du dernier sprint. Si cela ne s’est pas produit lors de la réunion préalable à la planification, les récits devront être dimensionnés, et il existe plusieurs façons de le faire. Certaines équipes utilisent des tailles de T-shirt (XS, S, M, M+, L, XL, XXL, XXXL), tandis que d’autres attribuent des points d’effort à l’aide de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21).
Quel que soit le système de dimensionnement que vous utilisez, les valeurs relatives sont plus importantes que leurs valeurs brutes. Commencez par deux récits, décidez lequel est plus grand, puis placez-les dans l’ordre. Ensuite, prenez un troisième récit et décidez de sa taille par rapport aux deux autres, ajoutez-le au classement, et ainsi de suite. La somme des points d’effort doit être inférieure à la vélocité de l’équipe. Tous les éléments du backlog produit allant au backlog de sprint doivent également être validés comme étant prêts à être soumis au travail.
Pour l’équipe Scrum, l’analyse de chaque récit utilisateur peut prendre beaucoup de temps, et il y a un certain nombre d’étapes à prendre en compte. D’une part, ce récit est-il à jour, ou sa définition a-t-elle changé ? Y a-t-il de nouvelles informations à prendre en compte ? Les estimations du récit sont-elles toujours valides ?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Une fois la définition du récit fixée, elle doit être décomposée en tâches. (Certaines de ces tâches deviendront des récits utilisateur à part entière.) L’équipe décidera quelles compétences spécialisées, le cas échéant, sont nécessaires pour gérer ces tâches, et se demandera également comment tester le récit.
Tout comme pour les points d’effort et la vélocité, la longueur estimée des tâches doit être inférieure à la capacité de l’équipe pour le sprint. Les tâches et les récits utilisateur qui sont déplacés vers le backlog de sprint se voient attribuer des dates d’échéance, avec une prise en compte du nombre de jours ouvrables et du départ en vacances ou du travail à temps partiel au sein de l’équipe Scrum de membres de l’équipe.
N’oubliez pas que les récits utilisateur et leurs tâches constitutives ne sont pas les seuls à prendre de la place dans le backlog : les corrections de bugs aussi, donc elles occupent une partie de la capacité de l’équipe Scrum. Mais comment décide-t-on de l’espace pour chaque élément du backlog ? L’une des solutions consiste à allouer une proportion fixe de la capacité – disons 20 % – aux corrections de bugs. Une autre consiste à relier des corrections de bugs aux récits utilisateur, puis à les dimensionner et à les hiérarchiser comme des récits utilisateur.
Enfin, l’équipe Scrum, le Scrum master et le product owner créeront une définition de fini, y compris une sorte d’indicateur de test pour aider à garantir la qualité de la nouvelle itération.
Idéalement, la séance de planification du sprint se terminera par l’atteinte de certains résultats cibles. Il s’agit notamment des éléments suivants : que l’équipe Scrum se sente à l’aise avec l’objectif et que, à son tour, l’objectif soit aligné sur la vision stratégique et la feuille de route d’un produit ; une documentation adéquate du plan de sprint ; la création d’un diagramme d’avancement (un diagramme qui trace le travail restant à faire par rapport au temps restant) pour voir l’avancement du travail prévu ; et que chaque développeur de l’équipe Scrum sache exactement sur quoi il va travailler une fois le sprint commencé.
Une fois le backlog du sprint ordonné et l’objectif du sprint à l’esprit, le sprint est prêt à commencer.
La planification de sprint pour le marketing Agile
Bien que les développeurs de logiciels soient les professionnels Agile par excellence, ils ne sont pas les seuls. De nombreuses équipes de marketing adoptent également Agile avec enthousiasme.
Bien sûr, les spécialistes du marketing n’ont pas d’itérations fixes de logiciels à publier. Ce qu’ils ont, ce sont des projets continus (souvent à long terme) qui comprennent une variété d’activités. Ils doivent constamment jongler entre les priorités à court et à moyen terme, souvent avec un objectif clair à l’esprit pour chaque nouvel ensemble d’efforts.
Ainsi, pour les spécialistes du marketing, l’adoption des méthodes Agile est un moyen de réagir de manière coordonnée à l’évolution des conditions du marché tout en maximisant l’efficacité et en allant vers un objectif clairement énoncé.
Pour l’essentiel, les sprints et la planification de sprint pour le développement de logiciels et le marketing sont très similaires. Il existe cependant quelques différences importantes.
Premièrement, la durée des sprints marketing a tendance à être plus courte que celle des sprints de développement de logiciels. Le sprint marketing typique ne prend pas plus de deux semaines tandis que, dans le développement de logiciels, les sprints d’un ou deux mois ne sont pas rares.
Deuxièmement, les modifications du backlog de sprint au cours du sprint sont plus courantes en marketing que dans le développement de logiciels. Cette différence est liée aux contraintes plus rigides imposées par les tâches techniques liées au développement de logiciels, tandis que le marketing se prête à être plus fluide.
Troisièmement, il est probable qu’il y ait plus de spécialisations variées dans une équipe Scrum de marketing que dans une équipe Scrum de développement de logiciels, car la première comprend plus de disciplines.
Les bonnes pratiques pour la planification de sprint
Les experts recommandent quelques bonnes pratiques pour tirer le meilleur parti de votre réunion de planification de sprint.
Lorsque vous envoyez l’invitation à la réunion, incluez l’ordre du jour. Envisagez également d’ajouter un lien aux récits utilisateur candidats à partir du backlog produit, afin que les développeurs aient un peu de temps pour les parcourir avant la réunion de sprint.
Lorsque le product owner prépare une liste de récits utilisateur candidats à partir du backlog produit, il doit sélectionner des récits totalisant plus que la capacité de l’équipe Scrum. En effet, le Scrum master et l’équipe Scrum sont susceptibles de rejeter certains récits utilisateur ou de les reporter pour un sprint ultérieur. Si le product owner a choisi des récits qui occupent moins que la pleine capacité de l’équipe, les récits rejetés entraîneront un gaspillage de capacité pendant le sprint.
N’oubliez pas que, lors de la réunion de planification de sprint, c’est le Scrum master, et non le product owner, qui prend les choses en main. Comme l’équipe Scrum, le product owner est plus un contributeur à la réunion : les product owners répondent à toutes les questions des développeurs, expliquent les récits utilisateur et négocient les critères d’acceptation sous la médiation du Scrum master.
Il est également utile de rappeler à chacun comment il peut contribuer le plus efficacement et ce qu’il peut ou ne peut pas attendre des autres participants. Le product owner, par exemple, prend les devants dans la création de l’objectif de sprint et est responsable de la définition de la portée du sprint, du détail exhaustif de chaque récit utilisateur – avec une définition de fini – et de la hiérarchisation du backlog produit.
Le Scrum master organise la logistique de la réunion et négocie des indicateurs clés, comme la vélocité du sprint et la capacité pratique de l’équipe. Il prend également les devants dans la finalisation du backlog de sprint et modère les négociations entre le product owner et l’équipe Scrum.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
L’équipe Scrum rassemble toutes les informations dont elle a besoin pour le sprint à venir et s’engage sur un backlog de sprint qu’elle sait pouvoir livrer raisonnablement. Il est également du devoir de l’équipe d’informer le Scrum master de son indisponibilité à tout moment pendant le sprint.
L’une des sources courantes de dysfonctionnement dans la planification de sprint, explique le coach Agile Kevin Brunner, est la personne en charge du backlog. S’il n’a pas préparé la réunion ou ne fait pas confiance à l’équipe pour prendre des décisions par elle-même, l’état d’esprit de l’équipe devient celui de l’évitement plutôt que de l’engagement. Les développeurs en particulier peuvent se plaindre que la réunion est une perte de temps, car les récits utilisateur n’ont pas été étoffés ou car leur présence n’est pas requise parce que leur Scrum master ou le product owner prend de toute façon toutes les décisions unilatéralement.
Pour favoriser une dynamique d’équipe saine, Brunner explique que le Scrum master peut suivre trois principes :
-
La visualisation. Projetez-vous à la fin d’un sprint avec une itération terminée avec succès et travaillez en remontant en arrière à partir de là pour négocier les critères d’acceptation et extraire les informations nécessaires à la livraison de l’itération terminée. La visualisation donne à l’équipe un produit final concret autour duquel ses efforts vont se coaliser.
-
La culture. L’habitude de prendre des décisions d’équipe par consensus, d’écouter et de respecter la contribution des membres de l’équipe. La culture donne également à l’équipe le temps dont elle a besoin pour prendre des décisions, et garantit l’adhésion aux aspects clés du sprint, tels que la portée et les estimations de temps.
-
La réflexion. L’habitude de repenser à un sprint une fois qu’il est terminé afin de se demander ce qui s’est bien passé, ce qui ne s’est pas bien passé, et comment les choses pourraient être améliorées.
Une dynamique d’équipe saine, explique Tony Solomita, coach Agile, est définie par trois habitudes : préparer le backlog avant la réunion de planification, écouter ce que tout le monde a à dire dans le processus d’estimations et la finalisation du backlog de sprint, et respecter l’autorité du product owner quant à la raison pour laquelle une fonctionnalité particulière est nécessaire ainsi que l’autorité des développeurs sur la manière dont cette fonctionnalité sera livrée.
Questions fréquentes concernant la planification de sprint
Voici les questions les plus fréquemment posées concernant la planification de sprint :
Comment les interdépendances entre les tâches sont-elles gérées au mieux ? Il existe plusieurs façons d’atténuer les effets potentiels de perte de temps en lien avec les interdépendances des tâches. Tout d’abord, la planification des tâches pendant la réunion de planification de sprint peut activement réduire ou éliminer les interdépendances complexes lorsque vous décomposez les récits utilisateur en tâches. Deuxièmement, vous pouvez créer un temps tampon entre les tâches dépendantes, si possible. Troisièmement, l’utilisation de conceptions et de techniques de développement peu couplées et adaptables, telles que des objets fictifs, peut aider les développeurs à faire face aux effets des interdépendances. Quatrièmement, le fait que les développeurs travaillent à proximité les uns des autres peut éviter les problèmes liés à la dépendance en facilitant la communication.
Pour quel effort chaque membre de l’équipe doit-il signer ? En utilisant le principe de la météo de la veille, chaque membre de l’équipe doit signer pour un effort équivalent au maximum au nombre total de points d’effort qu’il a pris en charge lors du dernier sprint.
Comment les itérations sont-elles planifiées si la taille de l’équipe varie ? Bien que les changements récurrents dans la taille des équipes ne soient pas idéaux, ils sont parfois inévitables. Si la taille d’une équipe change, calculez le nombre moyen de points d’effort pris en charge par développeur dans le dernier sprint, et multipliez-le par le nombre de développeurs participant au sprint à venir pour obtenir un chiffre approximatif pour la vélocité du sprint. Vous devrez peut-être ajuster ce chiffre en fonction des personnes qui quittent et rejoignent l’équipe.
Comment les frais généraux, comme le temps passé dans les réunions ou la rédaction d’e-mails, sont-ils pris en compte ? Il n’existe pas de règle empirique pour calculer les frais généraux, car ils varient d’une équipe à l’autre. La plupart des équipes supposent simplement qu’une durée constante est consacrée aux frais généraux dans chaque sprint et que la vélocité de sprint des sprints précédents reflète avec précision le temps passé sur les frais généraux.
Comment la correction des bugs doit-elle être prise en compte ? Il y a plusieurs façons d’aborder cela. L’une consiste à traiter les bugs comme des récits utilisateur, en estimant la quantité de travail impliquée comme pour d’autres éléments du backlog de sprint. Une autre approche plus risquée consiste à ne pas attribuer de points d’effort aux bugs, ce qui réduit la vélocité de l’équipe. Le risque de cette approche est qu’elle ne fonctionne que si vous fournissez la même quantité de travail sur la correction des bugs dans chaque itération. Si la quantité de travail sur la correction des bugs varie, la vitesse changera considérablement d’un sprint à l’autre, ce qui rendra la planification des futurs sprints beaucoup plus difficile.
Pourquoi les itérations doivent-elles toujours avoir la même longueur ? La réponse, en bref, est le rythme et la cohérence. La séquence d’un sprint se déroule beaucoup plus facilement s’il suit un cycle régulier et facilement prévisible, ce qui simplifie grandement la planification du sprint.
Comment le temps consacré aux tests et à la documentation est-il pris en compte ? Le moyen le plus simple de le faire est d’inclure le temps consacré aux tests et à la documentation en tant que tâche distincte pour chaque récit utilisateur. Une autre solution consiste à créer un élément distinct dans le backlog de sprint pour les tests et la documentation.
Les estimations des fonctionnalités doivent-elles être révisées lors de la planification des itérations ? Seulement si l’estimation initiale est extrêmement inexacte.
Les estimations des tâches doivent-elles être révisées lors d’une itération ? Non. Une fois que vous avez terminé la planification d’une itération, laissez les estimations des tâches telles qu’elles sont. Bien sûr, le Scrum master indiquera probablement pourquoi l’équipe a choisi de changer une tâche, afin qu’elle puisse refléter ces informations dans la planification du futur sprint.
Toutes les équipes doivent-elles fonctionner selon le même calendrier d’itération ? Cela dépend du nombre d’équipes Scrum travaillant en tandem et de la disponibilité du personnel de soutien. S’il n’y avait pas de contraintes à ce que plusieurs équipes travaillent sur des itérations qui ont commencé et se sont terminées au même moment, la synchronisation qui en résulterait serait d’un grand avantage pour la direction. Cela réduirait le risque que le travail d’une équipe impose des changements au backlog de sprint d’une autre, car les équipes se coordonneraient en ce qui concerne la planification de leur sprint. En pratique, cependant, les équipes Scrum ne travaillent pas isolément, et il y a un nombre limité de personnes qui remplissent des fonctions de soutien au sein de plusieurs équipes Scrum et apprécient les itérations avec des dates de début et de fin décalées.
Erreurs courantes dans la planification de sprint et signes avant-coureurs
Le Scrum master expérimenté connaît les signes avant-coureurs qui indiquent que la planification du sprint ne se passe pas aussi bien qu’elle le devrait. Voici ce à quoi il faut faire attention.
Si une équipe échoue à plusieurs reprises à terminer son backlog de sprint – si elle pousse continuellement les récits utilisateur vers le prochain sprint – c’est un signe que le groupe surestime sa propre vélocité et se surcharge de travail. Pour s’assurer que la planification est exacte (et réellement utile), le Scrum master devra ajuster la vélocité de l’équipe Scrum à la baisse.
Si, toutefois, les mêmes fonctionnalités sont poussées à plusieurs reprises vers le prochain sprint, l’équipe évite probablement délibérément de s’attaquer à certains récits utilisateur ou corrections de bugs. Cette situation mérite d’être examinée pour savoir s’il y a des problèmes autour de ces récits utilisateur ou des bugs qui ne sont pas soulevés lors de la planification du sprint.
Un échec à terminer le backlog de sprint pourrait également indiquer une conception trop poussée, c’est-à-dire que les développeurs vont bien au-delà de leur travail, en faisant en réalité plus que nécessaire. Cela demanderait un examen des exigences pour les fonctionnalités demandées afin de s’assurer que l’équipe ne déploie pas d’efforts non nécessaires.
Ce qu’il ne faut pas faire : les erreurs typiques dans la planification de sprint
Une séance de planification de sprint peut être sabotée par quelques pièges courants :
-
Le product owner crée le backlog de sprint seul, sans la contribution des développeurs. Cela engage l’équipe Scrum dans un backlog pour lequel elle n’a pas eu son mot à dire dans la création. Cela réduit à la fois leur implication dans le processus de planification et la probabilité que le sprint atteigne son objectif déclaré.
-
Le Scrum master montre les récits utilisateur candidats aux développeurs pour la première fois lors de la réunion de planification de sprint. Une perte de temps inutile : cela fait durer les réunions de planification beaucoup plus longtemps qu’elles ne le devraient. Si vous avez nettoyé le backlog, il est assez simple d’inclure les récits utilisateur candidats à l’ordre du jour de la réunion. Le fait d’avoir des récits utilisateur qui ne répondent pas aux critères INVEST entraînera des problèmes similaires.
-
L’équipe ne fixe pas de définition de fini. Lorsque cela se produit, l’équipe livre un produit qui est incomplet à la fin de l’itération. Un signe que ce problème peut se profiler est que tous les éléments du backlog de sprint ne sont pas décomposés en une série de tâches gérables.
-
Les sous-tâches ne sont pas estimées dans leur totalité. Vous pouvez repérer ce problème lorsque les tâches ne semblent pas estimées avec précision les unes par rapport aux autres. (Une tâche très complexe n’est pas un multiple assez grand d’une tâche simple.)
-
Le Scrum master prend trop de temps pour compiler le backlog de sprint dans un outil électronique. Cela peut impliquer que l’équipe Scrum travaille à l’aveugle pendant les premiers jours du sprint, incapable de voir sa véritable progression.
-
Les récits utilisateur candidats ne sont pas abordés avec d’autres parties prenantes avant d’être ajoutés au backlog du sprint. Encore une fois, ce type d’erreur conduit les parties prenantes mécontentes à demander à ce que le backlog soit modifié une fois le sprint en cours. Certains product owners peuvent également faire cela, même après avoir approuvé le backlog de sprint d’origine, et cela peut être très frustrant. Pour certaines équipes Scrum, un certain changement dans le backlog peut être pratiquement inévitable. Si tel est le cas, il existe un certain nombre de recours possibles. L’un d’entre eux consiste à allonger le sprint ou à sous-estimer intentionnellement la capacité du sprint afin qu’il y ait une plus grande marge de manœuvre si du travail doit être ajouté. Pour les équipes dont le travail est fréquemment interrompu, la meilleure solution peut être de simplement faire avec et de réduire le temps passé à la planification du sprint, car l’activité ne peut pas vraiment servir son but prévu.
-
L’équipe Scrum ne détaille pas les tâches et les sous-tâches correctement. C’est généralement un signe que l’équipe s’ennuie de la planification et veut juste se lancer. Un niveau de détail insuffisant risque de fausser les estimations lorsque les développeurs découvriront que les tâches prennent plus de temps que ce à quoi ils s’attendaient.
-
Les membres de l’équipe sont réticents à l’idée de discuter des étapes. Cela prive le reste d’une équipe de l’occasion d’apprendre.
-
L’équipe n’a pas de Scrum master pour prendre en charge la planification. Sans Scrum master pour contrôler le rythme de la session de planification, tout le monde cherchera à en finir avec cela le plus tôt possible, ce qui peut entraîner soit une session de planification frustrante, soit l’absence de détails clés.
Améliorez la planification de sprint pour la gestion de projet avec Smartsheet
De la simple gestion de tâches et de projets à la gestion complexe de ressources et de portefeuilles, Smartsheet vous aide à améliorer la collaboration et à accélérer le travail. Vous avez ainsi les moyens d'accomplir plus de travail. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports de synthèse sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.