Cérémonies scrum : guide complet des 5 événements

Équipe illustrée de développeurs rassemblés autour d'un tableau scrum avec des post-it, progressant à travers différents formats de réunion dans un espace de travail agile coloré Scrum définit exactement cinq événements. Pas quatre, pas six. Chacun existe pour une raison précise, et en sauter un seul laisse un vide dans la boucle de feedback qui fait fonctionner scrum. Voici à quoi sert chaque événement, qui y participe, combien de temps il dure, et les erreurs qui déraillent silencieusement les équipes.

Le sprint

Le sprint est le conteneur de tout le reste. Chaque autre événement scrum se déroule à l'intérieur d'un sprint. C'est un timebox fixe, généralement d'une à quatre semaines, pendant lequel l'équipe construit un incrément potentiellement livrable du produit. Points clés :

Durée : 1 à 4 semaines (2 semaines est le plus courant)
Qui participe : L'équipe scrum entière
Résultat : Un incrément terminé

Les sprints ne sont pas prolongés. Si l'équipe ne peut pas tout terminer, les éléments retournent dans le backlog. Cette contrainte est le but. Elle force les conversations difficiles sur le périmètre et les priorités tôt, au lieu de laisser les échéances glisser silencieusement. Les sprints plus courts (une ou deux semaines) réduisent le risque car vous obtenez du feedback plus rapidement. Les sprints plus longs laissent plus de place pour le travail complexe. La plupart des équipes se fixent sur deux semaines et n'y reviennent jamais.

Quand raccourcir votre sprint

Si votre équipe reporte systématiquement du travail non terminé au sprint suivant, essayez des sprints plus courts. Il est plus facile de planifier avec précision pour une semaine que pour quatre, et vous détecterez les problèmes de périmètre plus tôt.

Sprint planning

Le sprint planning lance chaque sprint. L'équipe décide quoi construire et comment le construire. Points clés :

Timebox : Jusqu'à 8 heures pour un sprint de 4 semaines (proportionnellement moins, soit environ 2 heures pour un sprint de 2 semaines)
Qui participe : Product Owner, Scrum Master, équipe de développement
Résultat : L'objectif du sprint et le sprint backlog

La réunion se divise en deux parties. D'abord, le Product Owner présente les éléments du backlog les plus prioritaires et l'équipe discute de ce qui est réalisable. Ensuite, les développeurs décomposent ces éléments en tâches et définissent l'approche. L'objectif du sprint compte plus que les éléments individuels. Il donne à l'équipe une direction et la flexibilité de négocier le périmètre si des surprises surviennent en cours de sprint.

Comment le planning poker s'intègre

De nombreuses équipes utilisent le planning poker pendant ou avant le sprint planning pour estimer les éléments du backlog. Chaque membre de l'équipe estime indépendamment les story points, puis le groupe discute des écarts importants. Cela met en lumière les hypothèses et les malentendus avant le début du travail. Apprenez-en plus sur le fonctionnement du planning poker et les échelles de story points utilisées par les équipes.

Erreur courante

Ne laissez pas le sprint planning devenir une session de grooming du backlog. Les éléments devraient déjà être affinés et estimés avant d'entrer en planification. Si la moitié de la réunion est consacrée à clarifier les exigences, votre processus de refinement a besoin d'être revu.

Daily scrum

Le daily scrum (ou daily standup) est une synchronisation de 15 minutes pour l'équipe de développement. Ce n'est pas un rapport d'avancement pour la direction. Points clés :

Timebox : 15 minutes, même heure et même lieu chaque jour
Qui participe : Équipe de développement (le Scrum Master facilite si nécessaire, le Product Owner est optionnel)
Résultat : Compréhension partagée de l'avancement et des blocages

Le format classique repose sur trois questions : Qu'ai-je fait hier ? Que vais-je faire aujourd'hui ? Qu'est-ce qui me bloque ? Mais ce format peut devenir lassant. Certaines équipes parcourent le tableau à la place, en se concentrant sur les tickets plutôt que sur les personnes. D'autres utilisent des formats asynchrones pour les équipes distribuées. Le daily scrum existe pour aider les développeurs à se coordonner. Si quelqu'un est bloqué, l'équipe trouve une solution ensemble. Si deux personnes s'apprêtent à travailler sur des modifications conflictuelles, elles le détectent ici plutôt que dans un conflit de merge.

