Daily Scrum, Sprint Review et Sprint Retrospective — The Scrum Guide

Le Sprint est un contenant, et la Sprint Planning en trace le plan initial — mais un plan tracé le premier jour ne survit jamais intact au contact du réel. C'est là qu'interviennent les trois autres événements formels que le Sprint enveloppe : le Daily Scrum, la Sprint Review et la Sprint Retrospective. Chacun est une occasion formelle d'inspecter et d'adapter, mais chacun braque le projecteur sur un objet différent. Le Daily Scrum inspecte le progrès quotidien vers le Sprint Goal et adapte le Sprint Backlog. La Sprint Review inspecte le résultat du Sprint avec les parties prenantes et prépare les adaptations futures du produit. La Sprint Retrospective, enfin, inspecte l'équipe elle-même — ses individus, ses interactions, ses processus, ses outils — pour augmenter la qualité et l'efficacité. Trois boucles emboîtées, du quotidien au produit puis à la manière de travailler : c'est toute la mécanique empirique de Scrum condensée en trois rendez-vous.

Daily Scrum : quinze minutes pour ajuster le cap

Le but du Daily Scrum (mêlée quotidienne) est limpide : inspecter le progrès vers le Sprint Goal et adapter le Sprint Backlog si nécessaire, en ajustant le travail planifié à venir. Ce n'est ni un rapport d'activité, ni une réunion de suivi pour un chef de projet : c'est l'application quotidienne, à petite échelle, du cycle inspection-adaptation.

Le format prescrit par le guide tient en peu de mots. C'est un événement de quinze minutes, destiné aux Developers de la Scrum Team. Pour réduire la complexité, il se tient à la même heure et au même endroit chaque jour ouvré du Sprint — pas de négociation de créneau, pas de charge mentale d'organisation : le rendez-vous est un réflexe. Et le guide règle avec élégance la question de la présence des autres rôles : si le Product Owner ou le Scrum Master travaillent activement sur des items du Sprint Backlog, ils participent en tant que Developers. Autrement dit, on ne vient pas au Daily Scrum au titre de sa casquette, mais au titre du travail qu'on accomplit dans le Sprint.

Pour le reste, la liberté est totale : les Developers peuvent choisir la structure et les techniques qu'ils veulent, du moment que leur Daily Scrum se concentre sur le progrès vers le Sprint Goal et produit un plan actionnable pour la prochaine journée de travail. Ce double critère — focalisation sur l'objectif, plan concret en sortie — est le seul test de validité de l'événement. Un tour de table, une lecture du tableau de droite à gauche, une discussion centrée sur les obstacles : peu importe la forme, tant que l'équipe ressort en sachant ce qu'elle fait aujourd'hui et pourquoi. Le guide souligne que cette pratique crée du focus et améliore le self-management : c'est l'équipe qui se pilote elle-même, chaque jour, sans attendre qu'on le fasse pour elle.

Note

Le guide 2020 ne prescrit aucun format pour le Daily Scrum — on n'y trouve nulle part les fameuses « trois questions » (« qu'ai-je fait hier, que vais-je faire aujourd'hui, quels obstacles ? ») souvent associées à cet événement dans les usages courants. Seuls comptent les deux critères du guide : rester concentré sur le progrès vers le Sprint Goal et produire un plan actionnable pour le jour à venir. La structure appartient aux Developers.

Les bénéfices énumérés par le guide dessinent en creux le portrait d'une organisation plus saine : les Daily Scrums améliorent la communication, identifient les obstacles, favorisent des prises de décision rapides et, par conséquent, éliminent le besoin d'autres réunions. Ce dernier point mérite qu'on s'y arrête : un Daily Scrum bien mené n'ajoute pas une réunion au calendrier, il en retire plusieurs. Quinze minutes de synchronisation quotidienne remplacent les points de coordination improvisés, les comités de suivi et les chaînes de messages où l'information se perd.

Enfin, le guide prend soin de désamorcer une lecture trop rigide : le Daily Scrum n'est pas le seul moment où les Developers ont le droit d'ajuster leur plan. Ils se retrouvent souvent au fil de la journée pour des discussions plus détaillées sur l'adaptation ou la replanification du reste du travail du Sprint. Le Daily Scrum garantit un point de synchronisation minimal et régulier ; il ne rationne pas la collaboration.

Attention

Anti-pattern courant (observation générale, pas une citation du guide) : le Daily Scrum qui dérive en compte rendu au Scrum Master ou au manager. Chacun s'adresse à une figure d'autorité plutôt qu'à ses pairs, l'événement devient un rituel de reporting, et le plan actionnable pour la journée n'émerge jamais. Le guide est pourtant clair sur le destinataire : cet événement est pour les Developers — c'est leur outil de pilotage, pas un instrument de contrôle.

