Déroulé de sprint review pour décider du backlog

Si votre sprint review est devenue un diaporama à sens unique où le Product Owner fait défiler des captures d'écran pendant que les parties prenantes consultent discrètement leurs e-mails, vous avez un point d'avancement dont la participation baisse à chaque fois. Le schéma est assez prévisible pour que la deuxième sprint review montre généralement si les parties prenantes seront encore dans la salle à la sixième.

La solution est surtout structurelle. Vous changez la finalité de la réunion, puis vous changez le déroulé pour que la salle soit obligée de trancher. Ce guide couvre la finalité, un déroulé minuté, qui parle à quel moment, comment recueillir du feedback sans être submergé de demandes de fonctionnalités, et ce que fait le Product Owner ensuite.

Pourquoi les parties prenantes cessent de venir aux sprint reviews

Les parties prenantes se comportent ici de façon rationnelle. Quand une review est une visite guidée scénarisée d'écrans terminés, sans aucune question ouverte sur la table, elles en concluent, à juste titre, que leur présence ne change rien. D'abord elles envoient un délégué, puis elles déclinent, et finalement l'invitation disparaît de leur agenda.

Voici un cas typique. Une équipe produit présente un parcours de paiement terminé pendant 45 minutes sans jamais poser une seule question aux parties prenantes. Au troisième sprint, seul le manager du PO participe encore, et il répond à des messages Slack tout du long. C'est l'un des anti-patterns les plus courants de la sprint review : l'équipe fait une démo, qui montre ce qui a été construit, et l'appelle une review, qui inspecte ce qui a été construit et décide de ce qui doit changer ensuite.

L'environnement de réunions dans son ensemble aggrave la situation. Le Work Trend Index de Microsoft indiquait en 2022 que le nombre de réunions hebdomadaires de l'utilisateur moyen de Teams avait fortement augmenté depuis le début de la pandémie, sans aucun signe d'inversion de la tendance. Quand les agendas se remplissent, les gens abandonnent d'abord les réunions qui ressemblent à des points d'information passifs. Une démo est à peu près le point d'information le plus passif qui soit, et quiconque pourrait lire les notes de version à la place finira par le faire.

À quoi sert une sprint review selon le Scrum Guide

Le Scrum Guide 2020 est bref et clair sur ce point. L'objectif de la Sprint Review est d'inspecter le résultat du Sprint et de déterminer les adaptations futures. La Scrum Team présente les résultats aux principales parties prenantes, les progrès vers l'objectif de produit sont discutés, et les participants collaborent sur la suite. Le Product Backlog peut être ajusté pour saisir de nouvelles opportunités.

La phrase la plus utile pour les équipes est celle-ci : la Sprint Review est une séance de travail, et la Scrum Team doit éviter de la réduire à une présentation. L'incrément est l'entrée de la conversation. La sortie est une décision sur le backlog.

Le même raisonnement vaut du côté des parties prenantes. La review existe parce que les personnes qui utiliseront, financeront ou soutiendront le produit savent des choses que l'équipe ignore, et le backlog devrait évoluer une fois qu'elles ont vu un logiciel fonctionnel.

Côté durée, le Scrum Guide plafonne l'événement à quatre heures pour un Sprint d'un mois et attend des Sprints plus courts qu'ils y consacrent proportionnellement moins de temps. Pour un Sprint de deux semaines, cela signifie deux heures au maximum. En pratique, 60 à 90 minutes suffisent généralement. Un plafond fixe, disons 75 minutes, fonctionne mieux lorsque l'équipe le traite comme une contrainte de conception qui l'oblige à couper la narration et à protéger la discussion.

Sprint review, rétrospective et sprint planning : les différences

Ces trois événements sont souvent confondus, ce qui fait perdre beaucoup de temps aux parties prenantes.

Événement	Ce qui est inspecté	Qui participe	Ce qui change
Sprint Review	L'incrément produit et le contexte marché ou business	La Scrum Team et les principales parties prenantes	Le Product Backlog
Sprint Retrospective	La façon dont l'équipe travaille : processus, outils, collaboration	La Scrum Team uniquement	La façon de travailler de l'équipe
Sprint Planning	Le backlog adapté et la capacité de l'équipe	La Scrum Team, avec d'autres personnes invitées si besoin	Le Sprint Backlog du Sprint suivant

La Review examine le produit. La Retrospective examine l'équipe. Le Planning reprend ce que la Review a décidé et le transforme en engagement pour le Sprint suivant, ce qui boucle la boucle.

Un débordement courant va de la Retrospective vers la Review. Pendant la démo, un développeur mentionne que le pipeline de déploiement est trop lent, deux autres renchérissent, et soudain six parties prenantes assistent à un débat sur l'outillage interne sur lequel elles ne peuvent pas agir. Cette conversation a sa place dans la Retrospective. Si vos rétros traitent mal ces sujets, notre article Sprint Retrospective : le guide complet de l'animateur détaille le format. Le débordement inverse existe aussi : une équipe passe la moitié de sa Retrospective à rejouer les priorités du backlog, ce qui relève de la décision du PO et aurait dû être réglé avec les parties prenantes dans la salle.

