Sprint Review : Comment se déroule une Review en Scrum & Agile ?

L'activité la plus évidente lors d'une Sprint Review est la démonstration des fonctionnalités développées pendant le Sprint précédent. Cependant, une bonne Sprint Review va bien au-delà d'une simple démonstration. Regardons ensemble un ordre du jour pour une réunion de Review.

Créer les bonnes conditions pour la Review

Le Product Owner commence le Sprint Review Meeting en souhaitant la bienvenue à tous les participants. Il suffit amplement de dire quelque chose comme : « Merci à tous d'être là. »

Si les personnes présentes ne se connaissent pas entre elles, le Product Owner peut leur demander de se présenter brièvement. Au début d'une nouvelle initiative de développement produit, un tour de présentations est généralement une bonne idée. Le Product Owner sait certes que Joe du marketing est Joe du marketing, mais les membres de l'équipe ne le savent peut-être pas.

De plus, il est judicieux que tous les participants se présentent brièvement lorsque de nouveaux participants rejoignent occasionnellement les Sprint Reviews. Il se peut en effet que Joe du marketing ne vienne qu'aux Sprint Reviews des deux Sprints pendant lesquels l'équipe a travaillé sur des fonctionnalités liées au marketing.

Les présentations doivent vraiment rester courtes et concises. « Salut, je suis Mike et je suis développeur. J'ai travaillé sur les fonctionnalités du panier d'achat » est presque déjà trop. « Salut, je suis Mike et je suis développeur » suffirait dans la plupart des cas. Cependant, dès qu'une équipe atteint une certaine taille, il peut être utile pour les parties prenantes d'en savoir brièvement un peu plus sur ce sur quoi chacun a travaillé.

Après l'accueil et le tour de présentations éventuellement nécessaire au début, le Product Owner peut encore établir quelques règles ou annoncer les attentes pour le Sprint Review. Par exemple, certains Product Owners trouvent important de rappeler de toujours rester courtois pendant le Sprint Review. Donc si quelqu'un n'aime pas la façon dont une fonctionnalité a été implémentée, il peut bien sûr le dire, mais il ne faut pas qualifier l'implémentation de « débile ». Oui, bien sûr nous savons tous ces choses de toute façon, mais parfois il faut le rappeler.

En fonction du nombre de participants et de nombreux autres facteurs, le Product Owner peut aussi expliquer aux personnes présentes que le Review cherche certes à obtenir du feedback sur les fonctionnalités construites jusqu'ici, mais que ce n'est ni le moment ni l'endroit pour repenser complètement le design des fonctionnalités.

Une fois l'introduction et les règles du Review terminées, il est temps de passer au point suivant de l'ordre du jour.

Qu'est-ce qui est démontré lors d'une Review - et qu'est-ce qui ne l'est pas ?

À ce stade, beaucoup d'équipes commencent directement par la démonstration. Je recommande que le Product Owner donne d'abord un bref aperçu de ce qui va être démontré et de ce qui ne le sera pas.

Pour éviter que le Product Owner se contente de lire une liste d'items que les participants ne peuvent pas suivre, celle-ci devrait être affichée de manière visible sur un écran ou un projecteur. On peut aussi imprimer la liste à l'avance pour ceux qui souhaiteraient en avoir une copie.

Personnellement, j'aime envoyer ces informations la veille du meeting sous forme de document Word par e-mail à tous les participants potentiels du Sprint Review. Cela donne aux gens la possibilité de voir à l'avance ce qui sera démontré. Ainsi, chacun peut décider si cela vaut la peine pour lui de participer au Sprint Review.

Le tableau suivant présente les informations que je considère pertinentes pour chaque élément du Product Backlog. Je suggère de lister les items dans l'ordre dans lequel ils seront démontrés. Cela peut toutefois être modifié spontanément selon les besoins.

Le premier point du tableau est une description de l'élément concerné. On y insère une User Story ou une autre description. Ensuite vient la taille des éléments – généralement en Story Points. Puis vient le statut des éléments. Il s'agit principalement de savoir s'ils sont terminés ou non. Mais tout ce qui semble important à cet égard peut également y être ajouté. La dernière colonne indique si l'élément en question sera présenté ou non.

Tu te demandes peut-être pourquoi des éléments qui ne doivent pas être présentés figurent sur la liste. Dans le tableau ci-dessus, j'ai inclus quelques exemples. De toute évidence, l'élément qui a été intégré au Sprint puis abandonné ne peut pas être présenté. J'ai également listé une correction de bug qui ne concerne qu'une mise à jour d'un caractère sur un écran – cet élément n'est pas non plus prévu pour la démonstration.

Il est tout à fait possible qu'un ou plusieurs participants posent des questions sur un élément qui n'était pas prévu pour la démo. Si cela arrive, tu peux présenter cet élément avec les autres sans problème. Il ne s'agit pas d'éviter de montrer certains éléments, mais de respecter le temps des participants en ne leur montrant pas des éléments sur lesquels on n'a pas besoin de feedback.

