Le sprint planning

• Comment organiser un sprint planning ?
• Comment s’assurer que le planning est réaliste ?
• Et surtout, quel est le but du sprint planning ?

Le sprint planning est sans aucun doute l’un des exercices les plus difficiles du Scrum.

Dans ce post, je vous montre que le sprint planning est tout sauf une cérémonie d’une heure ou plus.
Non, le sprint planning ne se joue pas dans une salle de réunion avec son équipe, c’est un travail que le product owner bâtit au quotidien.

Qui organise le sprint planning ?

Normalement c’est le scrum master qui est censé le faire… Mais dans la majorité des cas c’est le Product owner qui le fait.

Primo, toutes les organisations n’ont pas forcément de Scrum master, du coup c’est le product owner qui s’en charge par défaut.

Deuxio, je ne prêche pas pour ma paroisse mais je trouve que ça n’a pas de sens de le faire faire par une autre personne que le product owner.

Soyons clair, c’est vous qui écrivez les users stories et participez au backlog grooming. C’est aussi à vous de définir l’objectif et le contenu du sprint.

Il est donc un peu ridicule de ne pas organiser le sprint planning et de laisser une personne tierce expliquer ce que l’on a en tête.
Ceci n’est évidemment que ma vision des choses, mais j’assume entièrement ce que je dis.

Quand doit avoir lieu le sprint planning ?

Normalement le 1er jour du sprint.

Pour ma part, mes sprints ont une durée de 2 semaines et commencent le lundi pour se terminer le vendredi de la semaine suivante.

J’aime organiser mon sprint planning le lundi matin à la première heure.

Je connais également des product owners qui l’organisent le dernier jour du sprint.
Je ne pense pas qu’il y ait de règles précises à ce niveau là.

Personnellement, étant donné que mes sprints se terminent un vendredi, je pense que ce n’est pas un bon jour pour se projeter sur le travail futur.
En général le vendredi tout le monde pense à son week-end et n’est pas motivé à l’idée de penser au lundi suivant.

Par ailleurs, quelque soit le dernier jour de votre sprint, il est coutume d’organiser une rétrospective ce jour là.  A mon avis c’est un peu lourd d’avoir la rétrospective et le sprint planning dans la même journée.

Ceci étant dit, faites pour le meilleur et le bien de votre équipe.

Combien de temps doit durer le sprint planning ?

Évidemment, tout dépend de la durée de votre sprint. Un sprint d’une semaine nécessite moins de temps de planning qu’un sprint de 4 semaines.

Néanmoins, au risque de passer pour un inconscient auprès de la police scrum encore une fois, ma réponse est simple:

Le moins de temps possible

La première raison est simple et personnelle.

J’ai pour principe de minimiser le temps de meeting de mes collaborateurs afin de maximiser leur temps de production.

Si on commence à organiser des sprint plannings de 2 heures ou plus, suivi de rétrospectives, de backlog grooming, de démos etc…  la semaine de travail est réduit à 4 jours voir moins.
A ce stade le process devient contre-productif et pénalise le sprint.

Ensuite, la raison principale est qu’un sprint planning qui nécessite de longues explications et un sprint planning mal préparé.

Je m’explique…

Tout est dans la préparation

On a tendance à penser que le sprint planning est un départ.

Du point de vue de votre équipe, en effet il s’agit du commencement du sprint.

De votre point vue en revanche, il s’agit d’une conclusion.

Quand je parle de conclusion, je veux dire que le sprint planning vient achever tout le travail préparatoire que vous avez réalisé les semaines précédentes :

• Product roadmap
• Définition des user stories
• Chiffrage des user stories (grooming)

Evidemment, une fois le sprint planning achevé, le travail de développement commence.

Mais de votre point vue, votre job est terminé.  Si votre équipe est agile et autonome, votre job consiste à suivre au quotidien les avancées mais la majeure partie du reste consiste à préparer le sprint suivant.

Tout part du backlog :

Le sprint planning est l’action de planifier les user stories à réaliser dans le prochain sprint par l’équipe de développeurs.

L’ensemble de vos user stories se trouvent dans votre backlog et normalement celui-ci doit être bien ordonné.

Si on suit cette logique, le sprint planning consiste à sélectionner les stories qui sont en haut du backlog.

Oui mais…

Avant tout, même si votre backlog est ordonné en terme de priorité, certaines de vos user stories sont déjà chiffrées et d’autres pas encore.

La condition sine qua non pour établir un sprint planning est de sélectionner uniquement des user stories déjà chiffrées.
Si une user story n’est pas chiffrée, elle ne respecte pas la « Definition of Ready » et vous ne devez pas l’inclure dans un sprint.

Ok, dans ce cas, à partir du moment où j’ai déjà des user stories chiffrées et que je connais la vélocité de mon équipe sur un sprint, il suffit alors de choisir le bon chiffrage et les bonnes priorités :

Exemple :

• Imaginons que le Sprint de Martin qui est product owner dans une startup FinTech à une durée de 2 semaines.
• L’équipe de Martin est composée de 5 développeurs
• Martin travaille avec les mêmes développeurs depuis des années. Il connaît leur cadence de travail et est capable à l’avance d’estimer leur vélocité.
• Par exemple, pour faire simple, Martin sait que chaque développeur est capable de réaliser 15 points par sprint.
  Grâce à cette estimation, Martin peut calculer que la vélocité d’un sprint est de 75 points (5X15).
• Dans cet exemple, pour planifier son sprint, Martin devra choisir un nombre de Users stories dans son backlog ne dépassant pas 75 points au total. Cette estimation lui permet d’avoir un planning de développement réaliste.

Bravo, en théorie vous avez tout bon. Techniquement c’est exactement ce qu’il faut faire.
Simplement dans la réalité, ça ne se passe pas aussi facilement.
Il existe beaucoup de paramètres qui vont venir perturber votre plan

N’oubliez pas les facteurs X 

Au delà de ce que vous envisagez, vous devez faire face à des forces contraires qui vont vous obliger à vous adapter.

1. Les users stories inachevées

Vous finirez rarement un sprint avec toutes les users stories achevées.
Ainsi, quand vous commencez un nouveau sprint, vous débutez toujours avec une dette technique.
Vous devez être en mesure d’estimer l’effort nécessaire pour terminer les tâches restantes.

Exemple : 

• Imaginons que pour reprendre l’exemple du point précédent, la vélocité de votre équipe par sprint est de 75 points.
• L’ensemble des stories restantes à faire dans votre sprint précédent totalise un nombre de 15 points
• Ainsi, il ne vous reste que 60 points pour planifier le reste de votre sprint.

Attention, il se peut que par moment, vous décidiez de ne pas poursuivre les développements des users stories restantes.
En théorie, ça n’a pas de sens et remet en cause l’objectif de votre sprint précédent.
Cependant dans certains cas, s’il vous reste des tâches mineures (basse priorité) comparativement aux nouvelles tâches à planifier, la question peut se poser.

A retenir :

Vous pouvez abandonner des users stories restantes à condition qu’elles n’ont pas été commencées.
Si certaines sont déjà en cours, finissez les. Ne gaspillez pas le temps des développeurs. Vous allez les frustrer et vous faites perdre de l’argent à votre entreprise.

2. Un calendrier allégé

Autre paramètre à prendre en compte : le calendrier.
Pour une sprint de 2 semaines par exemple si vous avez 5 développeurs et une vélocité de 75 points,
La vélocité jour / équipe est de 7,5 points 
La vélocité jour / homme est de 1,5 points  

Si au cours de ce sprint, il y a 2 jour férié, cela fait 2 jours off.
Dans ces conditions, vous allez devoir recalculer la vélocité de votre équipe en fonction de la durée du sprint. 
Soit 75 – (2 x 7,5) = 60 points

De la même façon, si vous savez pas avance, qu’un des membres de l’équipe s’absentera quelques jours au cours du sprint, vous devrez soustraire 1,5 point par jour / homme.

A retenir:
Une fois que vous avez réussi à stabiliser une vélocité équipe / sprint sur plusieurs semaines, calculez la vélocité  jour / équipe et la vélocité  jour / homme.
Evidemment ce n’est pas une science exacte, en particulier la vélocité  jour / homme qui peut varier d’un développeur à l’autre.  Cependant même si cela peut vous paraître too much, cela vous donne un bon proxy.
Si vous voulez éviter de mauvaises surprises dans le calcul de votre sprint planning, ces paramètres ont un poid.

3. Les invités surprises

Finalement, le dernier facteur X le plus courant, j’ai nommé les invités surprises.
Les invités surprises sont ma façon de nommer ironiquement les galères que vous allez rencontrer au cours d’un sprint.
Il y en a 3 principales :

• Les bugs en production à régler d’urgence
• Les absences non planifiés (un collaborateur est malade)
• Un problème d’estimation dans une user story

Je ne vais pas faire du cas par cas. Ma méthode radicale pour anticiper tout invité surprise est de garder une marge de 20% de temps libre qui sera alloué à la résolution de ces problèmes.

Dans l’exemple de 75 points par sprint, 20% équivaut à 15 points.

Cela peut vous paraître beaucoup, mais la marge que je calcule a été établie en fonction de l’historique avec l’équipe avec laquelle je travaille et la plateforme sur laquelle nous opérons.
A vous d’estimer votre marge de temps libre.

Au final, quand vous prenez en compte toutes ces contraintes, votre sprint planning devient plus réaliste.
On se rend compte très vite que l’on ne peut pas mettre tout ce qui est théoriquement possible de faire. Il faut équilibrer entre les nouvelles users stories et les contraintes existantes ou envisageables. 

Réalité du sprint planning

Qu’est ce que l’on met réellement dans le sprint ?

Un sprint ce n’est pas une juste collection de nouvelles users stories et de bugs à résoudre.
Le contenu de votre sprint doit avoir un sens et un objectif.
Dans le post sur “comment écrire une user story ? “. je vous parle du framework Invest.
Et, en particulier, je vous décris que je divise le Framework en 2.
J’applique une partie (appelé le SET) à la user story, et l’autre que j’appelle le Framework VIN que j’applique au sprint.

Pour rappel, voici les 3 principes du VIN.

V -> Valeur
I – > Indépendant
N -> Négociable

Je vous explique comment j’applique ces principes pour savoir si mon sprint est cohérent.

Valeur :

Le sprint doit rendre service à l’utilisateur.
L’ensemble des users stories qui forment votre sprint doivent avoir une valeur business et pas une solution technique.

La raison est que l’ensemble du contenu réalisé à l’intérieur de votre sprint doit être livré à vos utilisateurs / clients.
En ayant cela en tête, vous devez orchestrer toutes les user stories pour former une cohérence.

Par exemple :

Imaginons que l’objectif de votre sprint est d’optimiser le chargement des pages de votre site internet pour améliorer l’expérience utilisateur de vos clients.

A vous de sélectionner toutes les users stories chiffrées dans votre backlog qui impactent de près ou de loin cet objectif.

Indépendant :

Un sprint doit être indépendant vis-à-vis des autres sprints.
À la fin du sprint, vous avez une livraison à fournir.
Si vous ne pouvez rien livrer à vos utilisateurs car il manque des éléments qui sont incluent dans votre prochain sprint, alors votre sprint est mal planifié.

Sprint = Livraison utilisateurs

Négociable :

L’objectif du sprint n’est JAMAIS négociable. L’objectif est fixe.
En revanche, ce que j’entends par négociable, c’est le scope.
Si en cours de sprint, vous vous apercevez qu’ils vous manque une user story clé ou qu’à l’inverse une autre n’est pas si importante pour atteindre votre objectif, vous pouvez négocier en cours de route pour affiner le contenu du sprint.
A partir du moment où ce changement permet de maintenir voire même de renforcer l’objectif du sprint, cette négociation est bénéfique.

Veuillez juste vous assurez que les changements apportés n’impactent pas négativement le chiffrage.

Mon conseil:

Ayez en tête des quick wins, j’entends par là des petites users stories faciles à faire.
Si vous apportez des user stories complexes en cours de route, vous risquez de compromettre votre sprint.
 

Bonus : Ma petite astuce

Pour finir, maintenant que vous avez tous les paramètres en tête pour réussir votre sprint planning.
Je vous partage ma façon de m’organiser pour planifier mon sprint en utilisant la fonction backlog dans Jira.
Si vous n’utilisez pas Jira, vous pourrez en principe appliquer cette méthode dans la majorité des autres outils de gestion de projets agiles.

Toujours avoir un sprint d’avance

Dans Jira, vous avez un bouton “Créer un sprint” en haut du backlog.

En général, on se sert de ce bouton pour créer un nouveau sprint pendant la cérémonie du sprint planning.

Pour ma part, je n’attends pas la cérémonie du sprint planning pour créer un nouveau sprint.
Plutôt que de laisser mes users stories prioritaires en haut de mon backlog, je les place dans un nouveau sprint appelé “To groom” (Traduction: A estimer).

En faisant ca, cela me permet d’arriver dans une séance ce backlog grooming en connaissant exactement mon scope.

Quel rapport avec le sprint planning ?

Quand vous faites une séance de grooming, vous avez forcément en tête votre prochain sprint. Le problème c’est que les développeurs ne sont pas dans votre tête et ne connaissent pas votre vision.
Ainsi détournant la fonction sprint dans Jira et en isolant toutes les users stories dans un dossier “To Groom”, je présente en avance le prochain sprint à mon équipe.

Plutôt que de groomer les users stories indépendamment, je consacre 10 minutes à présenter le prochain sprint dans le backlog grooming.

Cette étape est essentielle dans mon process. En faisant cela je prépare déjà mon sprint planning et j’embarque tout le monde sur l’objectif du prochain sprint 1 semaine en avance au minimum.

Par expérience, c’est le meilleur moyen de préparer un sprint planning.
Si au cours de la réunion, vous rencontrez des frictions de la part des développeurs, vous avez largement le temps d’ajuster.
En revanche, en présentant votre plan le jour de la cérémonie du sprint planning, si quelque chose coince, vous allez devoir faire des compromis au dernier moment.
Je le répète, ne pas être préparé peut vous pénaliser tout le sprint.

Ca ne s’arrête pas là 

Une fois la séance de grooming terminé, je retourne dans Jira et je crée encore un nouveau sprint que j’appelle “Futur sprint”.
Dans ce sprint, je place toutes les users stories chiffrées lors du grooming.
Ainsi, cela me permet de voir immédiatement la charge de travail pour le prochain sprint.

• Imaginons, que la vélocité sprint de mon équipe soit de 75 points.
• En plaçant la totalité des users stories chiffrées de mon dossier “To groom”, j’arrive à un total de 25 points

Dans ce cas, même en ajoutant une marge de temps libre de 20% (15 points) et en prenant en compte les stories en cours qui seront inachevées, je sais que j’ai encore de la marge.
Je peux me permettre d’inclure des nouvelles stories supplémentaires.

Dans le cas contraire, si mon total de points est trop importants, j’ai le temps d’ajuster mon sprint.

Le jour J

Le jour de la cérémonie du sprint planning, après avoir expliquer les objectifs du prochain sprint, je montre la vision du prochain sprint à mes collaborateurs dans mon backlog.

Dans la majorité des cas, le planning est quasi validé.
Notre discussion lors du backlog grooming nous a permis de définir les contours du sprint et j’ai évité de créer des surprises.

La seule chose qui reste à faire est d’estimer l’effort nécessaire pour terminer les tâches inachevées lors du sprint précédents.

Au delà de l’aspect organisationnel, le gros avantage est que cette méthode est totalement transparente.
L’équipe a accès au backlog en permanence et connaît ma vision. Chaque membre peut suivre la construction du futur sprint et participer aux ajustements n’importe quand.

Et donc..

Au final, que vous adoptez cette méthode ou une autre, retenez que le sprint planning est un exercice délicat seulement s’il n’est pas préparé.

Le sprint planning ne se décide pas en 1 heure dans une salle de réunion entre collègues.
Cette séance doit juste être une formalité pour finaliser des accords passés entre vous et votre équipe pendant les jours précédents.

Votre job n’est pas d’apporter un objectif sprint lors d’une réunion et de l’imposer.
Même si votre plan semble parfait, croyez moi vous rencontrerez des résistances.
Les gens n’aiment pas les surprises dans l’environnement professionnel.

Votre rôle est d’embarquer vos collaborateurs crescendo.
Tout commence à partir de votre backlog et l’essentiel doit se jouer au niveau du backlog grooming.

Si vous avez d’autres méthodes pour préparer un sprint planning, partagez les dans les commentaires. Je suis preneur.

Bon sprint planning