Sprint Planning meeting en scrum

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

Vous pouvez regarder la vidéo de La Minute Agile qui explique ce qu’est la Sprint Planning :

Sprint planning en ouverture de Sprint

La Sprint Planning est la cérémonie que l’équipe scrum réalise en ouverture de Sprint pour cadrer le sprint qui démarre. 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.

Pour bien travailler sa Sprint planning, il est essentiel de prendre du temps. Nous parlons :

• de 2 à 4h de sprint planning pour un sprint de 2 semaines
• de 4 à 8h de sprint planning pour un sprint de 4 semaines.

Ca peut paraitre beaucoup au premier abord, mais c’est le temps nécessaire pour bien la réaliser.

En sprint planning, nous commençons par un état des lieux

Avant même de travailler sur le sprint qui démarre, il faut commencer par faire un état des lieux de l’avancement du produit. Il est indispensable que l’ensemble de l’équipe soit clair sur l’avancement du produit.

Faire une sprint planning sans savoir l’état d’avancement du produit peut amener à la définition de mauvais objectifs.

En sprint planning, on définit 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 l’équipe scrum définisse concrètement l’objectif du sprint en début de la Sprint Planning.

L’objectif du sprint est définit par une phrase compréhensible par tous. Par exemple : « Nous voulons livrer une première version du panier aux utilisateurs ».

L’ensemble des items (« user-story », « tâche technique »…) n’ont pas l’obligation de répondre à l’objectif du sprint ; cependant les items répondant à cet objectif doivent y être inclus. Pour faire simple, il ne faut pas définir l’objectif du sprint par rapport aux items que nous voulons développer ; mais, nous allons définir les items qui répondront à l’objectif du sprint.

L’équipe de développement pourra amener l’équipe au complète à revoir l’objectif du sprint si elle considère à un moment de la sprint planning, qu’elle ne peut pas s’engager à tout livrer.

Un objectif ce n’est pas une série de numéro

Si vous avez bien compris ce paragraphe, vous comprendrez aisément que l’objectif du sprint ne peut pas être : « nous devons livrer le JIRA25, JIRA26, JIRA27… ».

L’objectif du sprint doit être une phrase compréhensible par tous ; et la raison est plutôt simple. En cours de sprint, nous pouvons nous apercevoir que l’objectif du sprint ne pourra pas être atteint sans une nouvelle user-story. Le Product Owner ajoutera alors une user-story (en accord avec l’équipe de développement) au cours de ce sprint pour que l’objectif soit atteignable.

ATTENTION !!! Il est tout a fait possible de rajouter des items en cours de sprint. Le scrum n’interdit absolument pas cette pratique agile, bien au contraire. En scrum, l’objectif du sprint est fixe mais le scope est variable. Un sprint devient caduque uniquement si son objectif n’est plus atteignable.

Maintenant, il faut que cette user-story respecte la « Definition of Ready », si vous utilisez cette pratique, pour la voir dans la colonne « ready ».

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

Choix des items en sprint planning

Maintenant que notre objectif est défini en ce début de sprint planning, l’équipe scrum va choisir les items qui répondront à l’objectif du sprint. L’ensemble de ces items ne doivent pas dépasser la capacité de faire de l’équipe de développement.

Seule l’équipe de développement est tenue de donner son avis sur sa capacité de faire ; et même si leur avis sur ce sprint va à l’encontre des indicateurs tels que la vélocité. La vélocité n’est qu’un indicateur pour aider le product owner à avoir une vision et/ou à l’équipe de développement de voir le chemin parcouru.

Les items du sprint précédent

L’équipe de développement est autorisée à ré-estimer le point d’effort de chacune des demandes du sprint précédent qui ont fini en « work in progress » si elle en ressent le besoin pour mieux visualiser sa capacité de faire ; il n’y a aucune obligation de le faire.

Si vous faites cette pratique et que l’estimation est importante pour l’équipe, voici l’astuce que je peux vous donner. Nous allons noter le nouveau point d’effort de la demande sans pour autant effacer le précédent point d’effort.

Pour ceux qui font de la prédictibilité, nous gardons le point d’effort le plus haut pour le calcul de la vélocité (et pour la prédictibilité) et le dernier point d’effort attribué 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é.