L'alternative du standup asynchrone

Pour les équipes distribuées et à distance, les standups asynchrones remplacent la réunion matinale traditionnelle. Les membres de l'équipe publient leurs mises à jour à leur propre rythme, et toute l'équipe reste informée sans se battre avec les décalages horaires. Si vous passez à l'asynchrone, écrire des mises à jour que les gens lisent vraiment est une compétence qui vaut la peine d'être développée. Découvrez comment écrire des mises à jour de standup qui sont réellement lues.

Illustration en écran partagé montrant un cercle de standup traditionnel d'un côté et des membres de l'équipe publiant des mises à jour asynchrones depuis différents endroits de l'autre, reliés par des lignes fluides

Sprint review

La sprint review a lieu à la fin du sprint. L'équipe démontre ce qu'elle a construit aux parties prenantes et recueille du feedback. Points clés :

Timebox : Jusqu'à 4 heures pour un sprint de 4 semaines (environ 1 à 2 heures pour un sprint de 2 semaines)
Qui participe : Équipe scrum + parties prenantes (utilisateurs, direction, autres équipes)
Résultat : Retours sur l'incrément, backlog produit mis à jour

Ce n'est pas une présentation formelle. C'est une session de travail où les parties prenantes utilisent le produit réel, posent des questions et disent ce qu'elles pensent devoir changer. Le Product Owner utilise ces retours pour ajuster le backlog. Les équipes qui sautent ou bâclent les sprint reviews ont tendance à s'éloigner de ce dont les utilisateurs ont réellement besoin. On ne peut planifier en vase clos que pendant un temps limité avant de construire la mauvaise chose.

Sprint review vs. sprint demo

Les gens utilisent ces termes de manière interchangeable, mais le Scrum Guide décrit une session de travail collaborative, pas une démo à sens unique. La différence compte. Une démo est passive. Une review est interactive. Les parties prenantes devraient repartir avec des opinions, et l'équipe devrait repartir avec des informations sur lesquelles agir.

Qui devrait être présent ?

Invitez toute personne qui se soucie du produit. Les responsables techniques, les designers, le service client, et même de vrais clients si possible. Plus les retours sont diversifiés, meilleur sera votre prochain sprint.

Sprint retrospective

La rétrospective est le moment où l'équipe s'examine elle-même. Qu'est-ce qui a bien fonctionné ? Qu'est-ce qui n'a pas fonctionné ? Qu'est-ce qui devrait changer ? C'est le seul événement entièrement centré sur la façon dont l'équipe travaille plutôt que sur ce qu'elle construit. Points clés :

Timebox : Jusqu'à 3 heures pour un sprint de 4 semaines (environ 90 minutes pour un sprint de 2 semaines)
Qui participe : Scrum Master, équipe de développement (Product Owner optionnel mais recommandé)
Résultat : Actions concrètes pour le prochain sprint

Une bonne rétro produit une ou deux actions concrètes. Pas une liste de souhaits. Pas des engagements vagues comme "mieux communiquer". Des changements spécifiques, assignables, que l'équipe met réellement en oeuvre. Pour approfondir, consultez notre guide pour mener une rétrospective efficace. Si vos rétros semblent répétitives, essayez de varier le format avec des idées fraîches de rétrospective ou commencez par des questions brise-glace pour détendre l'atmosphère avant la vraie discussion.

Équipe illustrée assise en cercle avec des bulles de pensée contenant des coches vertes et des drapeaux rouges, votant sur des post-it sur un tableau

Rendre les rétros sûres

Les rétrospectives ne fonctionnent que lorsque les gens se sentent en sécurité pour être honnêtes. Le feedback anonyme et le vote aident. Tout comme l'établissement de règles de base au début : pas de blâme, pas d'interruptions, toutes les perspectives sont bienvenues. Si les membres de l'équipe se retiennent, la rétro devient une formalité au lieu d'un outil. Les tableaux de rétrospective de Kollabe prennent en charge les soumissions et le vote anonymes par défaut, ce qui aide les membres plus discrets à contribuer sans pression.