Un déroulé de sprint review en 60-90 minutes

Ce déroulé est prévu pour un Sprint de deux semaines avec cinq à douze parties prenantes. Il dure environ 85 minutes, ce qui laisse une petite marge.

• Minutes 0-5 : objectif de Sprint et contexte. Le PO énonce l'objectif et dit clairement s'il a été atteint, partiellement atteint ou manqué. Une phrase sur ce qui a changé côté business depuis la dernière review.
• Minutes 5-35 : présentation du logiciel fonctionnel. Uniquement les éléments qui satisfont la Definition of Done, montrés en direct dans un environnement réel. Pas de diapositives, pas de maquettes de travail inachevé.
• Minutes 35-60 : feedback structuré des parties prenantes, à l'aide de questions précises (voir plus bas). Chaque élément est noté de façon visible au moment où il est soulevé.
• Minutes 60-80 : impact sur le backlog. Ce qui est ajouté, repriorisé ou supprimé à la suite de ce que nous venons d'entendre. Le PO tranche ou indique quand il tranchera.
• Minutes 80-85 : récapitulatif des décisions et des responsables, lu à voix haute depuis l'écran partagé.

Pour une version de 60 minutes, réduisez la présentation à 20 minutes et le bloc de feedback à 15. Ne réduisez jamais la séquence sur l'impact pour le backlog : c'est elle qui fait de cette réunion une review.

L'Atlassian Agile Coach décrit une review type comme s'ouvrant sur un aperçu de l'objectif de Sprint, suivi des démonstrations. Cet ordre a une raison pratique : si l'objectif a été manqué, le dire dès la deuxième minute change la manière dont les gens regardent les 30 minutes suivantes. Ils cherchent ce qui a été appris au lieu de noter le degré de finition. Mike Cohn, chez Mountain Goat Software, plaide pour des reviews informelles et légères, sans diapositives soignées. Les diapositives signalent une « présentation », et les parties prenantes réagissent en se calant dans leur fauteuil.

Un ajout utile à toute review est une section visible « Décisions prises » sur l'écran partagé, remplie en direct. Sans elle, les équipes ont tendance à revenir au simple « montrer et raconter », car rien dans la structure n'incite quiconque à trancher. Vous pouvez conserver ce déroulé comme modèle réutilisable dans Workshop Weaver, de sorte que le bloc de décision et son minutage soient intégrés à chaque Sprint au lieu d'être reconstruits de mémoire.

Qui parle à quel moment

Des rôles clairs évitent qu'une réunion de 12 personnes devienne un monologue du PO ou une foire d'empoigne.

Les développeurs présentent leur propre travail

Le Scrum Guide 2020 ne désigne pas de présentateur, mais les éditions précédentes confiaient à l'équipe de développement la démonstration du travail qu'elle avait terminé, et cela reste le meilleur choix par défaut. Quand trois développeurs différents montrent chacun la partie qu'ils ont construite, les parties prenantes obtiennent des réponses directes à leurs questions techniques et commencent à faire confiance à l'équipe dans son ensemble. Quand le PO présente tout au nom de l'équipe, chaque question difficile se transforme en « Je vérifie avec les développeurs et je reviens vers vous », et la réunion perd une grande partie de sa valeur.

Le Product Owner ouvre, écoute et conclut

Le PO cadre l'objectif de Sprint au début et cadre les implications pour le backlog à la fin. Entre les deux, son rôle est d'écouter et de creuser. Un PO qui parle plus d'environ un tiers de la réunion est généralement en train de défendre l'incrément au lieu d'apprendre des réactions qu'il suscite.

Le Scrum Master veille au time-box et à l'équilibre

Le Scrum Master anime. Cela signifie tenir les temps, veiller à ce que la partie prenante la plus bruyante ne fixe pas le backlog à force de décibels, et renvoyer vers la Retrospective les sujets de processus ou relationnels dès qu'ils surgissent. Une phrase simple suffit : « C'est une question de fonctionnement de l'équipe, je l'ai notée pour la rétro. Revenons au parcours de paiement. »

Recueillir le feedback des parties prenantes sans déluge de demandes de fonctionnalités

« Qu'en pensez-vous ? » est une mauvaise question pour une sprint review. Elle appelle des avis dispersés et des listes de souhaits, et vous vous retrouvez avec 14 demandes de fonctionnalités et aucune décision.

Des questions plus ciblées produisent un feedback exploitable :

• Qu'est-ce qui vous a surpris dans ce que vous venez de voir ?
• Que manque-t-il qui vous empêcherait de l'utiliser dès aujourd'hui ?
• Que changeriez-vous avant que nous le mettions devant des clients ?
• Quelque chose a-t-il changé de votre côté depuis le dernier Sprint qui devrait modifier nos priorités ?

