Cette page rassemble trois Sprint Review examples concrets et complets (application bancaire, plateforme e-commerce, application mobile), avec à chaque fois le Sprint Goal, l'Increment réalisé, le feedback obtenu des stakeholders, les décisions prises et la mise à jour du Product Backlog. S'y ajoutent une analyse détaillée, des schémas, une checklist, des erreurs fréquentes et des questions PSM I corrigées.
Sprint Review : rappel rapide
La Sprint Review est l'avant-dernier événement du Sprint Scrum. Sa raison d'être : inspecter l'Increment produit et adapter le Product Backlog si besoin. C'est l'unique événement Scrum où les stakeholders sont explicitement invités.
Sa timebox maximale est de 4 heures pour un Sprint d'un mois (à proratiser). Elle se conclut par un Product Backlog mis à jour, qui alimentera le Sprint Planning suivant.
Pourquoi s'appuyer sur des exemples concrets ?
Le Scrum Guide est volontairement minimaliste : 13 pages pour décrire tout le framework. C'est sa force, mais aussi sa principale difficulté pour les équipes qui débutent. Un Sprint Review example bien construit apporte ce que la théorie ne donne pas :
- Une incarnation : un vrai Sprint Goal, des fonctionnalités nommées, du feedback authentique, des décisions tracées.
- Une mécanique visible : on voit comment la démo, le feedback et l'adaptation du Product Backlog s'enchaînent.
- Des points de repère : combien de stakeholders, quelle durée réelle, quel niveau de feedback à attendre.
- Une base de comparaison avec votre propre Sprint Review : « pourquoi la nôtre est-elle si différente ? » est une excellente question d'amélioration continue.
Flux de la Sprint Review
Exemple n°1 — Sprint Review d'une application bancaire
Contexte : une banque en ligne vient de terminer le Sprint #42, dédié au virement instantané SEPA. Scrum Team : 1 Product Owner, 1 Scrum Master, 5 Developers. Sprint de 2 semaines. Sprint Review en visioconférence, durée 2 h.
Sprint Goal
« Permettre à un client particulier de réaliser un virement instantané SEPA de bout en bout depuis son espace web sécurisé, avec une exécution traçable et conforme. »
Increment réalisé
| Élément | État | Demo |
|---|---|---|
| Initiation du virement instantané (web) | Done | Démo live sur compte de test |
| Validation OTP (3DS interne) | Done | Démo live avec mobile de test |
| Trace back-office conformité | Done | Démo écran back-office |
| Notification temps réel du statut | Done | Démo live web + push mobile |
| Bénéficiaires favoris (stretch) | Not Done | Non présenté — reporté |
Déroulement de la Sprint Review
- 0–10 min : accueil par le Scrum Master, rappel du Sprint Goal et de l'agenda. Le PO présente les stakeholders présents (4 personnes du métier paiements, 1 sponsor exécutif, 2 testeurs internes).
- 10–40 min : démonstration live sur un environnement de pré-production. Le Developer back-end exécute un virement de A à Z (initiation → OTP → exécution → notification).
- 40–70 min : feedback structuré. Le PO pose deux questions ouvertes : « Qu'est-ce qui manque pour qu'un client réel utilise cela demain ? » et « Quels cas n'avons-nous pas couverts ? ».
- 70–90 min : adaptation du Product Backlog en direct (visible à l'écran).
- 90–120 min : discussion stratégique sur le Sprint suivant et alignement avec le Product Goal trimestriel.
Feedback obtenu
- « Le parcours est fluide, mais l'utilisateur ne voit pas immédiatement les frais (0 €) — risque de méfiance. »
- « Le libellé OTP est trop technique : code 3DS interne. À simplifier en code de sécurité. »
- « Manque un lien direct depuis le tableau de bord, pas seulement depuis le menu Virements. »
- « Côté conformité : la trace doit aussi inclure l'IP source pour les audits TIPS. »
Décisions prises
- 3 nouvelles User Stories ajoutées au Product Backlog (affichage des frais, libellé OTP, lien dashboard).
- 1 spike ajouté pour étudier l'enrichissement de la trace conformité (IP source).
- Décision PO : le Sprint #43 conservera le thème Virement instantané pour absorber le feedback prioritaire.
- Story Bénéficiaires favoris repriorisée plus haut dans le Product Backlog.
Product Backlog mis à jour
| Item | Action | Priorité |
|---|---|---|
| PBI-110 — Affichage frais 0 € sur l'écran d'initiation | Ajouté | Top du Backlog |
| PBI-111 — Renommer « code 3DS interne » en « code de sécurité » | Ajouté | Top du Backlog |
| PBI-112 — Lien direct depuis dashboard | Ajouté | Sprint suivant |
| SPK-008 — Spike IP source dans trace TIPS | Ajouté | Sprint suivant |
| PBI-107 — Bénéficiaires favoris | Repriorisée | Sprint suivant |
Exemple n°2 — Sprint Review d'une plateforme e-commerce
Contexte : une plateforme e-commerce mode termine un Sprint dédié à la réduction de l'abandon de panier (checkout simplifié + paiement express Apple Pay / Google Pay). Scrum Team : 1 PO, 1 SM, 4 Developers full-stack. Sprint de 2 semaines. Sprint Review de 1 h 30.
Sprint Goal
« Réduire l'abandon de panier en simplifiant le parcours de checkout et en proposant le paiement express Apple Pay / Google Pay. »
Increment réalisé
| Élément | État | Demo |
|---|---|---|
| Refactor du composant Panier | Done | Pas démontré (technique) |
| Paiement Apple Pay (iOS Safari) | Done | Démo live sur iPhone |
| Paiement Google Pay (Android Chrome) | Done | Démo live sur Pixel |
| Parcours checkout simplifié 3 étapes → 1 | Done | Démo live desktop + mobile |
| Gestion d'erreurs CB / 3DS | Done | Démo avec carte de test refusée |
| Analytics abandon par étape | Done | Démo tableau de bord |
Feedback obtenu
- Sponsor marketing : « Le checkout est splendide, mais on ne voit pas la promesse de livraison sur la dernière étape. Risque d'abandon résiduel. »
- Responsable customer care : « Apple Pay impeccable. Google Pay : 1 client sur 4 voit un message technique en cas d'échec — à reformuler. »
- Data analyst : « Le tracking analytics est en place, mais il manque le segment retour utilisateur. Sans ça, on ne pourra pas A/B-tester. »
- Designer produit : « Le bouton "Payer" est trop bas sur mobile petit écran (iPhone SE). »
Décisions prises
- Ajout d'une story « afficher délai de livraison sur l'étape de paiement » — sprint suivant.
- Bug ticket prioritaire : message d'erreur Google Pay à reformuler.
- Story « segmentation analytics retour utilisateur » ajoutée et priorisée.
- Validation : la plateforme va lancer un A/B test public sur 10 % du trafic dès la semaine suivante.
Exemple n°3 — Sprint Review d'une application mobile
Contexte : une startup de coaching sportif termine un Sprint d'onboarding (création de compte → premier programme personnalisé → première séance). Scrum Team : 1 PO, 1 SM, 3 Developers mobile. Sprint d'1 semaine. Sprint Review de 1 h, en présentiel.
Sprint Goal
« Permettre à un utilisateur de créer un compte, choisir son programme d'entraînement et recevoir sa première séance personnalisée. »
Increment réalisé
| Élément | État | Demo |
|---|---|---|
| Création de compte (email + mot de passe) | Done | Démo live iOS + Android |
| Choix d'objectif (perte / masse / endurance) | Done | Démo live |
| Algorithme programme personnalisé (back-end) | Done | Démo via app |
| Affichage du premier programme | Done | Démo live iOS + Android |
| Lancement et clôture de la première séance | Done | Démo live |
| Partage social (initialement prévu) | Coupé | Hors périmètre — préservé Sprint Goal |
Feedback obtenu
- Investisseur (présent en observateur) : « Le parcours est plus fluide que celui des concurrents que j'ai testés cette semaine. »
- Coach sportif (stakeholder métier) : « L'algorithme est correct mais ne prend pas en compte la blessure. C'est un déclencheur de churn majeur. »
- Utilisatrice bêta : « J'ai mis 2 minutes à comprendre comment lancer ma première séance. Le bouton "Commencer" devrait être plus saillant. »
- Designer : « OK pour le MVP. Iconographie à uniformiser au prochain Sprint. »
Décisions prises
- Nouvelle User Story : « prise en compte de la blessure dans le questionnaire d'onboarding » — top de Backlog.
- Bug visuel : bouton « Commencer » à rendre plus proéminent — top de Backlog.
- Story « partage social » non réintégrée au Sprint suivant (reste dans le Backlog, plus bas).
- Démarrage d'une bêta privée à 50 utilisateurs validée par le PO et le sponsor.
Analyse détaillée — pourquoi ces Sprint Reviews fonctionnent
Les trois exemples ont quelques caractéristiques communes qui expliquent leur efficacité. Cette section les analyse pour vous permettre de les transposer à votre propre contexte.
| Critère | Pourquoi ça compte |
|---|---|
| Sprint Goal explicite rappelé en ouverture | Aligne tout le monde sur l'angle d'inspection. |
| Démonstration sur environnement réel | Évite l'effet « slideware » et révèle les vrais comportements. |
| Stakeholders pertinents présents | Pas de feedback utile sans la bonne audience. |
| Feedback structuré par questions ouvertes | Évite les « Ça vous plaît ? » qui ne produisent rien. |
| Adaptation du Product Backlog visible en direct | Rend la valeur de l'événement tangible. |
| Distinction Done / Not Done assumée | Renforce la transparence et la confiance. |
| Décisions tracées et partagées après la Review | Évite l'effet « réunion sans suite ». |
Bonne Sprint Review vs Mauvaise Sprint Review
| Dimension | Bonne Sprint Review | Mauvaise Sprint Review |
|---|---|---|
| Audience | Stakeholders cibles, choisis selon le Sprint Goal | Toute l'organisation invitée par habitude |
| Démo | Live, sur environnement réel, avec données réalistes | Slideshow ou enregistrement vidéo |
| Sprint Goal | Rappelé, utilisé comme angle d'inspection | Jamais évoqué |
| Feedback | Questions ouvertes ancrées dans l'usage | « Avez-vous des retours ? » suivi de silence |
| Product Backlog | Mis à jour visiblement pendant l'événement | « On en discutera plus tard » |
| Ton | Collaboratif, exploratoire, transparent | Cérémonial, défensif, marketing |
| Sortie | Décisions tracées + Product Backlog adapté | Sentiment vague d'avoir fait une réunion |
Feedback utile vs feedback inutile
| Type | Feedback utile | Feedback inutile |
|---|---|---|
| Forme | « Pour un client qui X, il manque Y » | « C'est bien / c'est moche » |
| Ancrage | Cas d'usage précis | Avis général |
| Conséquence | Génère une User Story actionnable | Génère une discussion sans suite |
| Source | Stakeholder concerné, en condition réaliste | Personne déconnectée de l'usage |
| Traçabilité | Item ajouté au Product Backlog | Notes oubliées dans un Slack |
Mauvais exemples & erreurs fréquentes
| Erreur | Conséquence | Correction |
|---|---|---|
| La Sprint Review devient une présentation marketing | Feedback de complaisance, aucune décision réelle. | Démo live, pas de slides, posture exploratoire affichée par le PO. |
| On présente du travail non-Done | Confusion sur ce qui est livrable, transparence érodée. | Strict respect de la Definition of Done. Le « presque fini » n'existe pas. |
| Aucun stakeholder présent | Aucun feedback externe, valeur de l'événement nulle. | Le PO invite proactivement les stakeholders pertinents pour le Sprint Goal courant. |
| Le Sprint Goal n'est pas évoqué | Inspection sans angle, décisions désalignées. | Rappel du Sprint Goal en ouverture, utilisé comme grille de lecture. |
| Pas de mise à jour du Product Backlog | Feedback perdu, événement réduit à une démo. | PO met à jour le Backlog visiblement, en séance. |
| On annule la Sprint Review parce que « le Sprint a raté » | Perte de l'inspection collective, opacité. | La Sprint Review a toujours lieu. Si rien n'est Done, on inspecte la situation. |
| Sprint Review > timebox | Fatigue, décisions de mauvaise qualité. | SM cadre le temps. La densité prime sur l'exhaustivité. |
| Réunion à sens unique (Scrum Team parle, stakeholders écoutent) | Aucune adaptation, événement transformé en reporting. | Forcer le dialogue par des questions ouvertes, alterner démo et discussion. |
Bonnes pratiques
Checklist complète d'une Sprint Review réussie
Avant l'événement
- ☐ Sprint Goal rappelé et écrit visiblement.
- ☐ Liste des stakeholders pertinents validée par le PO.
- ☐ Environnement de démo prêt (données réalistes, comptes de test).
- ☐ Increment vérifié contre la Definition of Done.
- ☐ Agenda léger partagé (5 sections, pas 15).
Pendant l'événement
- ☐ Rappel du Sprint Goal en ouverture (5 minutes max).
- ☐ Démo live de chaque élément Done.
- ☐ Distinction explicite Done / Not Done.
- ☐ Questions ouvertes posées aux stakeholders.
- ☐ Notes prises et feedback structuré.
- ☐ Adaptation du Product Backlog en direct.
- ☐ Alignement final sur les prochaines étapes (cap, pas plan).
Après l'événement
- ☐ Note récapitulative (5 lignes) partagée avec stakeholders.
- ☐ Product Backlog mis à jour et publié.
- ☐ Sprint Retrospective enchaînée (même journée idéalement).
Questions PSM I typiques sur la Sprint Review
Question 1
Qui décide de l'adaptation du Product Backlog à l'issue de la Sprint Review ?
- A. Les stakeholders, par vote.
- B. Le Scrum Master.
- C. Le Product Owner.
- D. Le Scrum Team par consensus.
Réponse : C. Le Product Owner est responsable de la gestion du Product Backlog. Il intègre le feedback collecté, mais c'est lui qui décide.
Question 2
Quelle est la timebox maximale d'une Sprint Review pour un Sprint d'un mois ?
- A. 2 heures.
- B. 4 heures.
- C. 8 heures.
- D. Aucune limite officielle.
Réponse : B. 4 heures maximum, à proratiser pour les Sprints plus courts.
Question 3
Le Sprint Goal n'a pas été atteint. Que faire de la Sprint Review ?
- A. L'annuler et passer directement à la Retrospective.
- B. La maintenir et inspecter ce qui a été produit.
- C. La reporter au Sprint suivant.
- D. La transformer en réunion de cadrage avec le sponsor.
Réponse : B. La Sprint Review a toujours lieu. L'inspection est précisément ce qui permet d'adapter.
Question 4
Quels participants sont obligatoires à la Sprint Review ?
- A. Uniquement le Scrum Team.
- B. Le Scrum Team et les key stakeholders invités par le Product Owner.
- C. Toute l'organisation.
- D. Le Scrum Master uniquement, en tant que facilitateur.
Réponse : B. La Sprint Review est l'unique événement Scrum où les stakeholders sont explicitement attendus.
Question 5
Peut-on présenter du travail non-Done en Sprint Review ?
- A. Oui, pour montrer la progression.
- B. Non, seul l'Increment Done est inspecté en tant que livrable.
- C. Oui, mais uniquement si le PO donne son accord.
- D. Oui, à condition que le Scrum Master le valide.
Réponse : B. Le travail non-Done n'est pas un Increment au sens Scrum.
FAQ — Sprint Review Example
Les 11 questions ci-dessous synthétisent les interrogations les plus fréquentes autour d'un Sprint Review example. Elles sont également exposées en JSON-LD pour aider Google et les moteurs IA à comprendre le contenu de cette page.