Issue de la méthodologie Scrum, la sprint review (revue de sprint) est une réunion dont l’objectif est de récupérer du feedback et de donner de la visibilité sur le travail réalisé durant le sprint. Mais réussir sa sprint review n’est pas aussi évident que cela en a l’air. Comment faire de ce rituel une réussite ?
I - Qu’est-ce que la sprint review ?
II - Qui anime la sprint review ?
III - Comment bien préparer une sprint review ?
IV - Quel est le déroulé d’une sprint review ?
🤔 Qu’est-ce que la sprint review ?
Avec le daily scrum meeting, le sprint planning et la rétrospective, la sprint review est l’un des rituels décrits comme obligatoires dans le Scrum guide. Elle se déroule en fin de sprint, juste avant la rétrospective.
Contrairement à certaines organisations qui considèrent la sprint review comme une simple présentation du dernier incrément, je suis convaincue que cette cérémonie doit être perçue comme un événement ouvert et collaboratif. En effet, c’est une occasion de recevoir des retours des parties prenantes sur les nouveautés développées pendant le sprint, permettant ainsi de les impliquer dans le processus Produit.
Quand j'étais Product Manager (PM) chez Predictice, une plateforme Saas spécialisée dans la recherche des données juridiques, nous avons présenté une nouvelle fonctionnalité d’enregistrement des recherches dans des dossiers lors d’une sprint review. À ce moment-là, l'équipe du service client a suggéré de mieux mettre en avant cette fonctionnalité en ajoutant une pop-up pour annoncer cette nouveauté ou via un tutoriel pour aider les utilisateurs à comprendre comment l'utiliser. L'équipe commerciale, elle, s'est posée des questions sur l'ajout de fonctionnalités supplémentaires, telles que la possibilité de créer des sous-dossiers et de collaborer sur les dossiers comme peut le faire Google Drive par exemple. Ces échanges ont été l'occasion de prendre en compte leurs retours et de discuter des prochaines évolutions prévues.
À la fin d’une bonne sprint review, vous devez être en mesure de répondre par l'affirmative à ces questions :
- L’objectif du sprint a-t-il été atteint et le produit est-il toujours cohérent avec la vision globale du produit ?
- Avez-vous eu la participation collaborative et constructive de toutes les parties prenantes concernées ?
- L'équipe a-t-elle identifié des opportunités d'amélioration pour le prochain sprint ?
🙋 Qui anime la sprint review ?
Comme dans toute équipe, chaque rôle a son importance.
Le rôle du Product Owner
Le rôle du Product Owner (PO) dans une revue de sprint est à géométrie variable. Il peut :
- Être le facilitateur. Son rôle est alors d’introduire la revue de sprint, donner du contexte et faire en sorte que le timing soit respecté.
- Être le démonstrateur. En plus de la potentielle facilitation, il peut être amené à faire lui-même les démonstrations des fonctionnalités développées.
- N’être qu’un spectateur. Cette posture est surtout observée lorsqu’il n’est pas beaucoup disponible pour l’équipe. La revue lui permet de découvrir ce qui a été réalisé par l'équipe.
Pour ma part, privilégiant une proximité avec l’équipe, je me positionne beaucoup plus en facilitateur et non en démonstrateur.
Les autres participants
Selon Floriane Sirven, coach Produit chez Thiga, "le plus important est d’avoir une revue de sprint ouverte à tous. Toute personne intéressée est la bienvenue". Je suis entièrement d'accord avec elle. Inviter les parties prenantes comme l'équipe data, marketing, commerciale ou encore le service client est crucial pour recueillir leurs feedbacks et les tenir informés de l'avancement du produit. J’invite aussi les Product Managers et Product Owners d'autres équipes pour qu’ils soient au courant des évolutions du produit. Cela a pour avantage d'identifier d’éventuelles dépendances entre les équipes et de partager des retours UX/UI intéressants.
Bien qu’on cherche une ouverture pour cette réunion, j’émets deux points d’attention. Le premier repose sur le fait qu’avoir trop d’invités peut impacter négativement l’efficacité de la réunion. Trouver le juste équilibre est un défi que le PO doit relever. Le second point d’attention concerne le choix des invités. Il faut que ces personnes viennent avec un état d’esprit constructif en comprenant que le produit est toujours en cours de construction. Certains peuvent vite s’alarmer en pensant que la fonctionnalité est finie alors que ce n’est pas le cas. C’est au PO de bien identifier ces individus afin de les rassurer.
Afin d’optimiser la participation des parties prenantes, je communique en amont un ordre du jour leur permettant d'être informées des sujets qui seront abordés et de définir si leur présence est nécessaire ou non.
Qui présente la démonstration ?
Pour la démonstration ou “démo”, il peut être tentant de vouloir l’effectuer soi-même. Personnellement, je délègue cette partie aux développeurs pour mieux valoriser leur travail accompli et leur donner plus de visibilité vis-à-vis des parties prenantes. Il m’arrive toutefois d’introduire le sujet et de donner des éléments de contexte quand cela s’avère pertinent.
Par ailleurs, je m’assure que la présentation est compréhensible pour l'ensemble de mon auditoire en vulgarisant au maximum les termes employés. C’est d’ailleurs l’un des problèmes qui peut arriver lorsque les développeurs présentent leur travail pour la première fois. Lorsque je vois que les participants sont perdus, j’interviens pour clarifier le message !
💪 Comment bien préparer une sprint review ?
Pour assurer l'efficacité de la sprint review, il est essentiel d'éviter l'improvisation et de bien la préparer à l'avance. Je commence par collecter les données nécessaires, telles que le nombre de story points réalisés et les données d'utilisation des fonctionnalités livrées au sprint précédent. Une fois que j'ai rassemblé ces informations, je les analyse pour comprendre les résultats du sprint. Je crée ensuite des graphiques comme le “burndown chart” pour montrer la progression du travail accompli au cours du sprint et aider à la visualisation.
Que doit-on présenter ?
Vous êtes-vous déjà demandé s’il fallait présenter ou non une fonctionnalité lors d’une revue ? Moi oui ! Selon le “scrum guide”, il ne faut présenter que le travail considéré comme terminé. Cependant, il m’arrive par exception de présenter des fonctionnalités pour lesquelles il manque quelques éléments. Cela me permet de ne pas attendre 2 semaines (la durée d’un sprint) pour avoir le feedback des parties prenantes. Ces démonstrations peuvent être faites en local sur le poste d’un développeur. Dans ces situations, il est important que les parties prenantes soient conscientes que le travail n’est pas fini.
Par ailleurs, il m’est arrivé que certains développeurs backend estiment qu'il n'y a rien d'intéressant à présenter bien que la démonstration puisse en réalité mettre en évidence un réel travail effectué par l’équipe sur des éléments quasi-invisibles de l’utilisateur comme des améliorations de performance apportées par des optimisations de code, ou encore la mise en place d'une API. Dans ce cas, je m'assure que la démonstration soit succincte et suffisamment accessible pour être compréhensibles par tous.
Il est aussi possible que vous ayez déjà envisagé d’annuler une revue de sprint parce qu’ il n'y avait rien à montrer ou que l'équipe de développement n'avait pas atteint l'objectif de sprint… Quitte à la raccourcir, je suis persuadée qu'il est essentiel de la maintenir car elle amène de la transparence avec les parties prenantes et permet de parler des avancées de l'équipe de développement, malgré les difficultés rencontrées.
Comment éviter “l’effet démo” ?
Par le passé, j'ai moi-même été confrontée à des démonstrations qui ne se passaient pas comme prévu. Pour garantir une présentation réussie, que ce soit en présentiel ou à distance, j'ai appris avec le temps qu'il est crucial de préparer et tester l'environnement de démonstration en amont. Voici quelques conseils appris avec le temps pour éviter ces problèmes :
- Assurez-vous qu’il n’y a pas de déploiements ou changements de configuration intempestifs avant ou pendant la présentation faits par des personnes extérieures à l’équipe,
- Vérifiez que toutes les données nécessaires sont disponibles pour la démonstration,
- Testez l'environnement de démonstration en simulant les différentes étapes de la présentation pour identifier et résoudre les éventuels problèmes avant,
- Évitez de créer un compte de test en direct et assurez-vous d'en avoir un prêt à l'avance,
- Si la revue de sprint est à distance ou en hybride, assurez-vous que l'environnement de la personne effectuant la démonstration est propice à une bonne présentation, avec une connexion internet fiable et sans bruit ou interruption,
- Réservez une salle de réunion adaptée avec un vidéoprojecteur ou un écran pour une présentation en présentiel,
- Proposez à un développeur de s'entraîner avec vous, vous pouvez également travailler avec lui le scénario de démonstration.
Pour limiter les risques de problèmes techniques et le fameux ”effet démo” tant redouté, nous avons pour habitude avec mon équipe de faire un enregistrement vidéo en amont avec Loom. Le développeur partage alors la vidéo de son écran et fait des commentaires à l’oral.
🗒️ Quel est le déroulé d’une sprint review ?
La durée d’une sprint review
Le “scrum guide” recommande une revue de sprint d’une durée de 3h pour un sprint d’1 mois. Dans mon équipe, les sprints étant de 2 semaines, nous avons pris pour habitude de faire la revue de sprint en 1h.
Au-delà de la durée, il est important de choisir un jour et une heure régulière pour la présentation afin que cela devienne une routine pour les parties prenantes.
Les 3 grandes étapes de la sprint review
La revue de sprint se déroule en 3 temps :
- Le contexte, l’objectif de sprint et les chiffres clés
Dans mon équipe, nous avons pris pour habitude de commencer par rappeler l’objectif du sprint et de faire le bilan de l'engagement versus le travail réalisé. Nous partageons également les événements qui ont perturbé le bon déroulement du sprint. Enfin, nous partageons les résultats des A/B tests effectués, ainsi que les chiffres clés.
- La démonstration ou “démo”
Comme le souligne Naban Tuo, Product Manager chez Thiga : "la première mesure de succès, c’est un logiciel qui est opérationnel. Ainsi, présenter des slides en “démo”, ce n’est pas une bonne pratique, il faut montrer le produit que l’équipe a créé."
Je vous recommande vivement de faire une démonstration dynamique de la fonctionnalité, comprenant une prise en main et un parcours utilisateur pour obtenir une meilleure compréhension des parties prenantes et recueillir plus de feedbacks.
Je m’assure aussi de prévoir suffisamment de temps entre chaque démonstration de fonctionnalité pour permettre aux parties prenantes de poser des questions ou faire des retours. Je veille toutefois à répartir le temps en fonction des démonstrations et à me concentrer sur les éléments essentiels pour respecter le timing.
La projection vers le futur
Avant de clore la revue de sprint, je prends quelques minutes pour présenter les prochaines priorités sur lesquelles l’équipe va travailler pour m’assurer que tout le monde est aligné.
Je termine enfin avec un R.O.T.I (Return On Time Invested) afin de récupérer des retours et toujours chercher à améliorer l’animation de ces revues. Bien que cette dernière partie soit courte, il est selon moi important de la conserver.
Comme vous l’aurez compris, la sprint review est une étape cruciale du processus de développement Agile. Sa bonne animation permet de fédérer et gagner la confiance de vos parties prenantes. Contrairement à une approche courante consistant à ne la considérer que comme une simple démonstration, ce rituel va bien plus loin amenant avec lui tout un aspect de transparence et une récolte de feedbacks qui sont clés pour la suite. J’espère que vous en êtes désormais convaincus (si vous ne l’étiez pas déjà).
Merci à Mathilde Billay pour son aide précieuse à la production de cet article.
Pour en savoir plus : télécharger notre livre Les Clés du Product Management