Posez une question à la fois et laissez 60 secondes de silence pour écrire avant que quiconque prenne la parole. À distance, cela veut dire un tableau partagé. En salle, des post-it. L'étape d'écriture silencieuse empêche la première voix senior d'ancrer tout le monde.

Appliquez ensuite une règle ferme : noter maintenant, prioriser plus tard. Chaque retour devient une carte dans une colonne « Feedback de la review » de l'outil de backlog. Rien n'est estimé, chiffré ni engagé pendant la Review. Ce travail a lieu lors de l'affinage, et notre article Déroulé de l'affinage du backlog explique comment transformer ces cartes brutes en éléments estimés et prêts. Sans cette règle, la Review devient une séance de planification improvisée et dépasse son time-box à chaque Sprint.

Quand vous avez besoin d'une lecture rapide des retours qui comptent le plus, un tableau maintenant/ensuite/plus tard ou un tour de vote par points permet à la salle d'exprimer ses priorités en deux minutes. Le PO reste maître de l'ordre du backlog ; le vote est un élément d'information. Si vous utilisez le vote, lisez comment utiliser le vote par points sans tomber dans la pensée de groupe, car une salle de parties prenantes qui regarde son VP placer ses points en premier copiera le VP.

Ce que fait le Product Owner du résultat

Les éditions précédentes du Scrum Guide décrivaient le résultat de la Sprint Review comme un Product Backlog révisé présentant les éléments probables du Sprint suivant. La formulation de 2020 est plus souple, mais la tâche n'a pas changé. Le PO traduit la conversation en changements concrets et ordonnés du backlog sous un jour ou deux. Les promesses orales faites dans la salle ne suffisent pas. Si une partie prenante entend « oui, nous allons regarder ça » et ne revoit jamais l'élément, elle apprend que la réunion est du théâtre.

La pratique qui contribue le plus à faire revenir les parties prenantes est de boucler la boucle de façon visible. Ouvrez chaque review par une courte séquence « La dernière fois, vous nous avez dit » : trois retours issus des reviews précédentes et ce qu'il est advenu de chacun : livré, planifié ou refusé avec une raison. Le refus compte, car les parties prenantes peuvent vivre avec un non. Ce qui les fait fuir, c'est de ne rien entendre.

Le backlog adapté alimente ensuite directement le Sprint Planning suivant. Si la planification a lieu le même après-midi ou le lendemain matin, l'équipe choisit son travail à la lumière de ce que les parties prenantes viennent de dire, au lieu de planifier à partir d'un backlog qui a déjà deux semaines de retard.

Les réflexes d'animation qui en font une réunion de décision

Quelques réflexes distinguent les reviews qui restent utiles de celles qui se dégradent.

Envoyez une note préparatoire 24 heures avant. Une demi-page : ce qui était prévu, ce qui est fait, ce qui ne l'est pas, et les deux ou trois questions ouvertes sur lesquelles vous voulez l'avis des parties prenantes. Cela sort la narration de la réunion et laisse aux parties prenantes le temps de se forger un avis. Les questions ouvertes indiquent aussi à chacun pourquoi sa présence à lui est nécessaire.

Désignez un responsable de la décision pour chaque point ouvert à la clôture. « Nous allons réfléchir à la fonction d'export » est une discussion. « Priya décide d'ici jeudi si l'export passe avant la recherche » est une décision. Lisez la liste à voix haute avant que les gens partent.

Mesurez la bonne chose. La Sprint Review existe pour inspecter l'incrément et adapter le backlog : mesurez donc l'adaptation. Un chiffre utile à suivre d'un sprint à l'autre : les éléments du backlog ajoutés, repriorisés ou supprimés en conséquence directe de la Review. S'il tend vers zéro sur trois Sprints, considérez-le comme la preuve que la réunion a glissé de nouveau vers le mode démo et repensez le bloc de feedback. La participation et la finition de la démo vous apprennent très peu.

Trois événements, une seule boucle inspection-adaptation

La Sprint Review est la seule réunion récurrente où le backlog a légitimement le droit de changer devant les personnes qu'il concerne le plus. Concevez le déroulé autour de ce changement : ouvrez sur l'objectif de Sprint, ne montrez que le travail terminé, posez des questions ciblées et réservez 15 à 20 minutes aux décisions sur le backlog avec des responsables nommés.

Reliez-la ensuite aux deux autres événements. Les problèmes de processus qui apparaissent pendant la Review vont à la Retrospective, et notre article Sprint Retrospective : le guide complet de l'animateur explique comment mener cette conversation. Les cartes de feedback que vous recueillez vont à l'affinage, où le Déroulé de l'affinage du backlog les transforme en travail estimé et prêt pour le Sprint Planning suivant. Menez les trois comme un seul système et les parties prenantes continueront de venir, car chaque review leur montre ce que leur dernière série de retours a changé.