Sprint review Scrum : définition et bonnes pratiques 2026
- 13 juil.
- 10 min de lecture
Une sprint review est la réunion qui clôt un sprint (une période de travail de 1 à 4 semaines sur un projet). L'équipe y présente le travail réalisé sur le projet, tandis que les parties prenantes donnent leur avis. Elle dure généralement entre 1 et 4 heures, selon la durée du sprint.
Elle réunit le Product Owner, le Scrum Master, l'équipe de développement et les parties prenantes invitées. Son objectif est de vérifier que le travail réalisé répond aux objectifs du sprint, de recueillir des retours et d'ajuster les priorités pour le sprint suivant.
Sommaire de l'article :
Qu'est-ce qu'une sprint review ?
La sprint review (ou revue de sprint) est l'événement Scrum qui clôture un sprint : une période de travail de 1 à 4 semaines sur un projet. L'équipe présente l'incrément produit - ce qui a réellement été livré - et confronte ce résultat à l'objectif fixé en sprint planning.
Selon le Scrum Guide officiel, c'est le moment d'« inspecter le résultat du sprint et déterminer les adaptations futures ». Ce n'est pas une présentation à sens unique : c'est une session de travail collaborative.
Trois objectifs concrets :
Montrer, pas juste raconter.
Collecter du feedback réel, exploitable, sur le produit livré.
Ajuster le backlog en fonction de ce qui vient d'être dit.
Durée officielle : maximum 4 heures pour un sprint d'un mois. Pour un sprint de deux semaines, comptez plutôt 1 à 2 heures.
Le timebox est un plafond, pas un objectif à atteindre à tout prix. Si l'équipe a fini en 45 minutes, on s'arrête là.
Sprint review vs sprint planning : ne confondez pas les deux bouts du sprint
Le sprint planning ouvre le sprint, la sprint review le ferme. Le planning répond à « que va-t-on faire ? ». La review répond à « qu'est-ce qu'on a fait, et est-ce que ça correspond ? ».
Simple à retenir : planning = avant-match, review = bilan du match.
Sprint review vs rétrospective de sprint : le piège classique
C'est LA confusion qu'on voit le plus souvent sur le terrain, même chez des équipes qui pratiquent Scrum depuis des années.
Critère | Sprint review | Rétrospective de sprint |
Sujet | Le produit livré | La façon dont l'équipe a travaillé |
Public | Équipe + parties prenantes externes | Équipe Scrum uniquement, réunion interne |
Question centrale | « Est-ce qu'on a livré ce qu'il fallait ? » | « Comment on aurait pu mieux travailler ensemble ? » |
Timing | Juste avant la rétrospective | Juste après la review, dernier événement du sprint |
Ne fusionnez jamais les deux réunions. Une review qui dérive sur des sujets de process interne perd son public externe et casse la confiance des parties prenantes invitées.
Qui participe à une sprint review ?
Quatre catégories de participants, chacune avec un rôle précis.
Le Product Owner
Ouvre et cadre la réunion.
Rappelle l'objectif du sprint en une phrase.
Valide publiquement si chaque item répond à la Definition of Done.
Arbitre les priorités du backlog en direct, en fonction du feedback reçu.
Le Scrum Master
Garde le timing. C'est son job d'interrompre poliment une démo qui dérape.
S'assure que la réunion reste collaborative, pas accusatoire.
Note les points qui relèvent de la rétrospective et les met de côté pour plus tard.
L'équipe de développement
Fait la démo elle-même - pas seulement le Product Owner qui parle à la place des devs.
Répond aux questions techniques en direct.
Assume les items non terminés sans se justifier à outrance.
Les parties prenantes invitées
Clients, utilisateurs finaux, sponsors métier, experts métier concernés par ce qui a été livré.
Posent des questions, challengent, proposent des ajustements.
Doivent être choisies avec soin : inviter tout le monde "par précaution" est l'erreur n°3 de notre liste plus bas.
Comment se déroule une sprint review : l'agenda type minuté
Voici un agenda concret, calibré pour un sprint de 2 semaines (réunion d'environ 1 heure). Ajustez au prorata pour un sprint de 3 ou 4 semaines.
Étape | Durée | Contenu |
Accueil et cadrage | 5 min | Le PO rappelle l'objectif du sprint et l'ordre du jour |
Démo des items terminés | 20-30 min | L'équipe montre chaque item fini, en conditions réelles, pas en slides |
Feedback des parties prenantes | 15 min | Questions, réactions, suggestions d'ajustement |
Point sur les items non terminés | 5-10 min | Ce qui n'a pas été fini, pourquoi, et ce que ça implique pour le backlog |
Next steps | 10 min | Mise à jour du backlog produit, priorités pour le sprint suivant |
Pour un sprint de 4 semaines, doublez à peu près chaque bloc pour atteindre le plafond de 4 heures maximum recommandé par le Scrum Guide. Sans pour autant viser ce maximum si le contenu ne le justifie pas.
Trois règles pour que cet agenda tienne réellement :
Chronométrez chaque bloc visiblement. Un minuteur partagé à l'écran évite les dérapages silencieux.
Une démo = un item = un critère d'acceptation vérifié en direct. Pas de "je vous montrerai après".
Le feedback se note en direct, pas de mémoire après coup. Un simple tableau partagé (Confluence, Jira, ou même un doc partagé) suffit.
Éviter l'effet mouton de panurge pendant le feedback
Quand plusieurs parties prenantes assistent à la même démo, la première personne qui parle influence souvent toutes les réponses suivantes. Résultat : un feedback qui reflète l'opinion la plus bruyante dans la salle, pas l'avis réel de chacun.
La parade : après chaque démo d'item, imposez 1 à 2 minutes de réflexion silencieuse avant que quiconque prenne la parole. Chacun note son avis de son côté - sur un post-it, dans un champ Jira dédié, ou sur un tableau Miro - avant de le partager à voix haute.
Variez ensuite l'ordre de prise de parole d'un sprint à l'autre. Ne laissez pas systématiquement le sponsor le plus senior ouvrir le bal : son avis pèsera trop sur celui des autres.
Ce petit rituel change la nature du feedback recueilli. On récupère des avis contrastés, parfois contradictoires, au lieu d'un simple oui collectif poli qui ne dit rien de l'expérience réelle des utilisateurs.
Un template de sprint review prêt à réutiliser
Pas besoin de repartir de zéro à chaque sprint. Dupliquez cette structure dans une page Confluence ou un ticket Jira, et remplissez-la en direct pendant la réunion :
Objectif du sprint (une phrase) : ______
Items à démontrer : liste des tickets, avec statut Terminé / Non terminé pour chacun
Notes de feedback par item : une ligne par retour, associée à l'item concerné
Actions de suivi : qui fait quoi, avant quelle date, avec le lien vers l'item de backlog créé
Gardez ce canevas identique d'un sprint à l'autre. C'est ce qui permet de comparer les sprints entre eux et d'alimenter les métriques vues plus bas. Vous pouvez aussi télécharger ce template sprint review Atlassian
Les 5 erreurs les plus fréquentes en sprint review
On les retrouve, presque identiques, dans la majorité des équipes qu'on accompagne. Les corriger change immédiatement la qualité de la réunion.
1. Des démos interminables
Une démo doit durer quelques minutes par item, pas un quart d'heure. Symptôme classique : l'équipe navigue dans l'interface en cherchant la bonne fonctionnalité en direct devant tout le monde.
Correctif : préparez chaque démo à l'avance, avec un scénario écrit et un jeu de données propre.
2. L'absence de préparation
Une sprint review improvisée se voit tout de suite : items non testés, environnement de démo instable, personne ne sait qui présente quoi.
Correctif : un point de préparation de 15 minutes la veille, où l'équipe répartit les démos et teste l'environnement.
3. Des parties prenantes non pertinentes invitées
Inviter 15 personnes "au cas où" dilue la discussion et intimide l'équipe. Résultat : peu de vraies questions, beaucoup de silence poli.
Correctif : une liste d'invités courte et ciblée, revue à chaque sprint en fonction de ce qui a été livré.
4. Pas de définition claire de "Terminé"
Sans Definition of Done partagée, chacun a sa propre idée de ce qui compte comme "fini". On finit par montrer des demi-fonctionnalités, ce qui casse la confiance des parties prenantes.
Correctif : la Definition of Done doit être écrite, visible, et validée en équipe avant le sprint - pas inventée en direct pendant la review.
5. Pas de suivi du feedback recueilli
Le feedback est noté... puis oublié. Les parties prenantes reviennent au sprint suivant, redemandent la même chose, et perdent confiance dans le processus.
Correctif : chaque retour doit se transformer en item de backlog traçable, avec un statut visible au sprint suivant.
Comment mesurer le succès d'une sprint review
Une sprint review n'est ni bonne ni mauvaise "au feeling". Voici trois métriques concrètes à suivre sprint après sprint.
1. Taux de participation des parties prenantes
Nombre de parties prenantes invitées présentes / nombre de parties prenantes invitées. Un taux qui chute sprint après sprint est un signal d'alerte : soit les invitations ne sont plus pertinentes, soit la réunion n'apporte plus de valeur perçue.
2. Qualité du feedback collecté
Ne comptez pas juste le nombre de commentaires. Suivez le taux de feedback transformé en item de backlog actionnable dans les 48h suivant la review.
Un feedback qui reste "dans l'air" sans jamais devenir une tâche trackée ne sert à rien.
3. Taux d'items "Terminé" présentés vs prévus
Nombre d'items réellement démontrés comme finis / nombre d'items engagés en sprint planning. Un ratio qui reste durablement sous 70-80 % signale un problème en amont : surestimation en planning, dette technique non traitée, ou Definition of Done trop floue.
Suivez ces trois chiffres sur 4 à 6 sprints avant de tirer une conclusion. Un sprint isolé ne veut rien dire ; la tendance, si.
Les outils utiles pour une sprint review efficace
L'outil ne remplace jamais la préparation, mais il structure la réunion et garde une trace exploitable.
Jira
Suivi natif du sprint backlog et des items "Terminé" vs prévus.
Un modèle de revue de sprint dédié permet de préparer l'agenda et de tracer le feedback directement sur les tickets.
Utile pour calculer automatiquement le taux de complétion sprint après sprint.
Confluence
Sert à documenter les comptes-rendus de review, les décisions de backlog, et l'historique du feedback.
Pratique pour les équipes distribuées : une page par sprint, consultable de manière asynchrone.
Le bon réflexe : un outil de suivi de tickets (Jira ou équivalent) pour la traçabilité, un espace de documentation (Confluence ou équivalent) pour l'historique, et éventuellement un tableau visuel pour l'animation de la réunion elle-même.
Sprint review à distance : comment s'adapter
Une sprint review à distance ne se pilote pas comme une réunion en présentiel. L'attention se dissipe plus vite derrière un écran, et les silences gênés remplacent vite les échanges spontanés.
Trois ajustements suffisent à garder une review efficace, même à 100 % remote.
Enregistrez la démo en amont, et partagez-la avant la réunion
Plutôt que de risquer un bug live devant dix personnes en visio, enregistrez chaque démo en amont, sur 3 à 5 minutes par item. Envoyez la vidéo la veille aux parties prenantes, avec le lien vers les tickets Jira concernés.
Les parties prenantes arrivent alors préparées : elles ont déjà vu le résultat. La réunion peut alors se concentrer sur les questions et les ajustements, pas sur la découverte du produit.
Utilisez vos outils collaboratifs pour afficher le backlog en temps réel
Les mêmes outils mentionnés plus haut - Jira, Confluence, Miro - deviennent encore plus utiles à distance. Partagez l'écran sur le sprint backlog dans Jira pendant la discussion, pour que tout le monde voie exactement de quel item on parle.
Un tableau Miro projeté en simultané permet de recueillir le feedback en direct, sous forme de post-its virtuels classés par item - un bon moyen de garder la logique de réflexion individuelle avant partage vue plus haut. Confluence garde ensuite la trace écrite de la session, consultable de manière asynchrone par ceux qui n'ont pas pu se connecter.
Réduisez le timebox : visez 90 minutes, pas le plafond de 4 heures
En présentiel, viser le plafond de 4 heures recommandé par le Scrum Guide reste parfois justifié pour un sprint d'un mois. En visioconférence, c'est rarement une bonne idée : au-delà de 90 minutes, la concentration chute nettement, et le feedback perd en qualité.
Pour un sprint de 2 semaines à distance, visez plutôt 45 à 60 minutes. Pour un sprint de 4 semaines, plafonnez à 90 minutes et coupez la réunion en deux sessions si le contenu à présenter dépasse ce format.
Teolia, votre partenaire pour structurer vos rituels agiles
Une sprint review qui tourne mal, ce n'est presque jamais un problème d'outil. C'est un problème de rituel mal cadré : pas de Definition of Done partagée, pas de préparation, mauvaises personnes dans la salle.
Nos 190 consultants interviennent au quotidien sur des projets agiles, chez des clients de l'industrie, de la finance et du secteur public. Plus de 430 projets livrés depuis 2014, avec une constante : on ne vient pas juste poser un cadre théorique, on s'assied dans la réunion avec vos équipes.
Nos formations Agile Atlassian ne se limitent pas à expliquer ce qu'est une sprint review sur un slide. Nos consultants observent vos rituels existants, identifient ce qui coince concrètement - souvent l'une des 5 erreurs listées plus haut - et corrigent avec vos Scrum Masters et Product Owners, en conditions réelles.
Nous intervenons également pour accompagner tous vos projets de transformation digitale : Que ce soit en data et ia, cybersécurité, Devops et Cloud ou gestion de projet agile
FAQ
Combien de temps doit durer une sprint review ?
Maximum 4 heures pour un sprint d'un mois, selon le Scrum Guide officiel. Pour un sprint de 2 semaines, comptez 1 à 2 heures.
Le timebox est un plafond : arrêtez la réunion dès que son objectif est atteint, même en avance.
Qui anime une sprint review ?
Le Product Owner ouvre et cadre la réunion, mais l'équipe de développement fait elle-même la démo de son travail. Le Scrum Master, lui, garde le timing et veille à ce que la réunion reste collaborative.
Quelle est la différence entre sprint review et rétrospective de sprint ?
La sprint review porte sur le produit livré et implique des parties prenantes externes. La rétrospective porte sur la façon dont l'équipe a travaillé ensemble, et reste une réunion interne à l'équipe Scrum.
Les deux se tiennent l'une après l'autre, jamais fusionnées.
Faut-il faire une sprint review même si rien n'est terminé ?
Oui. Montrez ce qui a été fait, même partiel, et expliquez pourquoi certains items ne sont pas finis.
C'est justement l'occasion d'ajuster le backlog et d'aligner les attentes des parties prenantes avant le sprint suivant.
Quels outils utiliser pour une sprint review à distance ?
Jira pour suivre les items du sprint et la Definition of Done, Confluence pour documenter le compte-rendu, et un outil de visioconférence avec partage d'écran pour la démo elle-même. Un tableau collaboratif type Miro peut compléter l'animation, sans remplacer le suivi structuré des tickets.
Qui doit être invité à une sprint review ?
L'équipe Scrum au complet (Product Owner, Scrum Master, développeurs) plus des parties prenantes choisies pour leur pertinence sur ce qui a été livré ce sprint-là : clients concernés, sponsor métier, expert du domaine.
Évitez les invitations "par défaut" qui diluent la discussion.
Commentaires