Il n’est pas obligatoire qu’un item non terminé du sprint précédent revienne dans ce sprint ; cependant, quand un item est entamé, il peut s’avérer perturbant pour l’équipe de développement de ne pas le reprendre dans le nouveau sprint.

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

Les items complémentaires (en sprint planning) ?

Si l’équipe de développement estime, qu’elle peut encore prendre des items complémentaires à ceux défini pour répondre à l’objectif du sprint, elle partira en négociation avec le Product Owner pour ajouter de nouveaux items complémentaires.

Les raisons des ajouts peuvent être multiples :

• avancer sur d’autres fonctionnalités à forte valeur ajoutée
• faire des analyses sur des outils qui pourraient améliorer le produit
• retravailler sur des aspects UX/UI

En effet, si les compétences sont centrées sur des membres en particulier de l’équipe de développement, il est possible d’avoir des membres qui auront une charge de travail plus faible que d’autres membres. ils pourront donc en sprint planning proposer de travailler sur d’autres aspects avec pour objectif d’améliorer le produit.

Article sur le sujet à lire absolument : Front, back, UI en scrum… Faux problème !

Peut-on ré-estimer en sprint planning ?

En général, l’estimation est faites en product backlog refinement (PBR) ;  cependant, rien n’interdit de faire des estimations en sprint planning. Si l’équipe de développement en ressent le besoin pour mieux visualiser sa capacité de faire, elle peut estimer :

• les nouveaux items non présentés en PBR
• des items où l’équipe pense s’être trompée précédemment
• les items du précédent sprint

Nous recommandons cependant de ne pas focaliser votre activité sur les estimations (et la prédictibilité) car cela amène rapidement à de nombreuses dérives.

Définir le travail à faire en sprint planning sur les items du sprint

Quand tout le scope du sprint est défini, l’équipe de développement 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.

Et pour être plus précis, l’équipe de développement doit définir tous les travaux qui sont à réaliser pour pouvoir livrer chaque item (dans la mesure où l’équipe a assez d’éléments pour le faire). Si nous parlons souvent des tâches de développement front/back, cela peut également concerner d’autres aspects :

• aspects architectures
• travaux UX
• aspects UI
• éventuellement fonctionnel

En effet, le sprint peut comporter des items qui ne sont pas « ready » donc des travaux fonctionnels peuvent être exigés. L’équipe de développement fera ce travail de découpage plus tard quand tous les éléments nécessaires seront présents.

ATTENTION !!! Tous les items en sprint planning ne sont pas obligatoirement « ready » lors de la sprint planning. Si l’atteinte de l’objectif exige l’ajout d’un item à travailler, il faudra le rajouter. L’équipe de développement saura qu’il faudra le faire quand il sera considéré « ready ».

D’ailleurs, si l’équipe de développement considère à ce moment là qu’un travail de recherche sera nécessaire pour réaliser un item et qu’elle ne peut plus s’engager à atteindre l’objectif du sprint défini précédemment, l’équipe de développement et le Product Owner reverront ensemble l’objectif du sprint voire le scope de celui-ci.

Exemple de découpage technique

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

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
• test
• UI

C’est aux membres de l’équipe de développement de faire le découpage affiné le plus censé et le plus simple à leurs yeux ; donc, leur imposer une règle de découpage, c’est ne pas se donner le maximum de chance pour réussir.

Quand tous les travaux nécessaires pour réaliser au minimum les premiers items sont définis, la séance de sprint planning est levée et la réalisation peut commencer.

Conclusion scrum Sprint Planning

La Sprint Planning est la cérémonie Scrum pour démarrer un sprint qui peut durer jusqu’à 8h pour un sprint de 4 semaines. Elle est souvent sous-estimée alors qu’elle permet de structurer l’ensemble du sprint. En effet, en expédiant votre sprint planning, vous risquez d’avoir des sprints moins stables et vivre quelques mauvaises surprises.

J’espère que cet article vous aidera à mettre votre Sprint planning en place.

Encore une question à propos de la sprint planning ? N’hésitez pas à poser vos questions sur la sprint planning en commentaire. En effet, la sprint planning est une cérémonie pas si simple à maitriser.

A vos sprint planning !!!

Et si vous avez des questions sur la sprint planning, n’hésitez pas à la poser en commentaire.