Qu’est-ce qu’un Sprint planning ?
En gestion de projet Agile, le Sprint Planning est le premier évènement d’un Sprint. Son objectif est de collaborer à la planification du travail à effectuer durant le Sprint et de définir ce qui peut être livré dans le sprint et comment y parvenir. C’est un timebox de 8 heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court. Toute l’équipe Scrum (Scrum Team) y participe c’est à dire le product Owner, l’équipe de développement, les développeurs et le Scrum Master.
Si cette planification est bien exécutée, elle crée un environnement favorable dans lequel l’équipe Agile est motivée, mise au défi et peut réussir. Les mauvaises planifications de sprint, au contraire, peuvent faire dérailler l’équipe en définissant des attentes irréalistes.
Lors d’un Sprint Planning on discute les trois sujets suivants.
Pourquoi ce sprint est-il important ?
Le Product Owner décrit l’objectif du sprint et les tâches du backlog qui vont y contribuer. Ainsi le product Owner propose comment le produit augmente sa valeur et son utilité durant le Sprint actuel.
La partie haute du Product Backlog sera composée d’éléments suffisamment petits, connus et compris par toute la Scrum Team et en cohérence avec l’énoncé précédent du Product Owner.
La Scrum Team collabore pour définir un Sprint Goal réaliste et atteignable pour la fin du Sprint.
l’équipe de développement planifie le travail nécessaire pour livrer l’objectif du Sprint. Il s’agit donc d’une négociation entre les développeurs et le product Owner pour établir une planification réaliste.
le résultat sans doute le plus important de la réunion de planification du Sprint est de permettre à l’équipe Agile de décrire l’objectif du sprint et d’expliquer comment l’atteindre. La marche à suivre est visible dans le backlog de sprint.
QUELLE EST LA DURÉE IDÉALE POUR LA PLANIFICATION DU SPRINT ?
Pour rappel c’est une timebox de 8 heures pour un sprint d’un mois. C’est-à-dire que la planification du sprint se limite à un maximum de deux heures pour chaque semaine que contient le sprint.
Vous définissez une durée maximale pour réaliser une tâche. Le Scrum Master doit s’assurer que la durée de cette planification est comprise de tous. En revanche, aucune durée minimale n’est fixée.
Que Peut-on faire dans ce Sprint ?
Les Developers sélectionnent donc les éléments du Product Backlog qui sont réalisables dans le Sprint, en discutant avec le Product Owner.
Certains facteurs ont un impact sur les estimations des développeurs comme la Définition of Done, les performances passées, les actions d’améliorations à implémenter, la capacité de la Scrum Team (congés, maladies, affectations partielles).
Comment le travail choisi sera-t-il réalisé ?
Pour chaque élément du Product Backlog (pas nécessairement tous), les développeurs planifient le travail nécessaire pour créer un Increment qui répond à la Definition of Done, avec plus ou moins de détail selon l’expérience.
Le Sprint Goal, les éléments du Product Backlog pour le Sprint, ainsi que le plan pour les livrer constituent le Sprint Backlog. On acceptera que le Sprint Backlog change selon les informations qui émergeront au cours du Sprint.
Observations importantes
1. Rien n’est jamais figé
Dans un contexte complexe, tel que le développement logiciel par exemple, les interactions ne sont jamais linéaires. Attendez-vous à que les trois sujets soient rediscutés plusieurs fois au cours d’un Sprint Planning.
2. Qualité plutôt que quantité
Le seul engament pris par la Scrum Team consiste en la réalisation du Sprint Goal. Ce n’est pas la quantité de travail, ou d’éléments du Product Backlog développés à la fin du Sprint qui compte, c’est le fait d’avoir réussi à atteindre le Sprint Goal et avoir crée un Increment Done potentiellement délivrable en production. Le plus petit qu’il soit.
3. Du « Push » au « Pull » :
Seuls les développeurs peuvent faire les prévisions sur combien d’éléments du Product Backlog seront réalisés au cours du Sprint. On dit que les Developers « tirent » (Pull) le travail à faire sur la base de l’ordonnancement du Product Backlog. Personne ne peut leur imposer ou « pousser » (« Push ») une quantité de travail à réaliser. Renoncer à accepter cette manière de travailler, signifie déresponsabiliser les Développeurs et amène souvent à des effets de bords tels que :
- Manque d’engagement,
- Manque de qualité,
- Dette technique,
- Turnover,
- etc.
4. Sélection et réalisation
La sélection des éléments du Product Backlog par les développeurs sera faite dans l’ordre défini par le Product Owner dans le Product Backlog. On ne choisira pas l’élément plus facile à réaliser, par convenance.
5. Le Product Owner doit-il/elle participer aux discussions du sujet.
L’approche Agile est basée sur l’amélioration continue, ainsi, il faut toujours s’attendre à des interactions au sein de la Scrum Team tout au long du Sprint Planning. Il est donc nécessaire que le Product Owner soit présent pour participer au discussion.
6. Accepter de travailler dans l’incertitude
Le Sprint Backlog ne sera pas détaillé pour tout le contenu du Sprint. Les équipes Agiles doivent faire preuve de flexibilité. L’important est d’avoir suffisamment de détail pour pouvoir initier le Sprint. Dans la méthodologie Agile, on acceptera l’émergence du travail au cours du Sprint.
>Ce sont les résultats qui comptent, pas le travail
Durant la planification du sprint, il est facile de se focuser sur les tâches de travail à traiter en priorité (Kanban), leurs responsables et le temps nécessaire pour les réaliser. Pour les tâches les plus complexes, le niveau d’information de départ peut être limité, l’équipe doit accepter de naviguer dans la complexité.Le framework Scrum repose sur un modèle incrémental et empirique, ce qui signifie que vous ne pouvez pas et ne devez pas TOUT planifier à l’avance. Vous apprenez grâce à vos expérimentations, feedbacks et user stories Les user stories constituent une méthode idéale pour décrire le travail du point de vue du client et augmenter la valeur délivrée.
En ajoutant des résultats clairs et mesurables à votre user story, vous mesurez clairement les performances, et vous savez précisement lorsque votre itération est finie. Notre conseil : expliquez le plus clairement possible ce qui est attendu par l’équipe pour que chacun obtienne la transparence nécessaire pour se mettre au travail. Evitez par exemple des termes vagues ou des questions.
En conclusion
A la fin du Sprint Planning, un Sprint Goal, des prévisions d’éléments de Product Backlog à développer (faites par les développeurs) et un plan pour les réaliser seront visibles dans le Sprint Backlog et le Sprint pourra démarrer.
Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum, selon le Scrum Guide. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.
Formation Professional Product Owner
Au cours des 2 jours de formation, vous développerez vos connaissances en tant que Product Owner évoluant dans un cadre de travail Agile Scrum grâce à des exercices en équipe. Vous mettrez en place de métriques pour suivre la création de valeur et la bonne livraison du produit sur le marché.
- Prise en charge OPCO
- 2 tentatives de certifications incluses
