Les Scrum Events sont la colonne vertébrale de Scrum. Ce guide est conçu pour devenir la meilleure ressource francophone sur les cinq événements définis par le Scrum Guide 2020 et pour vous préparer aux questions PSM I qui s'y rapportent.
Que sont les Scrum Events ?
Selon le Scrum Guide 2020, les Scrum Events sont des événements formels conçus pour créer la régularité et minimiser le besoin de réunions non définies dans Scrum. Tous les événements sont des opportunités formelles d'inspecter et d'adapter les artefacts Scrum.
Le Scrum Guide en définit cinq, dont quatre se déroulent à l'intérieur d'un cinquième : le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective se déroulent à l'intérieur d'un Sprint.
Le Sprint contient les quatre autres événements.
Pourquoi des événements formels ?
Sans Scrum Events, l'équipe risque de multiplier des réunions ad hoc, perdre le rythme et glisser vers un fonctionnement cascade. Les événements existent pour :
- Créer une régularité : un rythme prévisible facilite la concentration.
- Réduire les autres réunions : chaque événement absorbe les besoins de synchronisation.
- Matérialiser l'empirisme : sans inspection régulière, il n'y a pas d'adaptation.
- Protéger le Sprint Goal : chaque événement reconnecte le travail au Goal.
Lien avec l'empirisme
Scrum repose sur l'empirisme : la connaissance vient de l'expérience et les décisions se prennent à partir de ce qui est observé. L'empirisme repose sur trois piliers : transparence, inspection, adaptation. Les Scrum Events sont les moments prescrits où ces trois piliers s'exercent simultanément.
Les Scrum Events matérialisent ces trois piliers à intervalles réguliers.
Transparence
Pour qu'une inspection soit utile, ce qui est inspecté doit être transparent : le Product Backlog, le Sprint Backlog, l'Increment et la Definition of Done doivent refléter fidèlement la réalité. Les événements créent l'espace pour rendre cela visible.
Inspection
Chaque événement inspecte un artefact face à son engagement : Product Backlog face au Product Goal (Sprint Planning / Review), Sprint Backlog face au Sprint Goal (Daily Scrum), Increment face à la Definition of Done (Sprint Review).
Adaptation
Si l'inspection révèle un écart, la Scrum Team adapte sans tarder : réordonner le Product Backlog, replanifier le Sprint Backlog, ajuster la Definition of Done, modifier la manière de travailler.
Les 5 Scrum Events
Le Scrum Guide 2020 définit cinq événements. Le Sprint englobe les quatre autres et crée le rythme de l'équipe.
| Événement | Objectif | Time-box (Sprint d'1 mois) |
|---|---|---|
| Sprint | Conteneur de tous les autres événements ; produit au moins un Increment. | ≤ 1 mois |
| Sprint Planning | Définir le Sprint Goal, sélectionner les PBI, élaborer le plan. | ≤ 8 h |
| Daily Scrum | Inspecter la progression vers le Sprint Goal et replanifier le travail. | 15 min / jour |
| Sprint Review | Inspecter l'Increment avec les stakeholders et adapter le Product Backlog. | ≤ 4 h |
| Sprint Retrospective | Inspecter la Scrum Team et planifier des améliorations. | ≤ 3 h |
Le Sprint démarre par le Planning, rythme avec les Dailies, se clôt par Review + Retrospective.
1. Le Sprint
Le Sprint est le cœur de Scrum. C'est une période d'un mois maximum (souvent 1, 2 ou 3 semaines), de longueur fixe, pendant laquelle un Increment de valeur, utilisable et conforme à la Definition of Done, est créé.
- Objectif : créer au moins un Increment de valeur.
- Participants : la Scrum Team entière.
- Time-box : 1 mois maximum, durée constante.
- Entrée : Product Backlog ordonné, Product Goal.
- Sortie : un ou plusieurs Increments « Done ».
2. Sprint Planning
Le Sprint Planning initie le Sprint en répondant à trois questions :
- Pourquoi ce Sprint a-t-il de la valeur ? → Sprint Goal.
- Quoi peut être terminé pendant ce Sprint ? → PBI sélectionnés.
- Comment le travail va-t-il être fait ? → Plan initial.
Time-box : ≤ 8 h pour un Sprint d'un mois, proportionnel pour des Sprints plus courts. Participants : Scrum Team entière, et éventuellement des invités si la Scrum Team le souhaite.
3. Daily Scrum
Le Daily Scrum est un événement de 15 minutes pour les Developers, chaque jour ouvré, au même endroit et à la même heure. Son objectif : inspecter la progression vers le Sprint Goal et adapter le Sprint Backlog.
4. Sprint Review
La Sprint Review a lieu à la fin du Sprint pour inspecter l'Increment et adapter le Product Backlog. Stakeholders et Scrum Team y collaborent.
- Objectif : inspecter le résultat du Sprint, ajuster le Product Backlog.
- Participants : Scrum Team + stakeholders invités par le PO.
- Time-box : ≤ 4 h pour un Sprint d'un mois.
- Sortie : Product Backlog ajusté ; pas de signature ni « validation officielle ».
5. Sprint Retrospective
La Sprint Retrospective clôt le Sprint. Elle vise à augmenter la qualité et l'efficacité de la Scrum Team.
- Objectif : inspecter le dernier Sprint (interactions, process, outils, DoD) et planifier des améliorations.
- Participants : Scrum Team uniquement.
- Time-box : ≤ 3 h pour un Sprint d'un mois.
- Sortie : améliorations concrètes appliquées dès le prochain Sprint.
Chaque événement nourrit le suivant — aucun n'est facultatif.
Pourquoi chaque événement est time-boxé
La time-box est un engagement de durée maximale. Elle protège l'équipe contre la dérive (« il faut encore 30 minutes »), force à se concentrer sur l'essentiel et préserve l'énergie pour le travail productif.
| Événement | Sprint d'1 mois | Sprint de 2 semaines | Sprint d'1 semaine |
|---|---|---|---|
| Sprint Planning | ≤ 8 h | ≤ 4 h | ≤ 2 h |
| Daily Scrum | 15 min | 15 min | 15 min |
| Sprint Review | ≤ 4 h | ≤ 2 h | ≤ 1 h |
| Sprint Retrospective | ≤ 3 h | ≤ 1 h 30 | ≤ 45 min |
Participants par événement
| Événement | Participants requis | Invités possibles |
|---|---|---|
| Sprint | Scrum Team entière | — |
| Sprint Planning | Scrum Team entière | Experts métier / techniques sur invitation |
| Daily Scrum | Developers | PO et SM s'ils sont aussi Developers actifs |
| Sprint Review | Scrum Team | Stakeholders invités par le PO |
| Sprint Retrospective | Scrum Team | Aucun par défaut (équipe seule) |
Livrables par événement
| Événement | Entrée principale | Sortie principale |
|---|---|---|
| Sprint | Product Backlog ordonné, Product Goal | Un ou plusieurs Increments Done |
| Sprint Planning | Product Backlog, vélocité, Definition of Done | Sprint Backlog (Goal + PBI + plan) |
| Daily Scrum | Sprint Backlog, Sprint Goal | Plan ajusté pour les 24 h suivantes |
| Sprint Review | Increment, Product Backlog, retours stakeholders | Product Backlog ajusté |
| Sprint Retrospective | Observations du Sprint | Améliorations concrètes pour le Sprint suivant |
Conséquences quand un événement est mal réalisé
| Événement | Erreur classique | Conséquence |
|---|---|---|
| Sprint Planning | Pas de Sprint Goal défini | Sprint sans cap, Daily Scrum vide de sens |
| Daily Scrum | Transformé en reporting au manager | Les Developers perdent l'ownership |
| Sprint Review | Démo unilatérale sans dialogue | Pas d'adaptation du Product Backlog |
| Sprint Retrospective | Recherche de coupables | Sécurité psychologique détruite, pas d'amélioration |
| Sprint | Extension ou raccourcissement opportuniste | Empirisme rompu, perte du rythme |
Approfondissement des 5 événements
Chaque événement Scrum mérite une fiche détaillée. Vous trouverez ci-dessous, pour les cinq événements, une synthèse structurée (objectif, participants, time-box, livrables, erreurs fréquentes, conseils PSM I) directement exploitable à l'examen et sur le terrain.
Sprint — le conteneur
- Objectif : produire au moins un Increment de valeur, conforme à la Definition of Done, en lien avec le Product Goal.
- Participants : Scrum Team entière.
- Time-box : 1 mois maximum, durée fixe d'un Sprint à l'autre.
- Livrables : un ou plusieurs Increments « Done ».
- Erreurs fréquentes : étendre le Sprint pour finir un PBI, modifier le Sprint Goal en cours de Sprint, accepter des changements qui mettent en péril le Sprint Goal.
- Conseil PSM I : seul le Product Owner peut annuler un Sprint, uniquement si le Sprint Goal devient obsolète.
Sprint Planning — démarrer avec un cap
- Objectif : définir un Sprint Goal, sélectionner les PBI, élaborer un plan initial.
- Participants : Scrum Team entière (+ experts invités si utile).
- Time-box : ≤ 8 h pour un Sprint d'un mois.
- Livrables : le Sprint Backlog (Sprint Goal + PBI + plan initial).
- Erreurs fréquentes : ne pas formuler explicitement le Sprint Goal, sélectionner des PBI sans rapport entre eux, planifier en mode cascade.
- Conseil PSM I : ce sont les Developers qui décident quels PBI entrent dans le Sprint Backlog, en collaboration avec le PO.
Daily Scrum — replanifier vers le Sprint Goal
- Objectif : inspecter la progression vers le Sprint Goal, adapter le Sprint Backlog.
- Participants : Developers. PO et SM optionnels (sauf s'ils sont Developers actifs).
- Time-box : 15 minutes, chaque jour ouvré, même heure / même lieu.
- Livrables : un plan ajusté pour les 24 h suivantes.
- Erreurs fréquentes : transformer le Daily en reporting au SM, au PO ou à un manager ; faire un tour de table « hier / aujourd'hui / blocages » sans lien avec le Sprint Goal ; dépasser 15 minutes pour résoudre un sujet technique.
- Conseil PSM I : le format des trois questions n'est plus imposé depuis le Scrum Guide 2020.
Sprint Review — inspecter le produit avec les stakeholders
- Objectif : inspecter l'Increment, recueillir les retours, adapter le Product Backlog.
- Participants : Scrum Team + stakeholders invités par le PO.
- Time-box : ≤ 4 h pour un Sprint d'un mois.
- Livrables : un Product Backlog mis à jour (pas une « validation » de l'Increment).
- Erreurs fréquentes : démo unidirectionnelle, sans dialogue ; absence de stakeholders ; signature formelle de l'Increment.
- Conseil PSM I : la Sprint Review est une session de travail, pas une démo.
Sprint Retrospective — améliorer l'équipe
- Objectif : inspecter la Scrum Team (interactions, process, outils, DoD) et planifier des améliorations concrètes.
- Participants : Scrum Team uniquement.
- Time-box : ≤ 3 h pour un Sprint d'un mois.
- Livrables : améliorations à appliquer dès le prochain Sprint (souvent ajoutées au Sprint Backlog du Sprint suivant).
- Erreurs fréquentes : recherche de coupables, format figé qui démotive, actions trop nombreuses ou jamais suivies.
- Conseil PSM I : la Retrospective conclut le Sprint et précède immédiatement le Sprint Planning suivant.
Exigences du Scrum Guide 2020
- Les Scrum Events sont au nombre de cinq.
- Le Sprint est un conteneur des quatre autres événements.
- Chaque événement est une opportunité formelle d'inspecter et adapter.
- Chaque événement a une time-box maximale.
- Ne pas tenir un événement = perdre une opportunité d'inspection et d'adaptation.
- Le Sprint démarre immédiatement après la fin du Sprint précédent.
Scrum Events vs cérémonies SAFe / Kanban
Beaucoup d'organisations mélangent Scrum, SAFe et Kanban. Les candidats PSM I doivent retenir que seul le Scrum Guide 2020 fait foi pour l'examen.
| Concept | Scrum (Guide 2020) | SAFe | Kanban |
|---|---|---|---|
| Cycle principal | Sprint ≤ 1 mois | PI de 8 à 12 semaines | Flux continu |
| Événement de planification | Sprint Planning (≤ 8 h) | PI Planning (2 jours) | Replenishment meeting |
| Synchronisation quotidienne | Daily Scrum (15 min) | Daily Stand-up + Scrum of Scrums | Daily Kanban (optionnel) |
| Revue | Sprint Review (≤ 4 h) | System Demo + PI Demo | Service delivery review |
| Amélioration | Sprint Retrospective (≤ 3 h) | Inspect & Adapt workshop | Operations review |
Scrum Events en équipe distribuée
Les Scrum Events restent identiques en distanciel, mais quelques adaptations pratiques aident à préserver leur efficacité :
- Sprint Planning : prévoir des pauses tous les 60–90 minutes, partager le board en temps réel, désigner un facilitateur de l'écran.
- Daily Scrum : caméra ouverte par défaut, tour de parole rapide, board affiché, pas de chat parallèle.
- Sprint Review : tester la démo à blanc 30 min avant, inviter les stakeholders avec un agenda clair, prévoir un canal pour les questions écrites.
- Sprint Retrospective : utiliser un board collaboratif (Miro, Mural, FunRetro) ; protéger la sécurité psychologique en limitant les participants à la Scrum Team.
- Sprint : aligner les fuseaux horaires (1 à 4 h de chevauchement minimum) et documenter les décisions clés dans un canal asynchrone.
Exemple complet — application bancaire
Pour illustrer l'enchaînement des cinq Scrum Events, prenons une Scrum Team développant une nouvelle application bancaire mobile en Sprints de deux semaines.
| Événement | Ce qui se passe concrètement |
|---|---|
| Sprint Planning (3 h, lundi matin) | Sprint Goal : « Permettre à un client de virer de l'argent à un IBAN existant. » Sept PBI sélectionnés, plan initial co-construit. |
| Daily Scrum × 10 (15 min / jour) | Les Developers inspectent la progression vers le Goal et replanifient. Jour 5 : un risque sécurité est identifié → un PBI est ajouté au Sprint Backlog par les Developers. |
| Sprint Review (2 h, vendredi S2) | Démonstration du virement de bout en bout. Cinq stakeholders donnent leur feedback. Le PO ajuste l'ordre du Product Backlog : la gestion des bénéficiaires favoris monte en priorité. |
| Sprint Retrospective (1 h 30, vendredi S2) | L'équipe identifie deux améliorations : 1) ajouter un step de revue de sécurité dans la Definition of Done, 2) découper les PBI critiques en plus petites tranches. Ces deux actions sont ajoutées au Sprint Backlog du Sprint 8. |
| Sprint 8 démarre immédiatement (lundi) | Le Sprint Planning du Sprint 8 reprend les apprentissages de la Review et de la Retrospective. |
20 anti-patterns à connaître
Voici les anti-patterns les plus fréquents observés sur les Scrum Events. Chacun pèse directement sur l'empirisme, la valeur livrée et la motivation de la Scrum Team.
- Daily Scrum reporting — les Developers « rendent des comptes » au SM ou à un manager.
- Sprint sans Sprint Goal — une liste de PBI hétéroclites, aucune direction commune.
- Sprint Planning en mode cascade — découpage et estimation détaillée de chaque tâche pour tout le Sprint.
- Review = démo descendante — l'équipe « présente », les stakeholders « regardent », pas d'adaptation.
- Retrospective chasse aux coupables — la sécurité psychologique s'effondre, les vrais problèmes disparaissent.
- Time-box étendue — « on prolonge de 30 minutes parce qu'il reste des sujets ».
- Sprint étendu pour finir un PBI — la longueur fixe est brisée, le rythme empirique aussi.
- Sprint raccourci « parce qu'on a fini » — même effet : le rythme prévisible est perdu.
- Refinement transformé en Sprint Planning bis — l'équipe planifie le futur trop en détail.
- Daily mené par le Scrum Master — les Developers perdent leur ownership.
- Sprint Goal absent ou flou — impossible de mesurer l'inspection au Daily.
- Stakeholders absents de la Review — pas d'inspection externe, pas d'adaptation.
- Validation officielle de l'Increment en Review — la Review n'est pas un comité d'acceptation.
- Retrospective sans actions concrètes — « on a parlé », rien n'est appliqué au Sprint suivant.
- Trop d'actions de Retrospective — l'équipe en sélectionne 10, n'en réalise aucune.
- Sprints consécutifs sans Retrospective — apprentissage cumulé perdu.
- Fusion Review + Retrospective — produit et process inspectés en même temps : aucun n'est traité correctement.
- Manager qui modifie le Sprint Backlog — seule la Scrum Team décide du contenu du Sprint Backlog.
- Daily « stand-up » devenu rituel social — bavardages, blagues, blocages oubliés ; le Sprint Goal n'est plus inspecté.
- Sprint Planning sans Definition of Done — impossible de savoir ce que « Done » veut dire pour le Sprint.
Erreurs fréquentes
| Symptôme | Pourquoi c'est faux | Que faire |
|---|---|---|
| « On saute la Retrospective ce Sprint, on n'a pas le temps. » | La Retrospective est obligatoire ; sans elle, pas d'amélioration continue. | Réduire le scope, jamais l'événement. |
| « Le Daily passe à 30 minutes parce qu'il y a beaucoup à dire. » | La time-box est un maximum strict. | Identifier les sujets longs et les sortir hors Daily. |
| « Le PO refuse d'inviter les stakeholders à la Review. » | Sans stakeholders, pas d'inspection externe ni d'adaptation valable. | Inviter activement les bonnes parties prenantes. |
| « Le manager anime le Daily. » | Le Daily Scrum est pour les Developers. | Réaffirmer l'ownership des Developers. |
| « Le Sprint est étendu de 3 jours pour finir un PBI. » | Un Sprint a une longueur fixe. | Terminer à la date prévue, replanifier le PBI manquant au Sprint suivant. |
15 questions PSM I
Préparer le PSM I sur les Scrum Events
Les questions PSM I sur les Scrum Events se répartissent en quatre familles principales. Travaillez chaque famille avec une grille de révision dédiée.
| Famille | Exemples de questions | Comment se préparer |
|---|---|---|
| Time-boxes | Durée max d'un événement, proportionnalité aux Sprints courts | Mémoriser le tableau des time-boxes ; refaire des QCM chronométrés. |
| Participants | Qui est requis, qui est invité, qui anime | Apprendre par cœur le tableau participants pour chaque événement. |
| Objectif / livrables | Quel artefact est inspecté, quel est le livrable | Réviser les liens Sprint Planning → Sprint Backlog, Review → Product Backlog, Retrospective → améliorations. |
| Pièges contextuels | Daily transformé en reporting, Review sans stakeholders, Retrospective sautée | Travailler 50 à 100 questions PSM I en conditions réelles. |
FAQ — questions fréquentes
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus posées sur les Scrum Events.
Références
- Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland, novembre 2020.
- Scrum.org — documentation officielle, parcours PSM I.
- Ken Schwaber, co-auteur du Scrum Guide.
- Jeff Sutherland, co-auteur du Scrum Guide.
À lire aussi
Source officielle : Scrum Guide 2020.