Sprint Review : inspecter le résultat avec les parties prenantes

Si le Daily Scrum regarde vers l'intérieur de l'équipe, la Sprint Review (révision de Sprint) ouvre grand les portes. Son but est d'inspecter le résultat du Sprint et de déterminer les adaptations futures. La Scrum Team y présente les résultats de son travail aux parties prenantes clés, et l'on y discute du progrès vers le Product Goal — pas seulement de ce qui a été livré ces dernières semaines, mais de la trajectoire d'ensemble du produit.

Le déroulé décrit par le guide articule deux mouvements. D'abord l'inspection : la Scrum Team et les parties prenantes passent en revue ce qui a été accompli durant le Sprint et ce qui a changé dans leur environnement. Cette seconde moitié de la phrase est souvent négligée, alors qu'elle est essentielle : entre le début et la fin d'un Sprint, le marché a pu bouger, un concurrent a pu sortir une fonctionnalité, une contrainte réglementaire a pu apparaître. L'inspection porte autant sur le monde que sur l'Increment. Ensuite l'adaptation : sur la base de ces informations, les participants collaborent sur ce qu'il convient de faire ensuite. Le Product Backlog peut être ajusté pour saisir de nouvelles opportunités — la Sprint Review alimente ainsi directement les Sprints suivants.

Le guide assène alors la phrase qui distingue une bonne Sprint Review d'une mauvaise : la Sprint Review est une session de travail, et la Scrum Team devrait éviter de la limiter à une présentation. La démonstration du produit a toute sa place, mais elle n'est qu'un support de l'inspection, pas la finalité de l'événement. Si les parties prenantes repartent après avoir applaudi poliment un diaporama sans qu'aucune décision sur la suite n'ait été discutée, l'événement a eu lieu, mais son but a été manqué : il n'y a eu ni véritable inspection, ni adaptation.

À retenir

La Sprint Review réussie se reconnaît à ses sorties, pas à son déroulé : des enseignements partagés sur l'état du produit et de son environnement, et des orientations concrètes pour la suite — éventuellement matérialisées par un Product Backlog ajusté. Une démo suivie de « pas de questions ? parfait, à dans deux semaines » est une présentation, pas une session de travail.

Côté logistique, la Sprint Review est l'avant-dernier événement du Sprint et son timebox est de quatre heures maximum pour un Sprint d'un mois — pour des Sprints plus courts, l'événement est généralement plus court. On peut noter — on y reviendra au chapitre sur les artefacts — que le guide précise ailleurs que la Sprint Review ne doit jamais être considérée comme une barrière au déploiement de la valeur : un Increment peut être livré aux parties prenantes avant la fin du Sprint. La Review n'est pas une porte de validation, c'est un point de convergence.

Sprint Retrospective : améliorer l'équipe elle-même

Le dernier événement du Sprint ne regarde ni le plan du jour, ni le produit : il regarde la manière dont l'équipe travaille. Le but de la Sprint Retrospective (rétrospective de Sprint) est de planifier des moyens d'augmenter la qualité et l'efficacité.

Le périmètre d'inspection est remarquablement large : la Scrum Team examine comment s'est déroulé le dernier Sprint concernant les individus, les interactions, les processus, les outils et leur Definition of Done. Ce dernier élément surprend parfois : la définition de « Fini » n'est pas gravée dans le marbre, c'est un standard de qualité vivant que l'équipe peut durcir au fil des Sprints — et la Retrospective est précisément le lieu où l'on décide de le faire. Le guide précise que les éléments inspectés varient souvent selon le domaine de travail : une équipe de développement logiciel, une équipe de recherche et une équipe marketing ne scruteront pas les mêmes aspects.

La discussion elle-même suit une trame que le guide esquisse sans la rigidifier. L'équipe identifie les hypothèses qui l'ont induite en erreur et en explore les origines — formulation d'inspiration très empirique : on ne cherche pas un coupable, on cherche l'hypothèse fausse et ce qui l'a rendue crédible. Elle discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés, et de la manière dont ces problèmes ont été (ou n'ont pas été) résolus. La parenthèse du guide est savoureuse : admettre qu'un problème n'a pas été résolu est déjà une inspection honnête, et c'est la valeur d'Openness (ouverture) en action.

Mais une Retrospective qui se contente de dresser des constats resterait, pour reprendre les termes de la théorie Scrum, une inspection sans adaptation — donc un exercice vain. Le guide exige un débouché : la Scrum Team identifie les changements les plus utiles pour améliorer son efficacité, et les améliorations les plus impactantes sont traitées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog du Sprint suivant — l'amélioration du processus devient alors un travail planifié, visible et suivi au même titre que le travail sur le produit, et non une bonne résolution condamnée à s'évaporer.

Astuce

Le critère « les plus utiles » invite à la frugalité : mieux vaut sortir d'une Retrospective avec une ou deux améliorations réellement traitées qu'avec une liste de quinze intentions jamais suivies d'effet. Inscrire l'amélioration choisie au Sprint Backlog suivant, comme le guide le permet explicitement, est le moyen le plus sûr qu'elle survive au retour du quotidien.

La Sprint Retrospective conclut le Sprint. Son timebox est de trois heures maximum pour un Sprint d'un mois, généralement moins pour des Sprints plus courts. Sa position n'a rien d'anodin : l'équipe ferme la boucle sur sa façon de travailler juste avant qu'un nouveau Sprint ne démarre — et comme un nouveau Sprint commence immédiatement après la fin du précédent, les enseignements de la Retrospective peuvent irriguer la Sprint Planning qui suit sans délai.

Les cinq événements en synthèse

Avec le Sprint et la Sprint Planning vus au chapitre précédent, la panoplie des événements Scrum est désormais complète. Le tableau suivant récapitule qui participe, ce qu'on y inspecte et adapte, et les limites de temps fixées par le guide (les maxima s'entendent pour un Sprint d'un mois ; pour des Sprints plus courts, les événements sont généralement plus courts).

Événement	Participants	But	Timebox
Sprint	Scrum Team	Contenant de tous les autres événements ; transformer les idées en valeur	Longueur fixe, un mois ou moins
Sprint Planning	Scrum Team (invités possibles pour conseil)	Définir le Sprint Goal, sélectionner les items, planifier le travail (pourquoi, quoi, comment)	Maximum 8 heures
Daily Scrum	Developers (PO et SM en tant que Developers s'ils travaillent sur le Sprint Backlog)	Inspecter le progrès vers le Sprint Goal, adapter le Sprint Backlog, plan actionnable pour la journée	15 minutes, chaque jour ouvré
Sprint Review	Scrum Team et parties prenantes clés	Inspecter le résultat du Sprint, discuter du progrès vers le Product Goal, déterminer les adaptations futures	Maximum 4 heures
Sprint Retrospective	Scrum Team	Planifier des moyens d'augmenter la qualité et l'efficacité	Maximum 3 heures

On remarque la gradation des objets d'inspection : le Daily Scrum ajuste le plan (Sprint Backlog), la Sprint Review ajuste le produit (Product Backlog, adaptations futures), la Retrospective ajuste le processus (qualité et efficacité de l'équipe). Trois niveaux, trois cadences, un même mécanisme empirique — et, comme le rappelle le guide, chaque événement manqué ou dénaturé est une occasion perdue d'inspecter et d'adapter.

À retenir

Le Daily Scrum dure 15 minutes, se tient à la même heure et au même endroit chaque jour ouvré du Sprint, et s'adresse aux Developers ; son but est d'inspecter le progrès vers le Sprint Goal et d'adapter le Sprint Backlog en ajustant le travail planifié à venir.
Si le Product Owner ou le Scrum Master travaillent activement sur des items du Sprint Backlog, ils participent au Daily Scrum en tant que Developers.
Le guide ne prescrit aucun format de Daily Scrum (pas de « trois questions ») : les Developers choisissent leur structure, tant que l'événement reste focalisé sur le Sprint Goal et produit un plan actionnable pour la journée ; il crée du focus, améliore le self-management, la communication et la prise de décision rapide, et élimine le besoin d'autres réunions — sans être le seul moment où l'on peut ajuster le plan.
La Sprint Review inspecte le résultat du Sprint avec les parties prenantes clés : on y passe en revue ce qui a été accompli et ce qui a changé dans l'environnement, on discute du progrès vers le Product Goal, et le Product Backlog peut être ajusté pour saisir de nouvelles opportunités.
La Sprint Review est une session de travail, pas une simple présentation ; c'est l'avant-dernier événement du Sprint, limité à 4 heures maximum pour un Sprint d'un mois.
La Sprint Retrospective vise à augmenter la qualité et l'efficacité : l'équipe inspecte individus, interactions, processus, outils et Definition of Done, identifie les hypothèses qui l'ont induite en erreur, et retient les changements les plus utiles.
Les améliorations les plus impactantes sont traitées dès que possible et peuvent être ajoutées au Sprint Backlog du Sprint suivant ; la Retrospective conclut le Sprint et dure 3 heures maximum pour un Sprint d'un mois.