Les 5 événements Scrum : Timebox = pouvoir

Découvrez les 5 événements Scrum : Sprint, Planning, Daily, Review et Rétrospective. Comprenez leur rôle pour améliorer vos projets.

Beaucoup échouent au PSM pour une raison simple :
ils comprennent Scrum… mais pas ses règles implicites.

Les événements Scrum ne sont pas des réunions.
Ce sont des pièges d’examen.

Et si tu ne comprends pas exactement leur rôle,
tu peux rater le PSM… même en connaissant le framework.

👉 Scrum.org ne teste pas ta mémoire.
👉 Il teste ta capacité à détecter ce qui est faux

1. Le Sprint : le rythme de base

👉 Le Sprint protège l’équipe du chaos.

Le Sprint est un événement à part entière : un cycle de travail de durée fixe (au plus un mois) qui contient tous les autres événements Scrum. Pendant ce laps de temps, l’équipe se concentre sur un objectif unique, le Sprint Goal, et respecte trois règles : l’objectif ne change pas, le niveau de qualité n’est jamais revu à la baisse, et le contenu du plan peut évoluer si l’objectif reste atteignable.

Pour PSM : toute proposition qui parle de prolonger un Sprint, de le mettre en pause ou de redéfinir le Sprint Goal en cours de route est contraire au Scrum Guide, donc à écarter.​​

👉 Le Sprint est intouchable.

  • ❌ on ne le prolonge jamais

  • ❌ on ne le met jamais en pause

  • ❌ on ne change pas le Sprint Goal

👉 Si tu vois ça dans une réponse → c’est faux.

2. Sprint Planning : donner une direction claire

👉 Si quelqu’un “écoute” ton Daily pour suivre l’avancement, tu n’es déjà plus dans Scrum.

Objectif : lancer le Sprint en répondant à trois questions :

  1. Pourquoi ce Sprint est‑il utile ? → définition du Sprint Goal.

  2. Que pouvons‑nous faire pendant ce Sprint ? → sélection d’items du Product Backlog.

  3. Comment allons‑nous les réaliser ? → plan de travail dans le Sprint Backlog.

La séance est timeboxée à 8 heures pour un Sprint d’un mois (moins si le Sprint est plus court) et implique toute la Scrum Team. Le Product Owner apporte la vision et les priorités, les Developers évaluent la capacité et construisent le plan, le Scrum Master facilite.​

Erreur d’examen fréquente : un Product Owner qui “impose” le plan ou un Sprint Backlog déclaré figé après le Planning. En Scrum, seul l’objectif reste stable ; le plan lui, peut et doit s’ajuster.​

👉 Le piège classique :

  • PO qui impose le plan → ❌

  • Sprint Backlog figé → ❌

👉 En Scrum :

  • objectif stable

  • plan adaptable

3. Daily Scrum : 15 minutes pour se recaler

👉 Si quelqu’un “écoute” ton Daily pour suivre l’avancement, tu n’es déjà plus dans Scrum.

Le Daily Scrum est une courte réunion quotidienne (15 minutes maximum) réservée aux Developers. Son but n’est pas de “rendre compte” mais d’inspecter la progression vers le Sprint Goal et d’ajuster le plan pour les 24 prochaines heures.

Le format est libre : l’équipe peut garder le traditionnel “hier / aujourd’hui / obstacles” ou choisir toute autre structure, tant qu’elle sert cet objectif. Les problèmes complexes sont traités après, avec les personnes concernées, pour ne pas diluer le Daily.​

Piège PSM classique : présenter le Daily comme un reporting au Scrum Master ou au manager, ou imposer un format unique comme “obligatoire”. Scrum ne fixe pas de script ; seul le but compte.​​​

👉 Si ça ressemble à un reporting → c’est faux.

  • ❌ pour le Scrum Master

  • ❌ pour le manager

  • ❌ pour “faire le point”

👉 C’est pour ajuster le plan vers le Sprint Goal.

4. Sprint Review : décider de la suite avec les parties prenantes

👉 La Review n’est pas une validation. C’est un moment de décision produit.

La Sprint Review a lieu en fin de Sprint, pour inspecter l’Incrément avec les parties prenantes et adapter le Product Backlog en conséquence. Timebox : 4 heures au maximum pour un Sprint d’un mois.​

On y passe en revue :

  • ce qui a été livré (Done),

  • ce qui n’a pas été terminé et pourquoi,

  • les retours utilisateurs, les évolutions du marché, les nouvelles contraintes,

  • et enfin : ce qu’il est pertinent de faire ensuite pour se rapprocher du Product Goal.

Erreur fréquente : réduire la Review à une simple “recette” de validation go/no go, ou la supprimer quand “on n’a rien à montrer”. Même sans Incrément, la Review reste indispensable pour inspecter la situation et ajuster le plan.

👉 Si tu vois “validation”, “recette”, “go/no go” → ❌

👉 La Review sert à :

  • inspecter

  • adapter

  • décider de la suite

5. Sprint Retrospective : améliorer la façon de travailler

La Sprint Retrospective clôture le Sprint. Son objectif est de trouver des moyens concrets d’améliorer la qualité et l’efficacité de la Scrum Team. Timebox : 3 heures pour un Sprint d’un mois.​

La Scrum Team y examine :

  • ses interactions,

  • ses processus et outils,

  • la Definition of Done,

  • ce qui a aidé ou freiné l’atteinte du Sprint Goal.​

L’enjeu n’est pas de refaire l’histoire, mais d’identifier un petit nombre d’actions réalistes à tester dès le Sprint suivant.

Côté PSM, les erreurs courantes sont de présenter la Retro comme facultative, de la fusionner avec la Review, ou d’en faire un simple défouloir sans plan d’action.​

👉 Une rétro sans actions = inutile.

Et :

👉 Si elle est optionnelle → réponse fausse.

6. Pourquoi ces timeboxes sont non négociables

Les timeboxes sont l’un des pièges les plus sous-estimés du PSM.

Beaucoup pensent que c’est une recommandation. Ce n’est pas le cas.

👉 Les 5 événements ne sont pas des réunions. Ce sont les mécanismes qui permettent à Scrum de fonctionner.

Si tu les comprends mal :

  • tu appliques mal Scrum

  • tu échoues au PSM

👉 Les timeboxes ne sont pas négociables.

  • Sprint → max 1 mois

  • Planning → max 8h

  • Daily → 15 min

  • Review → max 4h

  • Retro → max 3h

👉 Si une réponse propose de dépasser → ❌

7. Transformer cette compréhension en points PSM

👉 Le problème au PSM n’est pas de connaître Scrum.


C’est de tomber dans les pièges.

Et ces pièges sont toujours les mêmes :

  • Daily = reporting

  • Review = validation

  • Scrum Master = chef de projet

  • Sprint adaptable

Si tu ne les identifies pas instantanément, tu perds des points.

C’est exactement ce que tu travailles dans mes guides PSM I et PSM II :

  • questions types examen

  • pièges détaillés

  • logique Scrum.org

Objectif : éviter les erreurs qui font échouer… parfois à 1 ou 2 questions près.

👉 Accès direct sur le site et sur Amazon.