Réunion de revue de sprint : objectif, participants et déroulement

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 session 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 concernées par le 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 soulignent ce 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 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 activité qui a lieu (l’équipe présente, les parties prenantes applaudissent, tout le monde s’en va), vous n’avez organisé qu’une communication à sens unique. La revue est la conversation bidirectionnelle que la démonstration est censée initier. 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 orienté 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 commentaires utiles, et faites un tri impitoyable : une salle remplie de spectateurs ne produit que du bruit de fond 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 cette 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 en organiser une 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 place aux réactions. L’équipe doit davantage écouter que présenter. Les questions, les objections et les « et si on pouvait aussi… » constituent justement la matière 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 réellement et résistez à la tentation de créer un « deck ». Dix minutes d’une fonctionnalité en action valent mieux que quarante minutes de captures d’écran de celle-ci.

Revue de sprint vs rétrospective de sprint

On confond souvent ces deux cérémonies de clôture ; veillez donc à bien faire la distinction : 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’ose dire au client que « nos tests sont réalisés à la hâte » ; par conséquent, les fusionner revient à faire disparaître discrètement la partie honnête. Nous conservons la comparaison complète, y compris la liste des participants à chaque réunion et les raisons de les distinguer, dans révision de sprint vs 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 de 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’important n’est pas les applaudissements, mais l’ajustement de la trajectoire. 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 initier : les réactions des parties prenantes, l’évolution des priorités, la modification du backlog. 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 permet d’examiner le produit avec les parties prenantes afin de décider des prochaines fonctionnalités à développer. La rétrospective permet d’analyser le processus de l’équipe en interne, dans un cadre privé, afin d’améliorer le travail lors du prochain sprint. La revue s’adresse à l’extérieur et a lieu en premier ; la rétrospective s’adresse à l’intérieur et a lieu en second. Vous avez besoin des deux, mais elles ne se combinent pas bien.