Bonjour !
Dans la leçon précédente, nous avons appris à prioriser le backlog avec la méthode MoSCoW, ce qui nous a permis de distinguer les fonctionnalités indispensables (Must have) des autres. Nous avons donc un backlog de produit ordonné par valeur métier. Il est maintenant temps de transformer cette liste de souhaits en un plan d'action concret.
L'objectif de cette leçon est d'apprendre à planifier un sprint en sélectionnant les tâches prioritaires du backlog. C'est le moment charnière où l'équipe s'engage sur un objectif précis pour les semaines à venir et définit le travail nécessaire pour l'atteindre. Pour vous, en tant que développeur, c'est la cérémonie qui transforme les exigences client en un véritable plan de développement technique.
1. Le Sprint Planning : Qu'est-ce que c'est ?
Le Sprint Planning est le premier événement d'un sprint. C'est une réunion de travail collaborative où toute l'équipe Scrum (Product Owner, Scrum Master et l'équipe de développement) se réunit pour définir ce qui peut être livré dans le sprint à venir et comment ce travail sera réalisé.
Pour avoir une vue d'ensemble complète et dynamique de cet événement, je vous propose de visionner la vidéo suivante. Elle est excellente pour comprendre la philosophie et le déroulement du Sprint Planning.
Sprint Planning c'est quoi ? Définition par Scrum Life #ScrumGuide
Cette vidéo de la chaîne Scrum Life est une des meilleures introductions en français au Sprint Planning. Elle décompose l'événement en trois questions fondamentales : le 'Pourquoi', le 'Quoi' et le 'Comment'.
Regardez la vidéo à partir de 1:49 jusqu'à la fin (8:07). Portez une attention particulière à la structure en trois parties : Le Pourquoi (Why) : La définition du Sprint Goal. Le Quoi (What) : La sélection des éléments du backlog. Le Comment (How) : La planification de la réalisation par l'équipe de développement.
Comme la vidéo l'explique très bien, le Sprint Planning n'est pas une simple distribution de tâches. C'est un atelier stratégique qui aboutit à un engagement collectif.
Les rôles sont clairs :
- Le Product Owner arrive avec un objectif en tête, basé sur les priorités du Product Backlog (nos "Must Haves"). Il représente la voix du client et du business.
- L'Équipe de Développement évalue la proposition, pose des questions, et détermine ce qu'elle peut raisonnablement s'engager à réaliser. C'est l'équipe qui a l'expertise technique.
- Le Scrum Master facilite la réunion, s'assure que les règles de Scrum sont respectées et aide l'équipe à rester dans les temps (le timeboxing).
2. Les prérequis du Sprint Planning
Pour commencer un Sprint Planning, l'équipe a besoin de deux éléments principaux :
- Un Product Backlog priorisé et estimé : C'est exactement ce que nous avons préparé dans les leçons précédentes. Nous avons des user stories, estimées avec des story points, et priorisées avec MoSCoW.
- La capacité de l'équipe (ou vélocité) : Il s'agit de la quantité de travail (en story points) que l'équipe est capable d'accomplir en un sprint. Pour une équipe existante, on se base sur la moyenne des sprints précédents. Pour une nouvelle équipe, les premiers sprints servent à établir cette mesure ; on commence par une estimation prudente.
Le but du Sprint Planning est de prendre des éléments du Product Backlog pour créer le Sprint Backlog. L'image suivante illustre parfaitement cette transition.
3. Le déroulement : du "Pourquoi" au "Comment"
Le processus se déroule en trois grandes étapes, comme vu dans la vidéo. Reprenons-les avec notre projet "Chez Antoine".
Étape 1 : Le Pourquoi - Définir le Sprint Goal
Tout commence par l'objectif. Plutôt que de dire "on va faire les stories US1, US2 et US3", le Product Owner propose un objectif qui donne du sens au travail.
- Exemple pour "Chez Antoine" (MVP) : En s'appuyant sur nos Must Haves de la leçon précédente, un bon Sprint Goal pourrait être : "Permettre aux nouveaux clients de passer une commande complète, de la consultation de la carte jusqu'au paiement, sans avoir à créer de compte."
Ce but est clair, mesurable et motive l'équipe. Il servira de fil rouge pendant tout le sprint.
Étape 2 : Le Quoi - Sélectionner les User Stories
Avec le Sprint Goal en tête, l'équipe de développement analyse le haut du Product Backlog (les Must et Should haves) et sélectionne les user stories qui contribuent directement à cet objectif.
- Processus : L'équipe "tire" (pull) les stories une par une, en additionnant leurs story points, jusqu'à ce que la somme atteigne une valeur proche de sa capacité.
- Exemple pour "Chez Antoine" :
- US1: Consulter la carte (5 points)
- US2: Ajouter au panier (3 points)
- US3: Valider et payer (8 points)
- Total : 16 points. Si la capacité de l'équipe est d'environ 15-20 points, c'est un engagement réaliste.
Un point crucial ici est que l'équipe de développement a le dernier mot sur la quantité de travail qu'elle embarque. Le Product Owner ne peut pas forcer l'équipe à prendre plus de travail. C'est un principe fondamental de Scrum qui responsabilise l'équipe.
Pour approfondir la création de cet artefact central qu'est le Sprint Backlog, l'article suivant est une excellente ressource.
Qu'est-ce qu'un backlog de sprint ? Ses avantages et comment en créer un
Cet article d'Atlassian, une référence dans l'outillage Agile (Jira), explique en détail ce qu'est un Sprint Backlog et comment le construire. Il vous servira de guide pratique.
Lisez la section 'Comment créer un backlog de sprint'. Elle vous donne une méthode claire en 4 étapes qui synthétise ce que nous sommes en train de faire.
Étape 3 : Le Comment - Décomposer le travail en tâches techniques
Une fois les user stories sélectionnées, le travail n'est pas terminé. C'est là que votre expertise de développeur entre en jeu. L'équipe décompose chaque user story en une liste de tâches techniques concrètes.
- Exemple pour "US3: Valider et payer" (8 points) :
- Créer le contrôleur Spring Boot pour la gestion du paiement.
- Implémenter le service métier pour calculer le total de la commande.
- Configurer l'API de paiement (ex: Stripe, PayPal).
- Créer le composant React pour le formulaire de paiement.
- Gérer la validation des données du formulaire (côté front et back).
- Créer la page de confirmation de commande.
- Écrire les tests d'intégration pour le flux de paiement.
- ...
Cet ensemble (Sprint Goal + User Stories sélectionnées + Tâches techniques) constitue le Sprint Backlog. C'est le plan de jeu de l'équipe pour le sprint.
Voici une visualisation des éléments qui composent un Sprint Backlog bien structuré.
Conclusion
Vous savez désormais comment passer d'un backlog priorisé à un plan de sprint réalisable. Le Sprint Planning est le moteur qui lance chaque cycle de développement, en garantissant que l'équipe est alignée, engagée et dispose d'un plan clair.
Points clés à retenir :
- Le Sprint Planning est un événement collaboratif qui répond à trois questions : Pourquoi (le Sprint Goal), Quoi (les user stories sélectionnées) et Comment (les tâches techniques).
- L'équipe de développement est souveraine sur la quantité de travail qu'elle s'engage à réaliser. Elle "tire" le travail, il ne lui est pas "poussé".
- Le résultat est le Sprint Backlog : un objectif, une sélection d'items du Product Backlog, et un plan pour les transformer en un incrément de produit fonctionnel.
- La décomposition en tâches techniques est une étape cruciale qui transforme une exigence fonctionnelle en un plan de développement concret.
Le sprint est maintenant planifié, le travail peut commencer ! Dans la prochaine leçon, nous verrons comment suivre l'avancement de ce plan et communiquer efficacement sur le progrès de l'équipe en apprenant à rédiger un rapport d'avancement de sprint.