Articles

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

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.

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.

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.

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.

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.

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.

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

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.