Planification de Sprint : Qu’est-ce que c’est et comment la réaliser ?
Êtes-vous prêt à tirer le meilleur parti de la planification de sprint ? En tant que chef de projet agile ou product owner, c'est à vous de vous assurer que tout le monde est aligné et de garantir des résultats.
Il est donc temps de mettre de l’ordre dans le chaos et d’atteindre ces critères de réussite grâce à ce guide ultime qui rendra votre planification de sprint si organisée que Marie Kondo pourrait en être jalouse ! Bien qu’un bon outil de gestion de projet agile puisse être très utile, rien ne remplace l’intelligence humaine et le travail d’équipe pour élaborer un plan de sprint efficace.
C’est pourquoi, dans ce guide complet, je vais vous accompagner à travers toutes les étapes pour planifier des sprints réussis—y compris comment définir un objectif de sprint, comment préparer la réunion de planification du sprint, établir l’ordre du jour de la réunion et d’autres bonnes pratiques.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Qu’est-ce que la planification de sprint ?
La planification de sprint est la phase initiale d’un cycle de développement agile et fait partie de la planification de projet agile. Lors de cette réunion, toute l’équipe se réunit pour une réunion de planification de sprint afin de définir le travail à réaliser pendant le sprint et d’élaborer un plan pour atteindre ces objectifs.
Généralement, la réunion de planification de sprint se divise en deux parties :
- Le “pourquoi” et le “quoi” du sprint : l’équipe définit l’objectif du sprint et se met d’accord sur ce qui sera réalisé. Elle sélectionne des items du backlog produit qui seront traités durant le sprint. Les outils de planification de projet dotés de fonctionnalités de planification de sprint peuvent aider à organiser et prioriser ces éléments afin que l’équipe reste concentrée et alignée sur les objectifs du sprint.
- Le “comment” du sprint : les développeurs discutent en détail des éléments individuels du backlog et les décomposent en tâches. Chaque tâche est conçue pour être terminée en une journée ouvrée ou moins et peut être suivie grâce à un outil de gestion des tâches.
Selon la durée du sprint, la réunion de planification dure entre deux et huit heures. Elle doit être minutée en fonction de la durée du sprint (par exemple, réunion de 4 heures maximum pour un sprint de deux semaines).
À la fin de la réunion, l’objectif du sprint et les tâches à accomplir doivent être fixés et le sprint doit officiellement commencer.
Pourquoi la planification de sprint est-elle importante ?
La planification de sprint est essentielle car elle définit une orientation claire pour le sprint à venir de l’équipe. Lorsqu’elle est bien menée, une session de planification de sprint peut :
- Instaurer une compréhension claire et partagée des objectifs et buts du projet
- Permettre aux équipes de prioriser et de sélectionner les tâches du prochain sprint
- Favoriser une allocation efficace des ressources et une bonne gestion du temps
- Encourager la collaboration et la communication entre les membres de l’équipe
Globalement, la planification de sprint est une étape préparatoire indispensable de la gestion de projet Agile. Elle établit les bases pour un sprint bien organisé et efficace, permettant aux équipes de livrer des résultats de qualité dans les délais impartis.
Qui participe à la planification de sprint ?
En résumé, toute l’équipe Scrum doit participer à la planification du sprint et être présente lors de l’événement Scrum au début de chaque sprint. Ces membres de l’équipe peuvent inclure :
- Le product owner : Apporte une vision produit, clarifie les besoins, et priorise les éléments du backlog à intégrer au sprint.
- Le Scrum master (appelé coach agile dans certaines équipes et à ne pas confondre avec un chef de projet) : Facilite la réunion, veille à ce que le processus convenu soit respecté et que chaque participant partage une vision commune de l’objectif du sprint.
- Les développeurs : Apportent leur expertise technique et évaluent la faisabilité ainsi que l’effort nécessaire à la réalisation des user stories.
Il arrive aussi que certains parties prenantes de l’entreprise participent en tant que consultants s’ils peuvent apporter un point de vue important ou des connaissances utiles.
Comment se préparer à la réunion de planification de sprint
Pour une réunion efficace, le product owner (PO) doit préparer les éléments suivants :
- Les enseignements tirés du dernier sprint review et de la rétrospective de sprint, ainsi que les retours des parties prenantes présents dans le backlog.
- Un aperçu des travaux déjà réalisés.
De plus, le product owner doit se préparer à une réunion de planification de sprint en accomplissant plusieurs processus, que je vais détailler ci-dessous. Ceux-ci incluent :
- Définir à l'avance l'objectif du sprint avec les éléments du backlog associés et priorisés pouvant être discutés lors de la planification.
- Affiner régulièrement le backlog, où les entrées les plus importantes sont mises à jour.
- Évaluer la vélocité et la capacité de l'équipe pour le prochain sprint.
Je vais décrire ces trois activités plus en détail ci-dessous.
Qu'est-ce qu'un objectif de sprint ?
Pendant la planification du sprint, le product owner et les développeurs se mettent d'accord sur un objectif de sprint spécifique. L'objectif de sprint décrit le résultat ou l'aboutissement du nouveau sprint sur lequel l'équipe travaille. C'est une étape à court terme sur le chemin du produit final.
L'objectif est qu'à la fin du sprint, il y ait un incrément de produit livrable qui offre déjà un avantage aux clients.
Qu'est-ce qu'un backlog ?
Si vous êtes product owner, il y a de fortes chances que vous ayez entendu le terme « backlog » plus de fois que vous ne pouvez le compter. Mais qu'est-ce que c'est au juste ? Bien sûr, à un niveau fondamental, nous savons tous ce que c'est : une liste de tâches ou de fonctionnalités à réaliser.
Cependant, lorsqu'il s'agit de détails concrets, comme la différence entre un backlog produit et un backlog de sprint, les choses deviennent rapidement compliquées. Alors accrochez-vous, on plonge dans le sujet !
Backlog produit vs backlog de sprint
L'équipe Scrum regroupe toutes les user stories, épopées (epics) et tâches nécessaires à la création du produit final dans le backlog produit. Et le product owner priorise les éléments du backlog afin que les histoires ayant la plus grande valeur pour les clients se trouvent en haut de la liste. Cette priorisation se fait généralement en collaboration avec les développeurs.
Cependant, le backlog produit n'est pas une liste définitive créée au début de la phase de développement puis exécutée. Non, cette liste évolue et s'enrichit sans cesse avec le temps.
Elle grandit à la fois grâce aux enseignements tirés des sprints et aux nouveaux besoins apparaissant au fil du temps. C'est pourquoi un affinage régulier du backlog est nécessaire afin de prendre en compte ces changements.
Par exemple, supposons que le backlog produit comprenne toutes les histoires nécessaires à la création d’un site Web, par exemple la page d'accueil, le formulaire de contact et les pages produits. Si l’équipe marketing réalise soudainement qu’elle a absolument besoin d’une section blog sur le site, celle-ci peut alors être ajoutée au backlog et priorisée en conséquence.
En comparaison avec le backlog produit, le backlog de sprint ne contient que les éléments du backlog sélectionnés pour le sprint en cours et un objectif général de sprint.
Comment estimer les éléments dans le backlog
Quelle quantité de travail une équipe peut-elle réaliser lors d’un sprint ? C’est l’une des questions clés auxquelles les développeurs doivent répondre lors de la planification du sprint. Afin de pouvoir faire une prévision, ils en font une estimation.
Cela peut s'avérer difficile car l’équipe fait face à de nombreuses variables inconnues. Cependant, au fil du temps et avec l'expérience acquise lors des sprints précédents, l’équipe devient de plus en plus précise dans ses estimations.
Comment calculer la vélocité et la capacité de l'équipe
Avant de pouvoir commencer l’estimation, il est essentiel de connaître la performance moyenne des sprints précédents (vélocité) ainsi que la capacité disponible de l’équipe pour le sprint à venir, qui peut être réduite en raison de formations, de congés, etc.
Sur la base de ces éléments, l’équipe estime la charge de travail (vélocité) qu'elle peut supporter lors du sprint, puis évalue individuellement les éléments du backlog et choisit combien en inclure dans le backlog de sprint.
Supposons que la vélocité moyenne ait été de 40 points d’histoire sur les derniers sprints (cycle de 2 semaines), et qu’aucune réduction significative de la disponibilité des membres de l’équipe ne soit attendue, alors l’équipe planifiera sur la base de cette même vélocité (c’est-à-dire que les éléments du backlog sélectionnés pour le prochain sprint rempliront environ 40 points d’histoire).
Alors que le temps moyen pour accomplir une tâche peut généralement être suivi avec un bon outil de suivi du temps, vous pouvez également utiliser d'autres méthodes d'estimation pour faire de la planification de capacité agile et déterminer la vélocité de votre équipe.
Méthodes d'estimation : Un bref aperçu
Vous cherchez à mieux comprendre l’art d’estimer ? Avec différentes méthodes et de nombreux paramètres en jeu, le sujet peut paraître intimidant – mais ne vous inquiétez pas ! En comprenant les bases, vous serez rapidement capable d’estimer votre backlog en toute confiance.
Points d’histoire
De nombreuses équipes agiles travaillant sur des projets à long terme estiment leur vélocité en points d’histoire.
Les points d'histoire sont une unité abstraite que l'équipe utilise pour estimer l'effort nécessaire à la réalisation d'un élément du backlog. Cela se base sur trois critères :
- Quantité de travail : Combien de sous-tâches doivent être achevées pour terminer l’histoire utilisateur ?
- Risques et incertitude : Est-ce que tous les besoins sont clairs ou pourrait-il y avoir des retards et changements inattendus ?
- Complexité de l'histoire : Les sous-tâches individuelles sont-elles liées entre elles, ce qui augmente la complexité de l'histoire ? Et existe-t-il des dépendances externes à l'équipe ?
La suite de Fibonacci & les nombres premiers
La planification agile avec l'utilisation de la suite de Fibonacci et des nombres premiers aide les équipes à effectuer des prévisions basées non seulement sur l’optimisme ou l’intuition, mais sur des principes logiques et numériques.
Si une histoire utilisateur comporte de nombreuses variables et est complexe ou d'envergure importante, l'attribution d'un nombre élevé sur l'échelle de Fibonacci signifie que l'équipe se prépare à engager suffisamment de ressources et d'efforts pour la mener à bien—parce qu'elle connaît déjà la quantité de travail inhérente à une telle tâche.
En revanche, les histoires comportant peu de variables ou des résultats plus simples obtiennent des notes plus basses—ce qui permet un budget temps et énergie plus serré. En bref, la planification agile remplace les espoirs et les rêves autour de la table de réunion par des chiffres concrets et mesurables !
Cependant, gardez à l'esprit que les points d’histoire ne sont pas nécessairement comparables entre différentes équipes de développement logiciel, car chaque équipe estime le périmètre à sa façon. Ainsi, ce qu'une équipe A considère comme une histoire à 5 points peut être estimé à 8 points par l’équipe B.
L’estimation par points d’histoire convient également aux petites équipes ou à des projets de taille réduite, puisque cette méthode consiste à évaluer les tâches selon la complexité et le temps requis pour les traiter. D'autres techniques incluent l’estimation via les tailles de T-shirt ou la méthode du planning poker.
Les tailles de T-shirt
Estimer les éléments du backlog à l’aide des tailles de T-shirt est une approche originale pour aider à hiérarchiser les tâches du projet. Au lieu d’attribuer un nombre exact d’heures ou de jours à une tâche, vous pouvez l’associer à l’une des quatre tailles (petit, moyen, grand, extra-grand) en fonction de sa complexité ou incertitude.
C’est une façon simplifiée mais étonnamment efficace de s’assurer que les bonnes tâches sont traitées au bon moment—qu’il s’agisse de petits, moyens ou grands projets, il suffit de choisir la taille qui correspond. Veillez simplement à ce que tous les participants au projet s’accordent sur la signification de chaque taille vis-à-vis du niveau d’effort estimé !
Planning Poker
Si vous cherchez une manière astucieuse d'estimer vos éléments de backlog, pourquoi ne pas essayer le planning poker ?
C'est une technique populaire qui existe depuis 2002, année où James Grenning a inventé ce terme.
Le principe est simple : les membres de l’équipe donnent anonymement leur estimation en choisissant des cartes dans le jeu de planning poker, chaque carte représentant une estimation différente (c’est-à-dire le nombre estimé de points d’histoire pour l’élément).
Cela encourage chacun à exprimer sa propre vision sans crainte de jugement ou de moquerie de la part des autres. Une fois que tous les membres de l’équipe ont donné leur estimation et qu’un consensus est trouvé, l’équipe passe à l’élément suivant.
L’ordre du jour de la planification de sprint
Après avoir préparé tout le nécessaire, vous êtes enfin arrivé à la réunion de planification du sprint. La planification d’un sprint en Scrum suit généralement l’agenda suivant :
- Le product owner (PO) présente son objectif de sprint prédéfini et partage son idée sur la manière d’augmenter la valeur du produit lors du prochain sprint. L'objectif final du sprint est défini conjointement par le product owner et les développeurs.
- Le PO énonce les éléments (priorisés) du backlog produit qui devraient être mis en œuvre pour atteindre l'objectif.
- L’équipe estime l’effort nécessaire pour chaque élément, si cela n’a pas déjà été fait auparavant (par exemple lors de l’affinage du backlog). Si besoin, l’équipe affine certains éléments ou contenus (ex. critères d’acceptation).
- L’équipe sélectionne les éléments du backlog produit qu’elle livrera d’ici la fin du sprint. À ce stade, le product owner discute avec les développeurs des tâches à accomplir en tenant compte de la valeur client et de l’effort requis. Les éléments choisis suffisent-ils à atteindre l'objectif du sprint et à créer de la valeur pour le client ? Au final, les développeurs décident eux-mêmes de la charge de travail qu’ils s’engagent à réaliser pendant le sprint. Important : Cette sélection ne constitue pas un engagement envers le product owner et les parties prenantes, mais une prévision basée sur l’estimation de l’effort et la vélocité moyenne de l’équipe.
- Les développeurs se réunissent ensuite pour découper les éléments du backlog sélectionnés en tâches plus petites. Idéalement, ces lots de travail sont conçus pour être achevés en une journée ou moins.
- Le sprint backlog se compose de l'objectif de sprint convenu ensemble, des éléments de backlog à traiter, et du plan pour les réaliser.
- De nombreuses équipes visualisent le sprint backlog et les travaux à réaliser sur un tableau Scrum. Chaque équipe a son propre tableau et utilise différentes colonnes pour documenter l’avancement du sprint. Fondamentalement, les trois colonnes principales de tous les tableaux devraient être les suivantes : « À faire », « En cours », « Terminé ».
Dans la pratique, de nombreuses équipes Scrum divisent la planification du sprint en deux phases :
Dans la première partie, les quatre premiers points de l’ordre du jour ci-dessus sont abordés. Le product owner et l’équipe clarifient les questions : « Pourquoi ce sprint est-il important ? » et « Qu’est-ce qui sera réalisé pendant ce sprint ? » Les développeurs réalisent la deuxième partie sans le PO et se concentrent sur la manière d’exécuter le travail sélectionné.
Modèle d'ordre du jour pour la réunion de planification de sprint
Besoin d’un modèle d’ordre du jour pour vos réunions de planification de sprint ? Téléchargez notre modèle clair et facile à utiliser pour organiser rapidement vos séances de planification de sprint. Vous y trouverez également une checklist et un modèle d’email, pour plus de praticité.
C’est le moment de simplifier vos réunions de planification de sprint à la Marie Kondo
Grâce à ce guide complet, vous êtes désormais prêt à tirer le meilleur parti de vos séances de planification de sprint. Si vous avez trouvé ce guide utile, nous vous recommandons également de consulter notre guide sur les réunions de planification de projet.
En suivant les étapes décrites dans cet article, les product owners ont toutes les clés pour transformer le chaos en clarté et aider leur équipe à réussir leur prochain sprint. Découvrez-en plus sur le cadre Scrum et d’autres cérémonies Scrum comme la Scrum quotidienne ici.
Pour rester informé de nos conseils d’organisation et de nos articles sur les thèmes liés à la gestion efficace de projets orientés produit, je vous invite à vous abonner à la newsletter The Digital Project Manager. Vous y recevrez des analyses d’experts du secteur et de chefs de projets du monde entier.
