La revue de sprint est la cérémonie au cours de laquelle l’équipe présente un produit fonctionnel aux parties prenantes et recueille les retours d’expérience qui orienteront ses prochains développements. Elle a lieu à la fin du sprint, dure environ deux heures pour un sprint de deux semaines, et aboutit à une mise à jour du backlog produit. Ce qu’il faut retenir : il s’agit d’une séance de travail, et non d’une présentation. La valeur ne réside pas dans la démonstration, mais dans les décisions qu’elle suscite.

À quoi sert la revue de sprint ?

Cette revue a pour but de répondre à une question avec les personnes qui s’intéressent au résultat : compte tenu de ce que nous venons de réaliser, que devrions-nous réaliser ensuite ?

L’équipe présente l’incrément (le travail réellement achevé, conformément à la définition de « terminé », et non le travail qui est presque terminé) et les parties prenantes présentes dans la salle réagissent. Elles posent des questions, elles remettent en question, elles soulèvent des points que personne n’avait pensé à mentionner lors de la planification. Cette réaction constitue le résultat de la réunion. Elle est directement intégrée au backlog du produit, que le Product Owner ajuste sur-le-champ ou peu après.

Revue du sprint ou démonstration ?

Les gens utilisent les termes « revue de sprint » et « démonstration » comme s’il s’agissait d’une seule et même réunion. Ce n’est pas le cas : la démonstration n’est qu’une partie de la revue.

Il est important de présenter un logiciel fonctionnel : cela impose l’honnêteté (vous ne pouvez pas faire la démonstration d’une fonctionnalité presque terminée) et cela donne à chacun un élément concret sur lequel réagir. Mais si la démonstration est la seule étape du processus (l’équipe présente, les parties prenantes applaudissent, tout le monde s’en va), vous n’avez organisé qu’une diffusion à sens unique. La revue est la conversation bidirectionnelle que la démonstration est censée lancer. La démonstration n’est qu’une mise en scène ; ce sont les retours d’expérience et la redéfinition des priorités qui constituent l’essentiel. Une démonstration réalisée pour susciter des applaudissements, sans aucune décision à la clé, relève du théâtre agile : une cérémonie organisée pour le public plutôt que pour le résultat.

Qui y participe, et pourquoi il est tourné vers l’extérieur

La revue du sprint est la seule cérémonie conçue pour s’adresser à l’extérieur. Les participants sont l’ensemble de l’équipe Scrum ainsi que les parties prenantes invitées par le Product Owner : clients, utilisateurs, commanditaires, services d’appui, et toute personne dont la réaction est susceptible d’influencer le produit.

Cette liste d’invités relève d’un choix, et non d’une simple formalité. Invitez des personnes capables d’apporter des retours utiles, et faites un tri impitoyable : une salle remplie de spectateurs ne produit qu’un brouhaha courtois ; une salle avec les trois bons clients permet de réorganiser le backlog. Cette ouverture vers l’extérieur est précisément ce qui distingue la revue de la rétrospective de sprint, qui est réservée à l’équipe et se déroule en privé pour une bonne raison.

Comment organiser une séance qui vaille vraiment la peine d’y consacrer une heure

Le format est volontairement décontracté. Veillez à ce que cela reste une séance de travail, et non un spectacle.

  • Commencez par rappeler l’objectif du sprint. Rappelez à l’assemblée ce que ce sprint visait à accomplir, afin que l’incrément soit évalué à l’aune de l’objectif initial, et non en fonction d’une impression générale.
  • Présentez un produit fonctionnel, pas des diapositives. Faites une démonstration du produit réel en vous référant à la définition de « terminé ». Évitez de présenter ce qui est « presque terminé ». Cela suscite des débats sur un travail qui n’est pas achevé.
  • Laissez de la place aux réactions. L’équipe doit davantage écouter que présenter. Les questions, les objections et les « et si on pouvait aussi… » constituent précisément ce que vous êtes venu chercher.
  • Clôturez la réunion en mettant à jour le backlog. Intégrez les retours d’expérience dans les priorités tant qu’ils sont encore d’actualité. C’est là le résultat concret de la réunion.

