La Sprint Planning Meeting en Scrum

En quoi consiste la Sprint Planning Meeting en Scrum ? C’est la cérémonie d’ouverture essentielle pour bien organiser vos sprints. Nous allons voir comment faire pour mettre en oeuvre cette cérémonie Scrum.

Ouverture de Sprint

La Sprint Planning Meeting est la cérémonie qu’on réalise en ouverture de Sprint avant même de commencer les Sprint. Commencer un Sprint sans même le préparer n’a que peu de valeur ; il est difficile de travailler sans avoir une vision du travail à réaliser.

Sprint Scrum 2.0
Sprint Scrum 2.0

Définissons nos objectifs

Pour que l’ensemble de l’équipe se concentre sur ce qui est attendu essentiellement à la fin du sprint, il est indispensable que le Product Owner définisse concrètement les objectifs du sprint en début de la Sprint Planning Meeting.

Bien que rien ne l’impose, je vous conseille avec l’expérience de ne pas définir l’ensemble du sprint comme un objectif à atteindre au risque d’être souvent déçu. Si votre objectif contient 60% des demandes à traiter pendant toute la durée du sprint, vous aurez plusieurs effets positifs non négligeables :

  • il y a beaucoup de chance d’atteindre l’objectif (comme ça concerne 60%) donc moins de frustration en fin de sprint
  • on priorise d’une certaine façon le contenu du sprint
  • on ne se risque pas de mettre la pression à l’équipe.

Je vous laisse décider si vous désirez ou non appliquer cette règle mais j’ai eu beaucoup d’effets positifs en l’appliquant d’où ma recommandation de le faire.

Quand les objectifs sont définis, n’hésitez pas à les rappeler tout au long de la Sprint Planning Meeting voire de les écrire directement sur le board. Vous pourrez d’ailleurs les laisser afficher tout au long du sprint sur votre management visuel.

Retour dans le futur

Maintenant que nos objectifs sont définis, l’équipe va devoir ré-estimer le point d’effort (la complexité) de chacune des demandes du sprint précédent qui ont fini en “work in progress” ; il est fort probable que le point d’effort de ces demandes ne soit plus le même car l’équipe a déjà travaillé dessus.

Nous allons noter le nouveau point d’effort de la demande sans pour autant effacer le précédent point d’effort. Voici une façon de le faire sur vos post’its :

réestimer une complexité
réestimer une complexité

Pour ceux qui font de la prédictibilité, nous gardons la complexité la plus haute pour le calcul de la vélocité (et pour la prédictibilité) et la dernière complexité attribuée pour le sprint en cours (pour mieux déterminer la capacité de faire de l’équipe sur le sprint et sur le Burndown Chart).

Dans cet exemple en image, l’équipe a redéfinie le point d’effort à 5 alors que celui-ci était de 8 lors du précédent sprint. Nous considérerons 5 en point d’effort pour la capacité de faire de l’équipe et nous enlèverons 5 du Burndown Chart quand elle passera en Done. Par contre, nous mettrons 8 dans la vélocité du sprint afin de bien gérer notre prédictibilité.

Ce travail de ré-estimation sera à faire sur l’ensemble des demandes concernées avant de passer à la suite. Je rappelle que ce travail est inutile sur les demandes qui étaient déjà en “todo” lors du précédent sprint.

N’hésitez pas à utiliser la technique du Poker Planning pour faire vos estimations : Estimer ses user-story avec le Poker Planning

Le choix des demandes à traiter

Le Product Owner va alors proposer aux développeurs l’ensemble des demandes qu’ils devront prendre en charge durant le sprint qui démarre qui répondront dans l’ensemble aux objectifs fixés en début de cérémonie.

Il devra respecter la capacité de faire de l’équipe de développement et ne pas proposer trop de demandes afin d’éviter au maximum de mettre cette équipe en pression.

En général lors des trois premiers sprint de l’équipe, on propose souvent aux développeurs de déterminer eux-même ce qu’ils sont capables de faire en terme de charge (en leur expliquant que l’erreur d’estimation n’est vraiment pas grave) ; ensuite nous utilisons des systèmes de prédictibilité tel que celui proposé par l’article suivant : Calculer la somme des complexités autorisées

On estime plus en Sprint Planning Meeting

Si on estimait toujours en Sprint Planning Meeting dans un passé lointain, il est devenu assez rare de le faire pour des raisons totalement justifiées. A présent on ne fait que les ré-estimations mais jamais les nouvelles estimations.

Le fait d’estimer dans cette cérémonie, on se risquait de devoir affiner les demandes (principalement les user-stories) en live parce que le PO n’avait pas forcément pensé à tout lorsqu’il les avait écrit. Il sera également dans l’obligation de construire son sprint backlog en direct et donc peut-être de devoir revoir ses objectifs en cours de cérémonie.

Tous ces points multipliaient le besoin de prise de temps et on pouvait rapidement se retrouver avec une cérémonie qui dure une demie-journée ; on ajoute la fatigue et les pertes d’attention de rester des heures en réunion et on se retrouvait avec un format pas forcément des plus productifs.

Il existe deux concepts proches pour faire les estimations en amont du Sprint Planning Meeting afin de permettre à cette dernière d’être rapide et de fluidifier au maximum les processus (en préparant bien le travail en amont) :

Backlog Grooming Meeting et Look ahead Meeting
La Product Backlog Refinement

En suivant l’un de ces deux concepts ci-dessus (bien qu’ils soient très proches), le Product Owner arrivera en Sprint Planning Meeting en connaissant concrètement les objectifs du sprint et son contenu.

Pour le PO, au lieu de se retrouver avec une incertitude de 40% sur le contenu du sprint, celle-ci ne sera plus que que de 10% maximum dans la très grande majorité des cas.

Ne jamais dire jamais

Il est vrai que j’ai dit “mais jamais les nouvelles estimations” ; cependant si le Product Owner a impérativement besoin d’une estimation exceptionnelle d’une user-story très simple mais indispensable à traiter, l’équipe de développement ne doit pas non plus se braquer à refuser l’estimation de celle-ci.

Nous sommes dans des projets agiles, il faut s’adapter et ne pas faire l’erreur de tout suivre à la lettre si cela ne nuit pas au fonctionnement de l’équipe ; et dans ce cas, il y a peu de raison que cela nuise à l’équipe.

Découpage des demandes en sous-tâches

Quand tout le sprint est défini, l’équipe technique devra découper chacune des demandes en sous-tâches techniques. Il peut s’avérer qu’une demande ne soit représentée que par une seule sous-tâche technique.

Il n’y a pas de règles exactes pour ce découpage technique ; je conseille aux équipes techniques de faire le découpage avec lequel elle se sentira le plus à l’aise possible.

Si nous avons comme demande technique : “refactoring du front-office”, nous pourrions avoir en sous tâche : “page d’accueil”, “panier”, “fiche produit”, “api panier”, “api offre”….

Si nous avons comme user-story  : “En tant que client, je souhaite ajouter un produit au panier”, nous pourrions avoir “IHM”, “API panier”, “BDD panier”…

A vos développeurs de faire le découpage affiné le plus censé et le plus simple à leurs yeux ; leur imposer une règle de découpage, c’est ne pas se donner le maximum de chance pour réussir.

Quand toutes les demandes sont découpées, la séance est levée et les développements peuvent commencer ; on dit alors que le sprint commence.

One Reply to “La Sprint Planning Meeting en Scrum”

Laissez une réponse