Dans le tableau d'exemple, j'ai inclus un Product Backlog Item qui a été ajouté au cours du Sprint. Je trouve utile de pouvoir identifier quels éléments étaient prévus dès le début du Sprint et lesquels ont été ajoutés en cours de route. Si des éléments sont fréquemment ajoutés pendant le Sprint, on peut envisager d'ajouter une colonne au tableau pour indiquer si les éléments étaient planifiés ou ajoutés ultérieurement.

On peut également ajouter une colonne tout à droite indiquant si les éléments ont été acceptés par les participants du Review Meeting, s'ils sont prêts pour un Release, etc. C'est particulièrement utile lorsque ces décisions font officiellement partie du Sprint Review.

Essaie de ne pas consacrer trop de temps à cette partie de l'agenda. L'objectif ici n'est pas d'obtenir du feedback sur les éléments ou de discuter des raisons pour lesquelles un élément prévu n'a été que partiellement implémenté. Cette liste sert uniquement à présenter le contenu du meeting. Une fois que le Product Owner a présenté cette liste, on passe à la partie principale du Sprint Review : la démonstration.

Démontrer les nouvelles fonctionnalités

C'est le cœur de toute réunion de Sprint Review. Si vous faites déjà des Sprint Reviews, il est fort possible que ce soit la seule partie de l'agenda que vous réalisez effectivement.

Dans cette partie du Sprint Review, vous passez en revue un par un les éléments que vous avez montrés aux participants au préalable. N'oubliez pas que le but d'une réunion de Sprint Review est d'obtenir du feedback.

Il n'y a pas de règle fixe sur qui doit faire la démo. Dans certains cas, c'est le Product Owner qui s'en charge. C'est ce que je recommanderais toujours quand des parties prenantes particulièrement difficiles participent à la Review. Dans d'autres cas, les membres de l'équipe concernés présentent eux-mêmes les éléments sur lesquels ils ont travaillé. Presque toutes les variantes sont permises ici. Expérimentez un peu et découvrez ce qui fonctionne le mieux pour votre équipe.

Discuter des points les plus importants

Une fois que tous les éléments du Product Backlog terminés ont été présentés, les événements majeurs ou problèmes principaux de ce Sprint sont discutés.

La discussion peut être animée soit par le Scrum Master, soit par le Product Owner. D'après mon expérience, les deux approches fonctionnent aussi bien l'une que l'autre. Personnellement, j'ai cependant une légère préférence pour que le Scrum Master prenne en charge cette partie de la réunion.

Jusqu'à ce moment du Review, le Product Owner aura beaucoup plus parlé que le Scrum Master. C'est pourquoi je trouve que c'est un bon équilibre si le Scrum Master anime cette partie de l'ordre du jour. De plus, à proprement parler, il s'agit généralement davantage d'une discussion sur le processus que sur le produit lui-même. Cela relève donc un peu plus du domaine du Scrum Master.

Présenter les prochains éléments du Product Backlog

Le dernier point à l'ordre du jour de la Sprint Review devrait être une discussion sur les prochains travaux du Product Backlog . Comme l'objectif de la Sprint Review est de recueillir du feedback sur le travail du Sprint en cours, cela influence souvent les travaux des Sprints suivants.

Par exemple, si les stakeholders apprécient beaucoup le look des nouveaux écrans, le Product Owner voudra peut-être rapidement adapter d'autres parties du produit au nouveau design. Ou bien la façon dont les fonctionnalités ont été implémentées ne plaît pas tant que ça au stakeholder . Dans ce cas, le prochain Sprint peut être utilisé pour corriger ces points au lieu de continuer avec les items suivants (comme cela se serait passé sans Sprint Review).

Le Product Owner lance la discussion avec la présentation des prochains items potentiels du Product Backlog. Il dit alors peut-être quelque chose comme : « Sur l'écran, vous voyez dix items que j'avais prévus pour le prochain Sprint. Cependant, j'aimerais ajouter l'item XY qui est apparu aujourd'hui. Je vais probablement l'insérer en position n° 3. »

Le Product Owner demande ensuite aux participants leur avis sur cette liste. Toutefois, à mon sens, le Product Owner ne devrait pas effectuer de priorisation pendant la Sprint Review en fonction de ces commentaires. Il y a plusieurs raisons à cela. Le Product Owner a peut-être besoin de temps pour réfléchir à ce qui a été dit. Ou peut-être souhaite-t-il recueillir les estimations de l'équipe sur les changements demandés lors de la Review, etc. Donc le Product Owner recueille les avis pendant la Sprint Review et prend les décisions finales tranquillement après la réunion.

Clôturer la Review

Terminez simplement la réunion en remerciant tout le monde pour leur participation. Réfléchissez également si vous ne souhaitez pas remercier l'équipe dans son ensemble pour le travail accompli durant le dernier Sprint, ou de temps en temps un ou deux membres de l'équipe qui ont montré des performances particulièrement bonnes. Ensuite, rappelez à tous quand et où aura lieu la prochaine réunion de Sprint Review.

Après la Sprint Review

Même si cela ne fait pas directement partie de l'ordre du jour de la Sprint Review, il faut s'assurer que tous les nouveaux Product Backlog Items sont bien transférés dans l'outil de l'équipe ou notés sur un Post-It et accrochés au Scrum Board.