Avant · préparer la décision
Le Product Owner explique le besoin prioritaire. Les Developers partagent les absences, les contraintes connues et les enseignements des derniers Sprints. Les incertitudes importantes sont discutées.
← Tous les modulesMODULE 02 / 05
02 — LES ÉVÉNEMENTS
Chaque rendez-vous doit faire avancer.
Préparer, animer et conclure les événements Scrum avec un objectif clair. Apprenez aussi à reconnaître un rendez-vous devenu mécanique.
45 MIN · lecture et activités indicatives- Expliquer ce que chaque événement permet d’inspecter.
- Préparer un Planning, un Daily, une Review et une Rétrospective.
- Séparer cadre Scrum et formats d’animation.
Notre fil rouge : VéloCity. Ses exemples illustrent les notions tout au long du module.
1. Le Sprint contient toute la boucle
Le Sprint dure au maximum un mois. Il inclut la planification, la réalisation, les échanges quotidiens, la Review et la Rétrospective. Le suivant commence à la suite : les tests et l’intégration font partie du travail, ils ne sont pas repoussés dans un « Sprint de finition ».
Au début du Sprint
Pourquoi ce Sprint a-t-il de la valeur ?
- Qui ?
- Toute la Scrum Team
- Résultat
- Un Objectif de Sprint, une sélection de travail et un plan.
- Durée
- 8 h maximum pour un Sprint d’un mois
Réalisation, tests, intégration et incréments utilisables tout au long du Sprint
Le Daily est récurrent. L’Incrément est un artefact, pas un événement. Le Sprint suivant prolonge cette boucle.
Pour aller plus loin · facultatif
Peut-on changer le contenu du Sprint ?
Les Developers et le Product Owner peuvent clarifier et renégocier le périmètre à mesure qu’ils apprennent, tout en protégeant l’Objectif de Sprint et la qualité. Si l’objectif devient obsolète, seul le Product Owner peut annuler le Sprint.
2. Sprint Planning : un pourquoi, un quoi, un comment
Arrivez avec des priorités compréhensibles et une idée réaliste de la disponibilité. Le résultat recherché est un objectif cohérent accompagné d’un plan, pas une liste de tickets remplie jusqu’à saturation.
Pendant · construire une prévision
Formulez ensemble le bénéfice attendu. Les Developers choisissent les éléments qu’ils pensent pouvoir terminer et définissent comment s’y prendre. Prévoyez l’intégration et les vérifications dès le départ.
À la sortie · reformuler
Demandez : « Si nous ne pouvions expliquer ce Sprint qu’en une phrase, laquelle serait-ce ? » Puis vérifiez que les éléments sélectionnés servent cette phrase.
3. Daily Scrum : adapter le plan du jour
Ce rendez-vous de quinze minutes est destiné aux Developers. Son format est libre tant qu’il aide à progresser vers l’objectif. Les trois questions « hier, aujourd’hui, blocages » sont une option, pas une obligation.
Commencer par l’objectif
Examiner la progression vers l’Objectif de Sprint et les changements depuis la veille.
Regarder le travail qui vieillit
Identifier les éléments en attente et les obstacles. Chercher où l’entraide permettrait de terminer du travail.
Finir sur des décisions
Adapter le Sprint Backlog avec un plan concret pour la prochaine journée. Poursuivre les discussions détaillées après le Daily avec les personnes concernées.
4. Sprint Review : décider avec le retour terrain
La Scrum Team et les parties prenantes examinent les résultats et les changements de contexte pour déterminer la suite. Une démonstration aide la discussion ; elle ne la remplace pas.
Inspecter le produit et son contexte
Examiner le résultat du Sprint, la progression vers l’Objectif Produit et les changements susceptibles d’influencer la suite.
Travailler avec les parties prenantes
Échanger sur les résultats, les besoins et les opportunités. La Review est une séance de travail, pas seulement une présentation.
Adapter les prochaines priorités
Déterminer ensemble des adaptations utiles. Le Product Backlog peut être ajusté pour tenir compte de ce qui a été appris.
5. Rétrospective : une amélioration testable
La Scrum Team inspecte sa façon de travailler : interactions, outils, pratiques et qualité. Un bon résultat peut être une seule expérience petite et suivie.
Créer un espace de parole
Permettre à toute la Scrum Team de discuter des interactions, des processus, des outils et de la qualité sans chercher un coupable.
Comprendre un mécanisme
Examiner ce qui a bien fonctionné, les difficultés et leurs causes possibles. Distinguer une observation d’une interprétation.
Définir une amélioration utile
Choisir les changements qui peuvent le mieux améliorer l’efficacité. Les améliorations les plus utiles sont abordées dès que possible et peuvent rejoindre le prochain Sprint Backlog.
Pour aller plus loin · facultatif
Timeboxes : que dit le cadre ?
Pour un Sprint d’un mois, les maxima sont de 8 h pour le Planning, 4 h pour la Review et 3 h pour la Rétrospective. Les événements sont habituellement plus courts pour un Sprint plus court, sans formule de proportion obligatoire. Le Daily reste limité à 15 minutes.
Le refinement est-il un cinquième rendez-vous ?
L’affinage du Product Backlog est une activité continue. L’équipe peut réserver des créneaux de travail, mais Scrum n’impose ni réunion spécifique ni durée fixe pour cette activité.
À vous de jouer.
Prenez un temps pour appliquer les notions, puis consultez les explications.
À VOUS DE JOUER · 5–8 MIN
Les notions à l’épreuve du terrain.
DÉCISION 1
Le Daily ressemble à un compte rendu individuel. Quel changement essayer ?
DÉCISION 2
Quelle est la durée maximale d’un Sprint ?
Votre texte reste dans cette page. Il n’est ni envoyé ni évalué automatiquement.
Trois repères pour agir.
- Chaque événement relie observation et adaptation.
- Les durées proposées dans les ateliers sont des exemples.
- La Review porte sur le produit et la suite ; la Rétrospective sur l’efficacité de l’équipe.
Pour vérifier le cadre : Scrum Guide, Ken Schwaber & Jeff Sutherland, novembre 2020 ↗. Les exemples VéloCity et les déroulés d’atelier sont des propositions pédagogiques de ce guide.