Issu de la méthodologie Agile SCRUM, le terme “sprint” correspond à la période au cours de laquelle tout le travail est réalisé. C'est donc le moment où l’on transforme les idées en valeur ! Souvent redouté par les Product Owner et boudé par les Développeurs, le sprint planning (littéralement planification de sprint) est pourtant un rituel indispensable au succès de ton produit.
Nous allons voir dans cet article en quoi consiste cette cérémonie et lever le voile sur beaucoup d’idées reçues.
Attention à la confusion, le poker planning et le sprint planning sont 2 choses différentes. Le premier est une méthode d’estimation d’effort, le deuxième est une cérémonie qui rentre dans le cadre d’une méthodologie (SCRUM). Ainsi, contrairement au poker planning :
“Scrum est simple. Essayez-le tel quel et déterminez si sa philosophie, sa théorie et sa structure aident à atteindre les objectifs et à créer de la valeur […] Scrum repose sur l'intelligence collective des personnes qui l'utilisent. Plutôt que de fournir aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions.”
Pour faire très simple c’est la réunion pendant laquelle l’équipe agile Scrum (Product owner, Scrum master et Développeurs) se met d’accord sur les éléments du backlog à inclure dans le prochain sprint pour atteindre un objectif et sur la manière d'y parvenir.
Qui participe au sprint planning ? Toute l’équipe scrum mais pas que ! En réalité il n’y a pas de règle et d’autres stakeholders peuvent assister à la réunion au besoin (utilisateurs, QA, etc.…), tout le monde est le bienvenu ! Pour ce qui est de la répartition des rôles, comme indiqué dans le scrum guide, le Product Owner doit s’assurer que tous les membres de la scrum team soient prêts à échanger sur les items les plus prioritaires du backlog et comment atteindre l’objectif du sprint.
Cependant, concernant l’animation de la cérémonie, rien n’est précisé. Ainsi dans certains cas le Scrum Master va se charger de l’animation tandis que dans d’autre cas c’est le PO qui aura la responsabilité de cette tâche . Dans certains cas ça peut même être un travail collaboratif entre le Scrum master et le PO !
Encore une fois, le framework agile permet d’être assez flexible à ce niveau.
Les sprints planning ont lieu avant chaque début de sprint et le jour va donc dépendre de la fréquence d’itération de ton projet. On évitera cependant de réaliser les sprints planning le vendredi pour ne pas perdre de vue l’objectif du sprint pendant le week-end !
Combien de temps doit durer un sprint planning ? Le moins de temps possible ! En effet, même s’il n’y a pas de durée minimum obligatoire, le scrum guide conseille de ne pas dépasser 8h de planification pour un sprint de 4 semaines (soit 2h max par semaine de sprint). Cela permet d’être plus efficace et de ne pas pénaliser la productivité. Tu peux donc time boxer la séance avant de commencer et le Scrum Master ou le Product Owner pourra ainsi faire office de gardien du temps. Malgré toutes ces recommandations, le plus gros levier qui va impacter la qualité et la durée de ton sprint planning reste le degré de préparation en amont de la cérémonie.
“Le sprint planning c’est 80% du travail en amont, et 20 % d’effort en séance”.
Avant de rentrer dans le détail du fonctionnement d’un sprint planning, nous allons nous intéresser ici à la partie en amont qui est fondamentale pour le bon déroulement de ce dernier. Cette partie de préparation doit être réalisée par l’équipe Scrum pendant le sprint en cours pour le sprint n+1.
Pour être sûr de ne rien oublier, tu peux utiliser un système de check liste en 4 étapes :
La roadmap produit est définie et l’objectif du prochain sprint doit être clair pour le PO et partagé à toute l’équipe Scrum. Comme indiqué en introduction, l’objectif du sprint doit apporter de la valeur à l’utilisateur.
Souvent négligé voir totalement absent, il est pourtant très important :
L’objectif de sprint est proposé par le Product Owner puis validé avec l’ensemble de la scrum team.
Le product backlog items qui comprend toutes les user stories rédigées par le Product Owner est priorisé et comprend tous les éléments nécessaires à l’atteinte de l’objectif du prochain sprint (voir article sur comment rédiger des US).
Les éléments du product backlog ont été raffinés par l’équipe et respectent la définition of ready (voir l’article sur la DOR).
Pour cette étape, les séances de backlog refinement (anciennement appelé backlog grooming) sont essentielles et doivent être réalisées régulièrement par l’équipe scrum.
La vélocité agile correspond à l’effort qu’est capable de fournir l’équipe de développement pour la réalisation des tâches programmées dans le sprint. Cette estimation peut être faite par le Scrum Master ou le Product Owner. Pour anticiper les aléas du sprint (mauvaise estimation, bugs de prod, absence non planifiée, etc...) tu peux garder une marge de 20 % en plus (à réajuster en fonction de l’historique de l’équipe).
Attention, la vélocité n’est pas un objectif à atteindre ou à dépasser ! C’est un outil permettant d’estimer la capacité à faire de l’équipe et d'apporter de la prédictivité sur les prochains sprints
Cette dernière étape consiste à faire le bilan du sprint précédent : a-t-on atteint l’objectif ? reste-t-il des tickets non terminés ? On peut aussi appliquer dès le sprint planning, les actions remontées lors de la dernière rétrospective dans le cas où des actions ont bien été identifiées. Si tu as suivi toutes ces étapes, félicitations, tu as fait le plus gros du travail !
Le jour du sprint planning, la première étape consiste à rappeler à toute l’équipe scrum l’objectif de ce sprint puis de rappeler la vélocité prévue de l’équipe.
Une fois que tout le monde partage la même vision, l’équipe choisit les tickets pour pouvoir atteindre l’objectif en cohérence avec la capacité de l’équipe sur la période.
On peut découper cette séance en 2 parties :
Le Product Owner présente toutes les US du product backlog aux Développeurs et, ensemble, ils sélectionnent les US à inclure dans le sprint backlog pour atteindre l’objectif. Lors de cette étape, les Développeurs échangent sur la complexité, l’incertitude, les dépendances et l’effort à fournir pour la réalisation des éléments du backlog.
Attention, il faut garder en tête qu’à la fin du sprint l’équipe doit être en mesure de livrer quelque chose à l’utilisateur.
Si des inconnues ou des incompréhensions sur les US sont remontées, il est important de les prendre en compte et ne pas hésiter à rechiffrer les US en séance en prenant éventuellement une marge pour ces aléas.
Théoriquement si une US ne respecte pas la definition of ready (DoR), on ne doit pas l’inclure dans le sprint. Dans la réalité, le scope d’un sprint est négociable et rien n’empêche d'ajouter une US qui ne respecte pas la DOR ou retirer une US d’un sprint en cours tant que ça ne remet pas en cause l’objectif du sprint qui est non négociable.
Une fois le plan établi, l’étape suivante consiste à découper tous les éléments du sprint backlog en tâches techniques et opérationnelles. Ce travail est fait par les Développeurs et va leur permettre de mieux se projeter sur le travail à fournir pendant le sprint et ainsi affiner l’estimation et d’améliorer l’engagement de l’équipe sur les sujets à traiter. Une fois le découpage terminé, chaque Développeur choisit un ticket par lequel il va commencer sur le sprint.
Suite à ces 2 étapes, tu as donc en théorie, un objectif et un plan détaillé pour atteindre ton objectif, ton sprint planning est un succès !
A la fin du sprint planning, tu peux effectuer un vote de confiance sur la capacité à atteindre l’objectif de sprint. Cela permet d’anticiper les possibles risques associés à la réalisation de l’objectif, d’ajuster le planning en conséquence, et surtout de stimuler l’engagement de l’équipe à atteindre l'objectif.
Important : cette partie est une description exhaustive du déroulement d’un sprint planning “conventionnel”, cependant le framework Scrum n’est pas à suivre à la lettre et c’est à toi de l’adapter à ton organisation pour être le plus efficace possible !
Tout d’abord, il n’existe pas d’outil spécifique pour le sprint planning, ce rituel est une petite partie d’une méthodologie agile appliquée à un projet. On utilisera donc un outil de gestion de projet classique pour conduire ces cérémonies.
Mais alors quel outil de gestion de projet puis-je utiliser ? Là encore, il n’y a pas de règle ! L’outil utilisé va surtout dépendre de la taille de ton équipe et de ton budget.
Parmi les outils de gestion de projet les plus connus on pourra citer :
Encore une fois, rien ne t’oblige à utiliser un logiciel, si ton planning poker a correctement été préparé tu pourrais théoriquement le faire juste avec un tableau blanc et des post-it !
Pour conclure, le sprint planning est une cérémonie agile essentielle de l’équipe scrum qui a pour but de déterminer le contenu et l’organisation du prochain sprint en vue d’atteindre un objectif commun à tous et générer de la valeur pour l’utilisateur. Dans la pratique, il demande surtout un travail de préparation pour être efficace mais cette cérémonie n’est pas aussi figée que ce que l’on pourrait penser. Ainsi, il faut plutôt voir le sprint planning comme une partie d’un outil permettant de délivrer de la valeur et cet outil est à faire évoluer en fonction de l’expérience de ton équipe.
Ce qu’il faut retenir :
Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !
