Sprint Review vs Rétrospective Scrum : différences et templates

Sprint review ou rétrospective Scrum : "on fait laquelle d'abord ?" "c'est quoi la différence ?" Ces questions reviennent à chaque fin de sprint dans des dizaines d'équipes. Les deux cérémonies se tiennent le même jour, les deux portent sur le sprint qui se termine — et pourtant la sprint review et la rétrospective n'ont rien en commun sur le fond.

Confondre les deux, c'est soit présenter son incrément devant les parties prenantes en se demandant ce qui s'est mal passé, soit passer une heure à critiquer les processus internes devant le client. Les deux scénarios sont embarrassants et improductifs.

Ce guide clarifie une fois pour toutes la différence, explique comment animer chaque cérémonie, et donne les templates pour démarrer dès le prochain sprint.

Sprint Review vs Rétrospective Scrum : la réponse courte

Sprint Review — cérémonie tournée vers l'extérieur : l'équipe présente l'incrément aux parties prenantes, recueille du feedback sur le produit et adapte le backlog en conséquence. Objectif : inspecter le produit.

Rétrospective — cérémonie tournée vers l'intérieur : l'équipe seule (sans parties prenantes) inspecte ses processus, sa collaboration et ses pratiques pour s'améliorer. Objectif : inspecter l'équipe.

Même sprint, deux regards différents. L'un regarde le quoi (le produit livré), l'autre regarde le comment (la façon dont l'équipe a travaillé).

Tableau comparatif rapide

La Sprint Review en détail

Définition et objectif

La Sprint Review est la cérémonie qui clôture le sprint côté produit. L'équipe Scrum présente l'incrément — ce qui a été terminé selon la Definition of Done — aux parties prenantes : product owner, clients, managers, utilisateurs représentatifs.

L'objectif n'est pas une "démo" au sens commercial du terme. C'est une session d'inspection et d'adaptation : est-ce que ce qu'on a livré correspond toujours à ce dont l'utilisateur a besoin ? Le marché a-t-il évolué ? Les priorités du backlog doivent-elles changer ?

Le Guide Scrum 2020 est clair : la sprint review est une réunion de travail, pas une présentation formelle avec slides. Les parties prenantes interagissent avec le produit réel, posent des questions et donnent du feedback qui alimente directement le backlog.

Qui assiste à la sprint review ?

• L'équipe Scrum complète : Scrum Master, Product Owner, développeurs
• Les parties prenantes clés : commanditaires, représentants utilisateurs, clients directs, managers produit
• Optionnel : toute personne dont le feedback aurait de la valeur pour le produit

Ce que la sprint review n'est pas : une réunion interne entre développeurs. Sans parties prenantes, vous perdez l'essence même de la cérémonie — le feedback externe sur le produit.

Déroulement type (2 heures pour un sprint de 2 semaines)

1. Contexte du sprint (10 min) — Le Product Owner rappelle l'objectif du sprint et les user stories sélectionnées. Il mentionne ce qui a été terminé et ce qui ne l'a pas été, sans excuses.
2. Démonstration (60 min) — L'équipe présente les fonctionnalités terminées story par story, en mode "live" sur l'environnement réel ou de staging. Pas de présentations PowerPoint — on montre, on ne raconte pas.
3. Discussion et feedback (30 min) — Les parties prenantes posent des questions, partagent leurs réactions et formulent de nouvelles demandes ou ajustements.
4. Mise à jour du backlog (20 min) — Le PO, avec le feedback reçu, ajuste les priorités, ferme des stories devenues inutiles ou ajoute de nouvelles. C'est le vrai livrable de la sprint review.

Ce qu'on ne présente pas

La règle d'or : on ne présente que ce qui est terminé selon la DoD. Une story à 90 % n'est pas terminée. La présenter comme "presque finie" crée de faux espoirs chez les parties prenantes et brouille le signal sur la vélocité réelle. Les stories non terminées retournent dans le backlog — point.

La Rétrospective Scrum en détail

Définition et objectif

La rétrospective est la cérémonie d'amélioration continue de l'équipe. Contrairement à la sprint review, elle est entièrement tournée vers l'intérieur : comment l'équipe a-t-elle travaillé ensemble ? Quels processus ont bien fonctionné ? Lesquels créent de la friction ? Qu'est-ce qu'on veut changer pour le prochain sprint ?

C'est la seule cérémonie Scrum sans parties prenantes. Cette confidentialité est intentionnelle : elle crée un espace safe pour parler franchement des dysfonctionnements, des tensions interpersonnelles et des problèmes organisationnels sans risque de jugement externe.

Qui assiste à la rétrospective ?

• L'équipe Scrum uniquement : Scrum Master, Product Owner, développeurs
• Personne d'autre — ni managers, ni clients, ni parties prenantes

Le Scrum Master facilite la rétrospective mais n'en est pas le juge. Son rôle : créer les conditions pour que tout le monde s'exprime, pas décider ce qui doit changer.

Durée

Maximum 1 h 30 pour un sprint de 2 semaines. Au-delà, la fatigue génère du conformisme — les gens acquiescent pour en finir plutôt que d'approfondir les vrais problèmes. Une rétrospective bien animée de 45 minutes vaut mieux qu'une de 2 heures qui tourne en rond.

Les formats de rétrospective

Start / Stop / Continue — le format de référence

C'est le format le plus utilisé, le plus simple à faciliter et le plus efficace pour les équipes qui démarrent. Chaque participant répond à trois questions :

• Start — Qu'est-ce qu'on devrait commencer à faire qu'on ne fait pas encore ? (nouvelles pratiques, outils, rituels)
• Stop — Qu'est-ce qu'on devrait arrêter de faire car ça crée de la friction ou du gaspillage ?
• Continue — Qu'est-ce qui a bien fonctionné et qu'on doit absolument conserver ?

Chacun écrit ses réponses individuellement (post-its physiques ou digitaux), puis l'équipe regroupe les thèmes communs et vote sur les points à traiter en priorité. On termine avec 1 à 3 actions concrètes pour le prochain sprint — pas plus, sinon rien n'est fait.

Mad / Sad / Glad

Format plus émotionnel, utile pour détecter les tensions humaines que le Start/Stop/Continue peut masquer. Les participants partagent ce qui les a rendus frustrés (mad), tristes ou découragés (sad), et satisfaits ou fiers (glad) pendant le sprint. Efficace après un sprint difficile pour libérer la parole avant d'analyser.

Les 4L (Liked, Learned, Lacked, Longed For)

Quatre angles d'analyse :

• Liked — Ce qu'on a apprécié
• Learned — Ce qu'on a appris
• Lacked — Ce qui manquait (ressources, clarté, décisions)
• Longed For — Ce qu'on aurait souhaité avoir ou faire autrement

Ce format pousse l'équipe à capitaliser sur les apprentissages, pas seulement sur les problèmes — utile pour les équipes qui ont tendance à ne voir que ce qui ne va pas.

Sailboat (le bateau)

Métaphore visuelle : l'équipe est un bateau. Le vent représente les éléments qui ont accéléré la livraison ; les ancres représentent ce qui a ralenti. Les récifs symbolisent les risques à venir ; l'île est l'objectif. Très efficace pour les équipes visuelles et pour intégrer la dimension anticipation (risques futurs) à la rétrospective.

Les erreurs qui sabotent ces cérémonies

Erreurs sur la Sprint Review

1. Présenter ce qui n'est pas fini

"Ça marche presque, on vous montre quand même" — ce moment crée une confusion durable dans l'esprit des parties prenantes sur l'état réel du produit. Tenez-vous à la DoD, sans exception.

2. Transformer la review en réunion de statut

La sprint review n'est pas un reporting. Si l'équipe passe 40 minutes à expliquer pourquoi des stories n'ont pas été finies plutôt qu'à montrer ce qui fonctionne, la cérémonie perd sa valeur de feedback produit.

3. Ne pas adapter le backlog pendant la réunion

Le feedback des parties prenantes ne doit pas atterrir dans un document pour "être traité plus tard". Le PO doit pouvoir ajuster les priorités en direct. C'est l'output concret de la sprint review.

Erreurs sur la Rétrospective

1. Inviter les parties prenantes ou le management

La présence d'un manager — même bienveillant — change radicalement la dynamique. Les gens n'expriment pas les mêmes choses devant leur hiérarchie. Réservez cet espace à l'équipe Scrum.

2. Définir trop d'actions

Terminer une rétrospective avec une liste de 12 actions d'amélioration, c'est garantir que zéro sera fait. Priorisez sans pitié : 1 action urgente, 2 actions souhaitables, le reste dans un backlog d'amélioration pour les prochains sprints.

3. Ne jamais faire le bilan des actions précédentes

Commencer chaque rétro par "qu'est-ce qu'on avait décidé le sprint dernier et qu'avons-nous réellement fait ?" n'est pas optionnel. Sans ce bilan, les mêmes problèmes reviennent indéfiniment et l'équipe perd confiance dans l'utilité de la cérémonie.

4. Toujours utiliser le même format

Start/Stop/Continue est excellent — mais l'utiliser 20 fois de suite génère de la routine et des réponses automatiques. Variez les formats selon le contexte : après un sprint très réussi (4L pour capitaliser les apprentissages), après un sprint conflictuel (Mad/Sad/Glad pour libérer la parole), pour anticiper les risques (Sailboat).

Dans quel ordre les faire ?

La séquence officielle Scrum de fin de sprint est :

1. Sprint Review — avec les parties prenantes
2. Rétrospective — équipe seule
3. Sprint Planning du sprint suivant — idéalement le lendemain ou après une pause

Pourquoi la review avant la rétro ? Parce que le feedback des parties prenantes peut nourrir la rétrospective. Si la démo révèle que la qualité n'était pas au rendez-vous, c'est un signal utile pour la rétro. L'inverse — faire la rétro avant la review — prive l'équipe de ce contexte.

Le sprint planning du sprint suivant ne devrait jamais s'enchaîner directement avec la rétro : l'équipe a besoin d'une pause mentale entre "qu'est-ce qu'on améliore" et "comment on engage le prochain sprint". Pour structurer ce planning, consultez notre guide comment organiser un sprint planning efficace en 5 étapes.

Templates pratiques

Template Sprint Review (sprint de 2 semaines — 2 h)

• [ ] Rappel de l'objectif du sprint (Sprint Goal) — 5 min
• [ ] Stories terminées vs non terminées — 5 min (PO)
• [ ] Démo story par story sur environnement réel — 50 min
• [ ] Session de feedback ouvert — 20 min
• [ ] Révision du backlog en live — 25 min (PO + équipe)
• [ ] Prochaines étapes annoncées — 5 min

Template Rétrospective Start/Stop/Continue (45 min)

• [ ] Bilan des actions du sprint précédent — 5 min
• [ ] Écriture individuelle silencieuse (Start / Stop / Continue) — 10 min
• [ ] Regroupement thématique des réponses — 5 min
• [ ] Vote sur les thèmes prioritaires — 5 min
• [ ] Discussion des 2–3 thèmes les plus votés — 15 min
• [ ] Définition des actions concrètes (max 3) avec responsable — 5 min

Sprint Review et Rétrospective dans Manifst

Dans Manifst, la sprint review s'articule autour des stories complétées du sprint : chaque story acceptée peut recevoir des commentaires directement dans l'outil, ce qui permet de tracer le feedback des parties prenantes story par story, sans perdre ces retours dans des fils de discussion épars.

La rétrospective est intégrée nativement au format Start/Stop/Continue : chaque membre de l'équipe contribue ses réponses, les thèmes émergent et les actions sont enregistrées dans l'outil — sans avoir besoin d'ouvrir un tableau Miro ou un outil de rétro séparé.

Essayez Manifst gratuitement — 1 projet, 4 membres, toutes les cérémonies incluses, sans carte bancaire.