Le malentendu le plus répandu en Scrum
La scène est familière: l’équipe de développement projette son écran et déroule les fonctionnalités livrées au cours du sprint tandis que les parties prenantes hochent la tête en silence. Quelques questions polies, un “bon travail” général, puis chacun retourne à son bureau. La Sprint Review est terminée en vingt minutes.
Ce scénario, aussi courant soit-il, repose sur un malentendu fondamental: la Sprint Review n’est pas une démonstration, comme le Scrum Guide le formule sans ambiguïté. C’est une working session, une séance de travail dont l’objectif est d’inspecter le résultat du sprint et de décider des adaptations à apporter. La différence est considérable, car elle transforme un exercice de communication descendant en un moment de prise de décision collaborative.
Ce qui ne va pas avec le format “démo”
Quand la Sprint Review se réduit à une présentation, plusieurs dysfonctionnements s’installent. Les parties prenantes adoptent un rôle de spectateur: elles regardent sans toucher le produit, sans le questionner en profondeur, sans confronter ce qu’elles voient à leurs besoins réels. Les développeurs, de leur côté, se retrouvent dans une posture d’examen: ils montrent ce qu’ils ont fait en espérant une validation, et l’échange se limite à des approbations de surface.
Un symptôme particulièrement révélateur permet de diagnostiquer le problème: si le Product Backlog (la liste priorisée de tout ce qui reste à faire sur le produit) ne change pas après une Sprint Review, c’est que la séance n’a pas rempli sa fonction. Un backlog qui reste identique d’un sprint à l’autre signifie qu’aucun apprentissage n’a été intégré et qu’aucune priorité n’a été réévaluée à la lumière de ce qui vient d’être construit.
Scrum.org identifie d’autres signaux d’alerte dans son analyse de ce mythe: l’usage de diapositives PowerPoint à la place du logiciel fonctionnel, l’absence des vrais utilisateurs finaux dans la salle, ou encore le fait que le Product Owner se contente de valider plutôt que de piloter la discussion. Chacun de ces signes indique que l’événement a glissé vers la présentation et s’est éloigné de sa raison d’être.
Ce que le Scrum Guide attend réellement
L’objectif officiel de la Sprint Review tient en deux mots: inspect and adapt. L’équipe Scrum et les parties prenantes examinent ensemble ce qui a été accompli pendant le sprint, mais aussi ce qui a changé dans le contexte du projet: évolutions du marché, contraintes budgétaires, nouvelles priorités stratégiques, capacité de l’équipe pour la période à venir.
Le Product Owner joue un rôle central dans cette dynamique. Lors d’une Sprint Review bien conduite, il agit en décideur: c’est le moment de confirmer l’orientation du prochain sprint, d’ajuster le périmètre, ou même de pivoter si les retours l’exigent. Les parties prenantes ne se contentent pas de commenter ce qu’on leur montre; elles proposent des objectifs pour le sprint suivant et participent à la priorisation. Cette distinction entre “montrer” et “décider ensemble” fait de la Sprint Review un levier de pilotage produit, pas un simple point d’avancement.
Comment transformer la séance en vrai travail collectif
Plusieurs pratiques concrètes permettent de sortir du format démo. La plus efficace consiste à faire tester le produit directement par les parties prenantes pendant la séance. Plutôt que de projeter un écran unique, on distribue des tablettes ou des accès directs pour que chaque participant explore l’incrément (la portion de produit livrable à la fin du sprint) par lui-même. Le feedback qui en résulte est incomparablement plus riche que celui d’une observation passive, parce que l’utilisateur découvre les frictions et les opportunités en manipulant le produit.
Une autre approche consiste à séparer la validation formelle de la Sprint Review. Les acceptations techniques peuvent se faire avant la séance, afin que le temps collectif soit consacré à l’exploration et à la prise de décision plutôt qu’à la vérification de conformité. Si la Sprint Review devient le moment où l’on vérifie que les critères d’acceptation sont respectés, elle se transforme inévitablement en porte de livraison, ce qui n’est pas son rôle.
La facilitation active fait aussi une différence majeure. Poser explicitement la question “quel serait l’objectif le plus utile pour le prochain sprint?” à chaque partie prenante transforme la dynamique: les participants passent du rôle de spectateur à celui de contributeur, et le Product Owner obtient des données concrètes pour alimenter la planification du sprint suivant.
Le test qui ne trompe pas
La prochaine fois que vous sortez d’une Sprint Review, posez-vous une seule question: le Product Backlog a-t-il changé? Si des éléments ont été ajoutés, retirés ou repriorisés en fonction de ce que la séance a révélé, l’événement a fonctionné. Si le backlog est resté identique, vous avez assisté à une démo, pas à une séance de travail. Comme le souligne un article de Scrum.org consacré au rôle du Product Owner dans la Sprint Review, c’est à cette personne qu’il revient de créer les conditions pour que cette transformation ait lieu, en préparant des questions ouvertes, en invitant les bons interlocuteurs et en structurant la séance autour de décisions à prendre plutôt que de résultats à présenter.