Suivez vos actions

Le plus grand tueur de rétro est de ne jamais assurer le suivi des actions. Choisissez un ou deux changements par sprint et assignez une personne spécifique à chacun. Passez en revue les actions du sprint précédent au début de chaque rétro.

Comment les cinq événements se connectent

Ces événements ne sont pas des réunions isolées. Ils forment un cycle :

Événement	Entrée	Sortie
Sprint planning	Backlog affiné, retours précédents	Objectif du sprint + sprint backlog
Daily scrum	Avancement de la veille, plan du jour	Coordination, résolution des blocages
Sprint review	Incrément terminé	Retours des parties prenantes, mises à jour du backlog
Sprint retrospective	Observations de l'équipe	Améliorations du processus
Sprint	Tout ce qui précède	Incrément livrable

Les retours de la sprint review alimentent la priorisation du backlog. Les actions de la rétrospective changent la façon dont le sprint suivant se déroule. Les daily scrums font remonter les problèmes qui sont traités le jour même. Supprimez n'importe quel événement et le cycle se brise.

Erreurs courantes dans toutes les cérémonies

😴Faire les choses machinalement

Organiser les événements parce que scrum le dit, sans véritable engagement. Si personne ne fait attention, la réunion est du gaspillage.

⏰Ignorer les timeboxes

Un standup de 15 minutes qui dure 45 minutes n'est plus un standup. Les timeboxes existent pour forcer la concentration. Utilisez un minuteur.

🚫Sauter des événements quand on est débordé

Le sprint où vous "n'avez pas le temps pour une rétro" est le sprint qui en avait le plus besoin.

👥Mauvais public

Des parties prenantes au daily scrum, des développeurs absents de la sprint review. Chaque événement a un public défini pour une raison. Consultez notre guide sur qui devrait participer à une rétrospective.

Référence rapide

Événement	Timebox (sprint de 2 semaines)	Participants	Fréquence
Sprint	2 semaines	Équipe scrum entière	Continu
Sprint planning	~2 heures	PO, SM, équipe de dev	Début de sprint
Daily scrum	15 minutes	Équipe de dev	Chaque jour
Sprint review	~1 à 2 heures	Équipe scrum + parties prenantes	Fin de sprint
Sprint retrospective	~90 minutes	SM, équipe de dev, PO (optionnel)	Fin de sprint, après la review

Pour conclure

Les cérémonies scrum fonctionnent comme un système. Chaque événement alimente le suivant, et ensemble ils créent une boucle de planification, construction, collecte de feedback et ajustement. Comprenez chacun individuellement, mais prêtez attention à la façon dont ils se connectent. Si vous souhaitez de meilleurs outils pour vos cérémonies, Kollabe gère l'estimation, les rétrospectives et les standups en un seul endroit.

Oui. Le Scrum Guide utilise "événements" comme terme officiel, mais "cérémonies" est largement utilisé en pratique. Ils désignent les mêmes cinq activités : le sprint, le sprint planning, le daily scrum, la sprint review et la sprint retrospective.

Chaque événement a un rôle spécifique dans le cycle d'inspection et d'adaptation. Sautez les sprint reviews et vous construisez la mauvaise chose. Sautez les rétros et les problèmes de processus ne sont jamais résolus. Sautez la planification et personne ne s'accorde sur l'objectif. Ils fonctionnent en ensemble.

Le daily scrum est le plus facile à passer en asynchrone, surtout pour les équipes distribuées. Le sprint planning et les rétrospectives bénéficient de discussions en temps réel mais peuvent utiliser des approches hybrides où les contributions sont recueillies en asynchrone et les décisions sont prises de manière synchrone. Les sprint reviews sont les plus difficiles à faire en asynchrone car le feedback en direct est tout l'intérêt.

Les grandes organisations utilisant des frameworks comme SAFe ou LeSS ajoutent des événements de coordination en plus des cinq événements de base. Mais au niveau de l'équipe individuelle, les cérémonies restent les mêmes. Chaque équipe scrum (idéalement 3 à 9 personnes) organise son propre ensemble d'événements quelle que soit la taille de l'entreprise.

Dernière mise à jour le 09/02/2026