Cette page rassemble la Sprint Review Checklist francophone la plus complète : préparation amont, déroulement de la réunion, exploitation du feedback, adaptation du Product Backlog et vérifications dédiées au Product Owner, aux Developers et au Scrum Master. Elle complète le guide pilier Sprint Review, le Sprint Review Template (structure réutilisable) et le Sprint Review Example (cas concrets) pour garantir qu'aucun point critique n'est oublié.
Pourquoi utiliser une checklist de Sprint Review ?
La Sprint Review est l'événement qui clôture chaque Sprint Scrum. C'est le seul moment formel où le Scrum Team inspecte l'Increment avec les stakeholders et adapte le Product Backlog en fonction de ce qui a été appris. Sa qualité conditionne directement la pertinence du Sprint Planning suivant.
Une checklist Sprint Review (ou Sprint Review meeting checklist) ne remplace pas le facilitateur, ne se substitue pas à l'expérience de l'équipe et n'est pas prescrite par le Scrum Guide. C'est un aide-mémoire opérationnel qui apporte trois bénéfices concrets :
- Réduire les oublis : démo qui plante faute de données, stakeholder clé absent, feedback non capturé, Product Backlog non mis à jour. Chacun de ces oublis casse la boucle empirique.
- Sécuriser la Sprint Review readiness : la checklist garantit que l'Increment est Done, que la démo a été répétée et que les bons interlocuteurs sont dans la salle (ou la visio).
- Industrialiser l'amélioration continue : la checklist est un objet d'inspection en Sprint Retrospective. On ajoute une ligne après chaque incident, on en retire une quand elle devient inutile.
Flux et chronologie
Préparer la Sprint Review : les fondations
Une Sprint Review réussie repose sur trois fondations posées en amont : un Increment Done, une démo fluide et les bons stakeholders présents. Sans ces trois éléments, aucune checklist ne sauve l'événement.
Cette préparation s'appuie sur le Sprint Goal initial : il détermine quoi montrer en priorité, qui inviter et quels feedbacks attendre. Si le Sprint Goal n'a pas été atteint, la Sprint Review ne s'annule pas — elle devient au contraire un moment d'inspection encore plus important.
Checklist — avant la Sprint Review (préparation)
La préparation se déroule sur les 2 à 3 jours précédents. Elle est portée principalement par les Developers et le Product Owner, avec le soutien logistique du Scrum Master.
✓ Avant la réunion — Increment & démo (J-3 à J-1)
- L'Increment respecte intégralement la Definition of Done.Critique
- L'Increment est déployé sur un environnement de démo accessible.Critique
- La démo a été répétée au moins une fois en conditions réelles.Critique
- Les données de démo sont réalistes (pas de « foo », « bar », « test 123 »).
- Le scénario de démo est aligné avec le Sprint Goal et la valeur livrée.Critique
- Un plan B est prévu si l'environnement de démo tombe (vidéo de secours, captures).
- Les éléments non terminés ne seront PAS montrés comme Done.
✓ Avant la réunion — Stakeholders & logistique
- Les stakeholders clés concernés par le Sprint Goal sont invités.Critique
- Les invitations précisent l'objectif, la durée et l'agenda.
- La salle / visio est testée (audio, partage d'écran, micros).
- Un scribe est désigné pour capturer le feedback en temps réel.Critique
- Le Product Backlog actuel est ouvert et accessible en séance.
- Les métriques produit utiles (usage, conversion, performance) sont préparées.
- La disponibilité du Scrum Team complet est confirmée sur toute la timebox.Critique
Checklist — pendant la Sprint Review (réunion)
La Sprint Review n'est pas une démo descendante : c'est une session de travail collaborative. La checklist ci-dessous garantit que chaque phase produit sa contribution.
✓ Ouverture (5 à 15 min)
- Le Scrum Master rappelle l'objectif et la timebox de la Sprint Review.
- Le Product Owner rappelle le Sprint Goal et son atteinte (oui / partiel / non).Critique
- L'agenda et le format de feedback sont annoncés aux stakeholders.
- Les nouveaux participants se présentent brièvement.
✓ Inspection de l'Increment — démo (30 à 60 min)
- Les Developers présentent l'Increment, pas le PO seul.Critique
- Seuls les éléments Done sont montrés.Critique
- La démo suit un scénario utilisateur, pas une liste de tickets.
- Les éléments non terminés sont mentionnés honnêtement comme non Done.
- Les métriques produit pertinentes sont partagées.
✓ Feedback & discussion produit (20 à 45 min)
- Les stakeholders sont activement sollicités, pas spectateurs.Critique
- Chaque feedback est capturé par le scribe en temps réel.Critique
- Le PO reformule pour vérifier la bonne compréhension.
- Les questions de marché, budget et timeline sont abordées si pertinent.
✓ Adaptation du Product Backlog (15 à 30 min)
- Les feedbacks retenus sont convertis en PBI candidats.Critique
- Les PBI existants sont réordonnés ou modifiés en séance.Critique
- Les éléments obsolètes sont supprimés du Product Backlog.
- Le prochain Sprint Goal candidat émerge naturellement de la discussion.
✓ Clôture (5 à 10 min)
- Les décisions clés sont récapitulées à voix haute.Critique
- Les next steps sont attribués à un responsable.
- La Sprint Retrospective qui suit est rappelée (uniquement Scrum Team).
- Les stakeholders sont remerciés pour leur feedback.
Checklist — après la Sprint Review
La Sprint Review ne s'arrête pas à la fin de la timebox. Pour que le feedback se transforme en valeur produit, il faut formaliser et diffuser ce qui a été décidé.
✓ Formalisation et diffusion (dans l'heure qui suit)
- Les notes de feedback sont consolidées et classées par type.Critique
- Les PBI nouveaux ou modifiés sont créés / mis à jour dans l'outil.Critique
- Le Product Backlog est ré-ordonné par le Product Owner.
- Une note de synthèse (5 lignes) est partagée aux stakeholders absents.
- Les actions de suivi externes (mails, validations) sont envoyées.
✓ Validation finale (Sprint Review To Do)
- Le Sprint Backlog du Sprint suivant est nourri des bons PBI.Critique
- Aucun feedback critique n'est resté sans réponse.
- Le Scrum Master a programmé la Sprint Retrospective.
- Les métriques produit présentées sont archivées pour comparaison future.
- Les leçons apprises sur la démo elle-même sont notées pour la Retrospective.
Checklist du Product Owner
✓ Product Owner — Sprint Review
- J'ai invité les stakeholders pertinents et confirmé leur présence.Critique
- J'ai préparé le récit de valeur autour du Sprint Goal.Critique
- Je sais expliquer clairement ce qui est Done et ce qui ne l'est pas.Critique
- Je suis prêt à animer la discussion produit, pas uniquement à présenter.
- Mon Product Backlog est à jour et accessible en séance.
- Je sais prendre des décisions de priorisation en temps réel face aux feedbacks.
- Je sais dire non à un feedback non aligné avec le Product Goal.
- J'ai en tête un Sprint Goal candidat pour le Sprint suivant.
Checklist des Developers
✓ Developers — Sprint Review
- Notre Increment respecte la Definition of Done.Critique
- Nous avons répété la démo au moins une fois.Critique
- Nous savons qui démontre quoi (rôles partagés).Critique
- Nous avons préparé un plan B si l'environnement de démo plante.
- Nous savons expliquer simplement les choix techniques au métier.
- Nous accueillons le feedback sans posture défensive.
- Nous identifions les contraintes techniques utiles à exposer en séance.
- Nous mettons à jour le Product Backlog avec le PO si nécessaire.
Checklist du Scrum Master
✓ Scrum Master — Sprint Review
- L'agenda et la timebox sont partagés en amont avec les participants.
- L'environnement (salle / visio / partage d'écran) est testé.Critique
- Un scribe est désigné pour capturer le feedback en temps réel.Critique
- Je facilite sans monopoliser la parole.
- Je rappelle le temps restant à intervalles réguliers.
- Je veille à ce que les stakeholders s'expriment, pas uniquement le Scrum Team.
- Je protège la timebox et l'objectif d'adaptation du Product Backlog.Critique
- Je m'assure que les sorties (feedback capturé + Backlog adapté) sont produites.Critique
Comment exploiter les feedbacks après la Sprint Review
Capturer le feedback n'est qu'une moitié du travail. L'autre moitié consiste à le transformer en valeur dans le Product Backlog. Une bonne pratique consiste à classer chaque feedback selon quatre catégories :
| Type | Définition | Action immédiate |
|---|---|---|
| Bug / défaut perçu | Comportement non conforme à l'attendu sur un élément Done. | Créer un PBI bug, prioriser dans les 1-2 prochains Sprints. |
| Nouvelle idée | Fonctionnalité ou amélioration non prévue jusqu'ici. | Créer un PBI candidat, raffiner ultérieurement, prioriser selon le Product Goal. |
| Changement de priorité | Demande de remonter ou descendre un PBI existant. | Discuter avec le PO en séance, réordonner le Product Backlog immédiatement. |
| Contrainte / risque | Information de marché, légale, technique ou budgétaire à intégrer. | Tracer dans le Backlog ou le wiki produit ; impact possible sur Product Goal. |
Tableau des responsabilités — qui vérifie quoi, et quand ?
| À vérifier | Responsable | Moment | Niveau |
|---|---|---|---|
| Increment Done | Developers | Avant | Critique |
| Démo répétée | Developers | Avant | Critique |
| Stakeholders invités et confirmés | Product Owner | Avant | Critique |
| Environnement de démo testé | Developers + SM | Avant | Critique |
| Scribe désigné | Scrum Master | Avant | Critique |
| Sprint Goal rappelé | Product Owner | Pendant (Ouverture) | Critique |
| Démo alignée sur la valeur | Developers | Pendant (Démo) | Critique |
| Feedback capturé en temps réel | Scribe / SM | Pendant (Feedback) | Critique |
| Product Backlog adapté en séance | Product Owner | Pendant (Adaptation) | Critique |
| Notes consolidées et diffusées | Scrum Master | Après | Important |
| PBI créés / modifiés dans l'outil | Product Owner | Après | Critique |
| Synthèse envoyée aux absents | Product Owner | Après | Facultatif |
| Sprint Retrospective programmée | Scrum Master | Après | Important |
Erreurs fréquentes vs bonnes pratiques
| Dimension | Bonne pratique | Erreur fréquente |
|---|---|---|
| Format | Session collaborative d'inspection / adaptation | Démo descendante figée |
| Préparation | Démo répétée, données réelles | Démo improvisée la veille |
| Increment | Strictement Done | On montre du « presque fini » |
| Stakeholders | 5-10 personnes clés concernées | Liste de diffusion de 50 personnes |
| Animation | PO + Developers présentent | PO seul, Developers spectateurs |
| Feedback | Capturé en temps réel par un scribe | « On s'en rappellera » |
| Product Backlog | Adapté en séance | Adapté plus tard, jamais |
| Sprint Goal | Rappelé et confronté à l'atteinte | Oublié, jamais évoqué |
| Suite | Notes diffusées dans l'heure | Aucune trace écrite |
Conseils Scrum Guide
Le Scrum Guide 2020 fixe quelques règles non négociables que votre Scrum Sprint Review checklist doit intégrer :
- La Sprint Review a pour objectif d'inspecter l'Increment et d'adapter le Product Backlog. Tout point de la checklist doit converger vers ces deux résultats.
- La timebox maximale est de 4 heures pour un Sprint d'un mois, à proratiser pour les Sprints plus courts. Une checklist qui pousserait au dépassement est mal calibrée.
- Les stakeholders sont invités par le Product Owner. Leur présence est attendue, pas optionnelle.
- La Sprint Review est un événement de travail, pas un comité de pilotage. Le format est collaboratif, pas une présentation.
- La Sprint Retrospective suit la Sprint Review et n'inclut que le Scrum Team. Ne pas mélanger les deux.
Pièges PSM I liés à la Sprint Review
Piège n°1 — La Sprint Review est une démo
Faux. La démo est un moyen d'inspecter l'Increment, mais l'objectif réel est l'adaptation du Product Backlog. Au PSM I, une Sprint Review qui se résume à une démo descendante est une mauvaise réponse.
Piège n°2 — On peut montrer ce qui n'est pas Done
Faux. Seuls les éléments respectant la Definition of Donepeuvent être présentés comme livrés. Les éléments non Done restent dans le Product Backlog.
Piège n°3 — Le Product Owner accepte ou refuse l'Increment
Trompeur. Le PO n'est pas un arbitre qui valide ou rejette. L'Increment est Done ou ne l'est pas, en fonction de la Definition of Done — qui est une responsabilité collective.
Piège n°4 — La Sprint Review est annulée si le Sprint Goal n'est pas atteint
Faux. La Sprint Review a lieu à chaque fin de Sprint, sans exception. L'inspection est encore plus précieuse quand le Sprint Goal n'a pas été atteint : il faut comprendre pourquoi et adapter.
Piège n°5 — Les stakeholders prennent les décisions de priorisation
Faux. Les stakeholders fournissent du feedback. Le Product Owner reste seul responsable de l'ordonnancement final du Product Backlog. Confondre influence et autorité est un classique du PSM I.
FAQ — Sprint Review Checklist
Les 12 questions ci-dessous synthétisent les interrogations les plus fréquentes autour d'une checklist revue de Sprint. Elles sont également exposées en JSON-LD pour aider Google et les moteurs IA à comprendre le contenu de cette page.