La préparation consiste avant tout à faire preuve de retenue : choisissez ce que vous allez montrer, assurez-vous que cela fonctionne bel et bien, et résistez à l’envie de créer un diaporama. Dix minutes d’une fonctionnalité en action valent mieux que quarante minutes de captures d’écran de celle-ci.

Revue de sprint et rétrospective de sprint

On confond souvent ces deux cérémonies de clôture, alors retenez bien ceci : la revue examine le produit avec les parties prenantes ; la rétrospective examine le processus de l’équipe, en interne. La revue est orientée vers l’extérieur et a lieu en premier ; la rétrospective est orientée vers l’intérieur et a lieu en second, afin que l’équipe puisse intégrer les retours d’expérience récents sur le produit dans sa propre réflexion.

Ces deux éléments ne font pas bon ménage. Personne n’aborde le sujet « nos tests sont précipités » devant le client ; par conséquent, les fusionner revient à faire passer sous silence la partie la plus honnête. Nous conservons la comparaison complète, y compris la liste des participants à chaque réunion et les raisons pour lesquelles elles sont distinctes, lors de la revue de sprint par opposition à la rétrospective de sprint. Pour savoir où ces deux réunions s’inscrivent parmi les autres, consultez les quatre cérémonies Scrum et les autres cérémonies présentées dans ce guide.

Foire aux questions

Quel est l’objectif d’une revue de sprint ?

Examiner l’incrément du produit avec les parties prenantes et adapter la suite du processus en conséquence. L’équipe présente ce qu’elle a réellement achevé, les parties prenantes réagissent, et cette réaction alimente le backlog du produit. L’objectif n’est pas de recueillir des applaudissements, mais d’ajuster le cap. Une revue qui ne modifie en rien le plan n’est rien d’autre qu’une réunion d’état d’avancement déguisée.

Qui participe à une réunion de revue de sprint ?

L’ensemble de l’équipe Scrum, ainsi que les parties prenantes invitées par le Product Owner : clients, utilisateurs, commanditaires, et toute personne dont les retours d’expérience doivent contribuer à façonner le produit. C’est la seule réunion qui s’ouvre délibérément vers l’extérieur. Le Product Owner établit la liste des invités de manière à ce que les retours d’expérience exprimés lors de cette réunion méritent d’être pris en compte.

Quelle doit être la durée d’une revue de sprint ?

Prévoyez environ deux heures par semaine de sprint : jusqu’à deux heures pour un sprint de deux semaines, jusqu’à quatre heures pour un sprint d’un mois. Si le temps imparti est dépassé, c’est probablement que vous présentez des diapositives au lieu de montrer un produit fonctionnel, ou que vous examinez un travail qui n’a en réalité pas été effectué.

Quelle est la différence entre une revue de sprint et une démonstration ?

Une démonstration est l’une des activités menées dans le cadre de la revue : elle consiste à présenter le logiciel en état de fonctionnement. La revue de sprint, quant à elle, désigne la discussion plus large que la démonstration vient lancer : les parties prenantes réagissent, les priorités évoluent, le backlog change. Si vous considérez la revue comme une simple démonstration, vous n’obtiendrez qu’une présentation à sens unique qui suscitera des hochements de tête, mais ne débouchera sur aucune décision.

Quelle est la différence entre une revue de sprint et une rétrospective ?

La revue de sprint consiste à examiner le produit avec les parties prenantes afin de décider des éléments à développer ensuite. La rétrospective consiste à analyser le processus de l’équipe elle-même, en interne, afin d’améliorer le travail lors du prochain sprint. La revue est orientée vers l’extérieur et a lieu en premier ; la rétrospective est orientée vers l’intérieur et a lieu en second. Vous avez besoin des deux, mais elles ne se combinent pas bien.