Issu de la méthodologie Scrum, le sprint planning est la cérémonie d’ouverture du sprint. Animé par le Product Owner ou le Scrum Master, il a pour objectif d’anticiper le déroulement de l’itération à venir et d’impliquer l’équipe autour d’un objectif commun. Mais comment le réussir ?
I - Qu’est-ce que le sprint planning ?
II - Qui participe au sprint planning ?
III - Comment préparer un sprint planning ?
IV - Quel est le déroulé d’un sprint planning ?
V - Les 4 pratiques à éviter lors d’un sprint planning
🤔 Qu’est-ce que le sprint planning ?
Avec le daily scrum meeting, la sprint review et la rétrospective, le sprint planning est l’un des rituels décrits comme obligatoires dans le Scrum guide.
En début d’itération, le sprint planning a pour objectif d’aligner l’équipe sur un objectif à atteindre, en définissant un ensemble d’éléments à réaliser durant le sprint. Pour cela, le Product Owner (PO) présente sa priorisation initiale en mettant l’accent sur l’objectif de sprint. Bien que sous la responsabilité du PO, le backlog de sprint priorisé doit être approuvé par l’ensemble de l’équipe, développeurs inclus.
Pour aller plus loin : télécharger notre livre Les Clés du Product Management
🙋 Qui participe au sprint planning ?
Comme dans toute équipe, chaque rôle a son importance.
Le rôle du PO
Le PO joue le premier rôle dans les sprints plannings. Sa mission principale est de présenter les tâches et users stories (US) à réaliser en insistant sur l’importance de chacune, et notamment leur lien avec l’objectif du sprint. Il est aussi là pour répondre aux questions que pourraient avoir les développeurs en apportant plus de détails fonctionnels et donner du sens si cela manque.
En l’absence de Scrum Master, il est d’usage qu’il soit chargé d’animer la réunion et de veiller à ce qu’elle ne dépasse pas le temps imparti.
Le PO peut challenger la constitution du backlog mais il n’en est pas responsable. C’est l’équipe qui définit sa capacité de production et se projette sur ce qu’elle peut réaliser. Le PO s’assure quand même que ce backlog est en accord avec l’objectif de sprint, que la priorisation est la bonne et que la projection par rapport à la capacité reste cohérente.
Les autres participants
L’ensemble des membres de l’équipe doit être présent afin que tout le monde soit embarqué et prêt pour le bon déroulement de l’itération à venir :
- Le Product Designer, s’il y en a un, aide le PO à présenter les US en insistant sur les spécificités qu’il attend en termes d’animations et de détails de design. Dans mes expériences passées, il m’est déjà arrivé de voir le Product Designer travailler dans plusieurs équipes. On organisait alors les sprint plannings à différents moments pour qu’il soit présent.
- Les développeurs prennent connaissance des priorités, challengent le backlog, planifient leur sprint et, pour certains, découpent les Users Stories (US) en sous-tâches.
- Le testeur/QA (quality assurance), s’il y en a un, se familiarise avec le périmètre des tickets à tester et s’intéresse plus particulièrement aux critères d’acceptation des US.
- Le Scrum Master, s’il y en a un, est garant de l’application de la méthodologie. Il s’assure que tous les tickets respectent la Definition of Ready. Il vérifie aussi l’alignement de l’équipe et du backlog par rapport à l’objectif. Il est aussi le plus souvent chargé de l’animation de la réunion.
Si un Product Manager est également dans l’équipe, celui-ci peut venir s’il le souhaite, mais c’est le PO qui représente le produit afin qu’il ait toute la légitimité vis-à-vis de son équipe de développement.
🧐 Comment préparer un sprint planning ?
Un sprint planning réussi permet de commencer du bon pied et donne le ton du sprint. Mais comme tout plan d’action, cela se prépare.
L’importance de l’objectif de sprint
Floriane Sirven, Head of Product chez Thiga, met en garde contre une mauvaise pratique qu’elle a observé : “au début du sprint planning, l’équipe doit se mettre d’accord sur un objectif partagé et proposé par le PO, mais on se retrouve souvent avec une liste de tickets qui ne sont pas orientés “objectif”, cela manque de focus utilisateur.”
Comme Floriane, j’avoue avoir déjà ressenti un relâchement dans mon équipe quand le backlog de sprint manquait de sens. C’était encore pire du côté de mes parties prenantes qui voyaient pleins de micro-sujets à traiter au lieu d’avoir un sujet principal qui avance vraiment.
Pour rédiger un bon objectif de sprint, gardez en tête qu’il doit :
- Être atteignable : l’itération étant courte par définition, évitez des objectifs trop ambitieux ou trop vastes. Au lieu de dire “travailler sur la barre de recherche” par exemple, mieux vaut préférer un objectif comme “améliorer les résultats de la barre de recherche”. Si vous n’y arrivez pas, je vous conseille de découper plus finement vos sprints.
- Servir de repère pour savoir quelles US intégrer ou supprimer en début ou en cours de sprint. Par exemple, si l’objectif est d’améliorer la recherche, alors ne touchez pas au panier d’achat.
Prioriser en amont de la réunion
Enrique Besuman, Coach Agile/Produit chez Thiga, nous fait part de son expérience : “il faut absolument prendre le temps de planifier. Avant de lancer un sprint, le PO doit être en capacité de répondre aux questions suivantes : Quel est le plan ? Quelle tâche est prioritaire et pourquoi l’est-elle ? Quelle est la stratégie ?”
Le but est d’arriver à s’accorder sur un backlog de sprint. Pour être efficaces, les participants doivent déjà avoir une bonne connaissance des US. L’estimation doit également avoir été faite en amont.
Une méthode connue pour cela est d’organiser régulièrement des sessions de Refinement (ou Affinage). Elles permettent aux équipes de challenger les US et au PO de revoir sa copie pour qu’elles soient prêtes au démarrage du sprint. De mon côté, j’ai l’habitude de bloquer deux créneaux de 30 minutes chaque semaine pour présenter les nouveaux items du backlog et valider ceux qui nécessitent des modifications ou un re-découpage.
Avoir des Backlog Refinements efficaces et réguliers permet aussi de raccourcir la durée de vos sprint plannings et ainsi garder une plus grande concentration des participants.
Vous avez terminé votre préparation ? Maintenant, place au sprint planning !
💡 Si vos réunions se passent en partie ou totalement à distance, nous vous conseillons de partager votre backlog de sprint et d’avoir une représentation visuelle de votre objectif de sprint.
Exemple d’un backlog de sprint avec un objectif de sprint
🗒️ Quel est le déroulé d’un sprint planning ?
La durée du sprint planning
Le Scrum guide recommande une durée maximale de 8h pour un sprint d’1 mois. En ayant des Backlog Refinements efficaces, pour des sprints de 2 semaines, les sprint plannings auxquels je participe par exemple ne durent pas plus de 2h.
Les 4 grandes étapes du sprint planning
L’agenda reste le même au fil du temps et peut se faire en 4 temps :
- Mise en avant de l’objectif du sprint
Expliquer l’objectif du sprint lui donne un sens et permet aux participants de mieux comprendre et challenger la priorisation faite. C’est une phase rapide mais importante.
- Revue du périmètre
C’est le moment de faire une passe sur toutes les US présélectionnées par le PO par rapport à l’objectif du sprint. Je trouve ce moment particulièrement clé parce qu’il permet de s’assurer de la bonne compréhension par l’ensemble de l’équipe et de partager la priorisation des tickets.
À mon sens, il vaut mieux “perdre” un peu de temps à réexpliquer le périmètre d’une US plutôt que de se rendre compte en la testant qu’elle n’a pas bien été comprise et potentiellement mal estimée.
- Définition du backlog de sprint
En fonction de votre vélocité et de la disponibilité des développeurs, il va falloir trancher sur le périmètre à intégrer au sprint. Faut-il être optimiste et ajouter plus de tickets ou être pessimiste et avoir moins de tickets ?
Benjamin Danel, Product Ops chez Thiga confie : “au début d’une précédente expérience, j’avais tendance à pousser pour prendre plus de tickets, même si je n’attendais pas forcément des développeurs que tout soit terminé avant la fin du sprint.. Mais au final, cela créait plus de frustration qu’autre chose... Nous avons changé pour mettre le minimum de tickets, quitte à en rajouter en cours de sprint. Cela a été mieux vécu avec une impression de succès, voire de surperformance. ”
Concernant la constitution du sprint, Naban Tuo, Coach chez Thiga, recommande d'ajouter d’abord les sujets structurants (liés à l’objectif de sprint, des gros sujets) “mais il ne faut pas mettre que ça sinon il n’y a pas d’agilité, pas de flexibilité. Le challenge est d’arriver à se limiter à seulement quelques-uns”. Je rejoins cet avis, notamment pour les fins de sprint où il est difficile de prendre des US complexes qui sont impossibles à finir avant la fin du sprint.
- Découpage des items en sous-tâches
À ce stade, seule la présence des développeurs est nécessaire. Cette étape - où les développeurs discutent du plan d’actions des US - permet à chacun de mieux planifier son sprint. À l’issue de toutes ces phases, le sprint peut débuter !
Ce découpage n’est qu’un exemple que j’ai éprouvé lors de mes différentes missions. Libre à vous d’inventer votre propre déroulé.
⛔ Les 4 pratiques à éviter lors d’un sprint planning
Je viens de vous partager ma vision d’un sprint planning idéal. Mais qu’en est-il dans la réalité de beaucoup d’équipes ? Je vous présente 4 mauvaises pratiques que j’ai vu ou qui m’ont été remontées par d’autres PO :
- Le backlog de sprint ressemble à une liste décousue et sans logique de user stories
Dans ce cas, il est probable que l’objectif du sprint n’a pas été défini en amont. Chez Thiga, nous avons interrogé des dizaines de Product Owners et 34% d’entre eux déclarent que l’objectif du sprint n’est pas présenté aux développeurs. Par conséquent, l’impact de l’itération est dilué.
- L’équipe découvre les tickets pour la première fois lors du rituel et l’estimation est faite à ce moment
37% des PO interrogés chez Thiga ont déjà travaillé dans des équipes où l’estimation se faisait pendant le sprint planning. Pour ma part, j’organise des sessions régulières de Backlog Refinement dès qu’il y’a suffisamment de user stories à présenter. Cela permet d’éviter des mauvaises surprises le premier jour du sprint empêchant de travailler sur le sujet.
- Les US sont mal rédigées et les tickets présentés ne sont pas prêts
Il est vivement conseillé d’organiser un point en équipe pour discuter de la Definition of Ready. Cette définition aligne tous les membres sur l’attendu, d’une part du PO pour la rédaction d’une user story, et d’autre part sur celui des développeurs et testeur/QA concernant la qualité de la réalisation. Si vous avez des doutes sur la rédaction de vos US, n’hésitez pas à regarder l’épisode dédié de notre série "L'Effet Produit”.
- Les US passent régulièrement de sprint en sprint
Si vous constatez souvent ce cas de figure, cela veut dire que vous surestimez votre capacité. J’ai souvent pensé qu’il valait mieux être plus ambitieux quitte à faire moins que prévu, mais je me suis vite rendu compte de l’importance des “petites victoires” et leurs conséquences sur le moral de l’équipe. Résultat, j’ai fini par respecter la capacité des équipes et préparer des US “bonus” si jamais l’équipe prenait de l’avance. C’est beaucoup plus efficace !
Pour conclure, un sprint planning réussi demande de la préparation pour donner du sens au backlog de sprint et garder la concentration de toute l’équipe. La responsabilité du PO dans ce rituel peut varier de la facilitation à une simple présentation des items du backlog, mais il est clé dans la recherche d’efficacité de la réunion. J’espère que vous pourrez tirer profit de ce retour d’expériences pour améliorer vos prochains sprint plannings.
Merci à Lisa Gentili pour son aide précieuse dans la rédaction de cet article.
Pour aller plus loin : télécharger notre livre Les Clés du Product Management
