La Sprint Review est souvent confondue avec la rétrospective — alors que leurs objectifs sont radicalement différents : la rétro regarde en interne (comment l’équipe travaille), la Sprint Review regarde vers l’extérieur (ce qui a été livré et si cela correspond aux besoins réels). C’est le mécanisme qui évite de construire pendant des mois quelque chose que personne ne voulait vraiment.
La méthode — 5 étapes pour conduire une Sprint Review qui crée de la valeur
Étape 1 — Cadrer la session en introduction (5 minutes)
La Sprint Review commence par un rappel clair : quel était l’objectif du sprint ? Quels items avaient été engagés ? Quel est le contexte de l’équipe et du projet à ce stade ? Cette mise en situation permet aux parties prenantes de suivre même si elles n’étaient pas présentes au sprint planning. C’est aussi le moment de rappeler les règles du jeu : ce qui sera montré est terminé au sens de la définition of done. Pas de demi-finitions, pas de “ça marche à peu près”.
Action concrète : Préparez une slide d’introduction avec 3 éléments : l’objectif du sprint, les items engagés, et le résultat global (atteint / partiellement atteint / non atteint). Partagez-la avant la session pour que les parties prenantes arrivent avec le contexte.
Étape 2 — Démontrer ce qui est vraiment terminé (20-30 minutes)
L’équipe présente les fonctionnalités ou livrables réellement terminés — pas ce qui est “presque fini”. C’est la règle la plus importante et la plus souvent violée de la Sprint Review. Une démonstration de fonctionnalités incomplètes crée de la confusion et dilue la valeur réelle du sprint. Montrer du concret, qui fonctionne, qui répond à un besoin identifié — c’est ce qui génère l’engagement des parties prenantes.
Action concrète : Faites une répétition de 15 minutes avant la Sprint Review avec les membres de l’équipe qui démontrent. Définissez ensemble le fil conducteur de la démo : quel problème utilisateur illustre-t-elle ? Quel est le “wow moment” que vous voulez créer ?
Étape 3 — Organiser la discussion et collecter les retours (15-20 minutes)
C’est la partie la plus précieuse — et la plus souvent bâclée. Les observations des parties prenantes révèlent des incompréhensions, des besoins non exprimés ou des changements de priorité qu’aucune réunion de planning ne peut anticiper. L’équipe écoute, note, pose des questions de clarification. On ne défend pas les choix déjà faits, on cherche à comprendre ce qui crée de la valeur pour les utilisateurs finaux.
Action concrète : Désignez un “scribe” qui note en temps réel les retours et questions des parties prenantes. Utilisez un simple tableau avec deux colonnes : “Ce qui fonctionne bien” / “Ce qu’on voudrait différent”. Partagez ce document en fin de session.
Étape 4 — Mettre à jour le backlog en conséquence (10 minutes)
En fonction des retours collectés, le Product Owner ajuste les priorités du Product Backlog en direct ou dans les 24 heures suivant la session. Certains items montent, d’autres descendent, de nouveaux apparaissent. C’est le moment où la boucle de feedback se ferme concrètement. Sans cette étape, la Sprint Review reste un exercice de communication — elle ne devient pas un outil de pilotage.
Action concrète : À la fin de chaque Sprint Review, le Product Owner annonce à voix haute les 3 principales modifications qu’il va apporter au backlog suite aux retours reçus. Cela valide l’écoute réelle et donne du sens à la participation des parties prenantes.
Étape 5 — Adapter la Sprint Review aux contextes hors IT
La Sprint Review ne s’applique pas qu’au développement logiciel. En équipe commerciale, c’est partager les opportunités avancées, les résultats du mois, et ajuster la stratégie de prospection. En équipe marketing, c’est présenter les campagnes lancées et leurs résultats, puis décider des prochaines priorités. En management de projet, c’est confronter l’avancement réel aux attentes des commanditaires. Dans tous les cas, le principe est identique : raccourcir la boucle de feedback pour rester aligné avec la réalité.
Action concrète : Si vous n’êtes pas en contexte Scrum, créez un rendez-vous mensuel de 45 minutes avec vos parties prenantes internes. Structure : 10 min de résultats, 20 min de démo ou partage de livrables, 15 min de questions et réorientation.
Points de vigilance
La Sprint Review ne doit pas être un théâtre. Si les parties prenantes ne peuvent pas exprimer leur désaccord ou remettre en question les priorités, ce n’est pas une session collaborative — c’est une présentation déguisée. La sécurité psychologique pour donner un feedback honnête est indispensable. Si vous ressentez que personne n’ose critiquer, c’est un signal d’alarme à prendre au sérieux.
L’absence de vraies parties prenantes vide l’exercice de son sens. Si seuls les membres de l’équipe sont présents, on perd l’essentiel de la valeur. Investissez du temps pour convaincre les bonnes personnes de participer régulièrement — directeurs, clients internes, utilisateurs finaux. Leur présence n’est pas un luxe, c’est une condition de fonctionnement.
Respectez la durée limitée. Quatre heures maximum pour un sprint d’un mois, au prorata pour des sprints plus courts. Une Sprint Review qui s’étire perd son efficacité et décourage la participation. Si vous dépassez régulièrement, c’est que la préparation est insuffisante ou que le périmètre est trop large.
Ce que j’en retiens
La Sprint Review illustre un principe que je retrouve dans toutes les dimensions de la performance : la confrontation régulière avec la réalité externe est l’antidote le plus puissant aux dérives. En vente, en formation, en management de projet — raccourcir la boucle de feedback est le moyen le plus sûr de rester sur la bonne voie. Ce qui se mesure régulièrement s’améliore plus vite que ce qui se mesure une fois par an.
🧠 Mini Quiz — Testez vos connaissances
5 questions pour valider votre compréhension et passer à l’action sur la Sprint Review
Question 1 — Quelle est la différence fondamentale entre Sprint Review et Rétrospective ?
- A) La Rétrospective dure plus longtemps que la Sprint Review
- B) La Sprint Review regarde l’externe (livrables, parties prenantes) et la Rétro regarde l’interne (fonctionnement de l’équipe)
- C) La Sprint Review est obligatoire, la Rétrospective est optionnelle
- D) La Rétrospective implique le management, la Sprint Review non
✅ Bonne réponse : B — Ces deux événements Scrum ont des objectifs distincts. Confondre les deux, c’est perdre l’un ou l’autre — soit la boucle de feedback externe sur le produit, soit la boucle d’amélioration interne de l’équipe.
Question 2 — Que peut-on présenter lors d’une Sprint Review ?
- A) Tout ce qui a été commencé durant le sprint
- B) Uniquement les items conformes à la définition of done
- C) Les items à 80% terminés pour obtenir des retours précoces
- D) Les fonctionnalités planifiées pour le prochain sprint
✅ Bonne réponse : B — La règle est stricte : on ne montre que ce qui est vraiment terminé selon la définition of done. Présenter des demi-finitions crée de la confusion et dilue la valeur réelle du travail accompli. C’est une des disciplines les plus importantes du Scrum.
Question 3 — Quel est le moment le plus précieux d’une Sprint Review ?
- A) L’introduction qui présente les objectifs du sprint
- B) La démonstration des fonctionnalités terminées
- C) La discussion avec les parties prenantes et la collecte de retours
- D) La mise à jour du backlog par le Product Owner
✅ Bonne réponse : C — La discussion est le coeur de valeur de la Sprint Review. C’est là que remontent les incompréhensions, les besoins non exprimés et les changements de priorité qu’aucune réunion de planning ne peut anticiper. Bâcler cette partie, c’est rater l’essentiel.
Question 4 — Comment adapter la Sprint Review à un contexte hors développement informatique ?
- A) On ne peut pas — c’est un outil réservé aux équipes tech
- B) En créant un rendez-vous régulier avec les parties prenantes pour présenter les livrables et collecter des retours
- C) En remplaçant la Sprint Review par un email de reporting mensuel
- D) En utilisant uniquement la Rétrospective, qui s’adapte mieux aux contextes non-IT
✅ Bonne réponse : B — La Sprint Review se transpose dans n’importe quel contexte où une équipe livre des résultats à des parties prenantes. L’essentiel est de maintenir la boucle de feedback régulière : montrer du concret, écouter les retours, ajuster les priorités.
Question 5 — Quelle est la durée maximale recommandée pour une Sprint Review dans un sprint d’un mois ?
- A) 1 heure
- B) 2 heures
- C) 4 heures
- D) 8 heures
✅ Bonne réponse : C — Scrum recommande 4 heures maximum pour un sprint d’un mois, au prorata pour des sprints plus courts. Dépasser régulièrement cette limite est souvent le signe d’une préparation insuffisante ou d’un périmètre trop large — deux problèmes à corriger en amont.
