Comment réussir sa Sprint review (ou Revue de sprint) ?

Réalisée en fin de sprint, la Sprint review précède la Rétrospective. Elle est l’occasion pour l’équipe Scrum de faire une démo sur les Users Stories terminées. Cette cérémonie est essentielle pour collecter des feedbacks et peut jouer un rôle clé sur le moral de l’équipe.

La Sprint review, une cérémonie de Scrum

La Sprint review est, au même titre que le Sprint planning, le Daily meeting et la Rétrospective, une des cérémonies de Scrum. C’est l’occasion pour les membres de l'équipe de célébrer leurs réalisations en faisant une démonstration du travail accompli pendant le sprint qui s’achève. Mais c’est aussi la possibilité d’ouvrir une discussion avec ses utilisateurs sur l’avenir du produit afin de construire ses prochains sprints et obtenir du feedback sur les fonctionnalités présentées.

📚 Lire nos articles concernant les autres cérémonies de Scrum : le Sprint Planning, le Daily Scrum Meeting et la Rétrospective.

Il est essentiel de bien préparer cette cérémonie pour éviter certaines erreurs qui pourraient être génératrices de stress et de mécontentement pour les différentes parties prenantes présentes lors de cette réunion (Équipe Scrum, sponsors, clients, utilisateurs…). Une Review qui se déroule bien peut avoir un impact positif sur le moral de l’équipe, mais aussi sur les prochaines étapes du développement du produit.

Les bonnes pratiques de la Sprint review

Pour bien réussir sa Sprint review, il faut veiller à respecter quelques bonnes pratiques. La première étape est de vérifier que l’équipe a bien défini ce que l’on appelle une User Story (US) terminée. Si une User Story respecte la définition de terminée, définie par l’équipe, alors il sera possible d’en faire la démonstration pendant la Review. Seules les User Stories identifiées comme terminées y seront présentées, les autres devront attendre une Revue prochaine.

📚 Lire notre article concernant la Definition of Done.

Le temps est également un élément-clé de la réussite d’une Sprint review. Les équipes étant très occupées, il faut définir une plage horaire ne dépassant pas 1 heure par semaine de sprint réalisée. Dans les faits, 2 heures semble être la durée maximale supportée par les stakeholders et les membres de l’équipe. En se basant sur cette plage horaire, préparer un planning de la Sprint review permet de garder un fil conducteur et de ne pas dépasser le temps prévu.

Pour finir, l'élément le plus important de cette Review est le feedback donné par les stakeholders, qui apporte une forte valeur ajoutée pour le produit et les futures actions à mener. C’est ce recueil d’informations qui va différencier la Sprint review d’une simple démo.

Pour vous aider à réaliser des Sprint reviews à fort impact, voici un exemple de planning que vous pouvez utiliser en tant que ligne temporelle directrice.

Exemple d’organisation d’une Sprint review

• Accueillir les participants et leur présenter les fonctionnalités qui seront montrées lors de cette Review ;
• Présenter les nouvelles fonctionnalités ;
• Recueillir des feedbacks sur le nouvel incrément ;
• Présenter les prochaines fonctionnalités à venir (le “haut du backlog”) pour récolter un dernier feedback avant le lancement du sprint à venir et le cas échéant, reprioriser le backlog.

Un dernier conseil pour augmenter la compréhension de votre produit et augmenter l’implication des équipes : rendre les démos réalisées pendant la revue accessibles à toute l’entreprise. Chez Atlassian, des vidéos informelles sont partagées sur Confluence afin de rendre les présentations des nouvelles fonctionnalités accessibles par tous les employés.

Les erreurs à éviter ?

Qui dit bonnes pratiques, dit aussi mauvaises pratiques et erreurs à ne pas commettre lors de l’organisation et la réalisation de la Sprint review. Il est facile de garantir la qualité de votre Sprint review en suivant ces conseils :

Attention à ne pas la confondre avec une session de tests

Les fonctionnalités qui sont montrées doivent avoir été testées en amont et des scénarii doivent avoir été préparés pour éviter à la Review de sprint de tourner à la catastrophe.

Cette erreur va de pair avec les modifications de dernières minutes. Ces ajustements de code fait rapidement avant la Review sont à proscrire. En effet, ils peuvent provoquer des bugs, des scénarios non testés et par conséquent, générer du stress dans cette cérémonie qui se veut informelle et détendue. Mais aussi développer un mécontentement de la part des stakeholders qui ne retiendront que les aspects négatifs de cette cérémonie.

Il faut laisser de la place aux feedbacks

La Sprint review n’est pas une simple démo. L’un des avantages et but premier de cette cérémonie est d’obtenir un retour et des informations de la part de stakeholders. Ne pas donner la possibilité aux participants de s’exprimer empêcherait donc l’apport d’informations essentielles au bon développement du produit.

Enfin, il ne faut pas confondre la Review avec une Rétrospective

En effet, la Review est vraiment axée sur ce qui a été réalisé et non pas sur comment cela a été réalisé (processus). Il est donc impératif de conserver les retours de l’équipe sur les processus liés à l’organisation pour la cérémonie de Rétrospective, qui, dans l’idéal, aura lieu juste après la Sprint review.

Les résultats d’un bonne Sprint review

Voilà votre Sprint review est terminée ! Quels sont les résultats que vous pouvez en tirer ?

Tenir au courant les stakeholders de l’avancée du projet et des fonctionnalités réalisées lors du sprint passé. Par la même occasion, c'est le moment idéal pour célébrer le travail et les efforts qui ont été réalisés par l’équipe ces derniers jours.

Obtenir du feedback capital, qui permettra d’aider à la prise de décision quant aux évolutions futures du produit. Mais aussi d’aider sur la constitution des prochains sprint backlogs.

Augmenter le moral des équipes, car le fait de montrer le résultat de son travail est gratifiant et génère de l’énergie pour l’équipe.

En conclusion

Une Sprint review n’est pas une démo : c’est une cérémonie qui permet d’apporter de la valeur au travail fourni par l'équipe durant le sprint et de l’encourager, mais aussi d’obtenir du feedback directement de la part des stakeholders.