.jpg)
La sprint review intervient à chaque fin de sprint. Elle est un arrêt sur image, un temps de pause après le rythme soutenu du sprint, afin de faire le bilan de ce qui a été accompli. C’est un rituel primordial, et ce pour deux principales raisons : elle permet de valoriser chaque membre de l’équipe, tout en donnant de la visibilité aux sponsors et aux équipes dépendantes. Elle offre aussi des perspectives aux sponsors et à l’équipe, et permet d’entrevoir la corrélation entre développements concrets et bénéfices utilisateurs.
La sprint review est un rituel agile qui a lieu à la fin de chaque sprint, afin d’analyser ce qui a été réalisé. Elle permet aux équipes, engagées pendant le sprint sur des tâches opérationnelles, de prendre du recul et d’avoir une vision d’ensemble de ce qui a été accompli, mais aussi de comprendre comment chaque sprint s’imbrique plus largement dans le Produit. La sprint review est un moment privilégié pour faire valoir le travail de l’équipe et les performances individuelles. Elle est particulièrement importante pour valoriser l’équipe, donner un sens à l’investissement de chacun et prendre du recul.
Le sponsor (client, directeur produit…) assiste à la sprint review, ainsi que toutes les personnes pouvant être intéressées ponctuellement par le travail de l’équipe, notamment en cas de dépendances (équipe commerciale en cas de lancement d’une nouvelle fonctionnalité, équipe design si un changement majeur a été fait en front…). La sprint review est donc un outil de communication, permettant aux personnes ne pouvant suivre de manière quotidienne le travail de l’équipe de connaître ses accomplissements. Elle est une synthèse du travail accompli.
En fonction de la durée des sprints, la sprint review peut avoir lieu toutes les semaines ou toutes les deux voire trois semaines. Elle dure en moyenne une demi-heure à une heure, afin d’aborder divers sujets :
La sprint review débute toujours par le statut du sprint goal : le sprint goal est l’objectif clé de chaque sprint, la fonctionnalité centrale à réaliser. Au début d’une sprint review, le Product Manager communique sur son accomplissement ou non, et, le cas échéant, explique les raisons de cet échec, en donnant des perspectives de réussite pour le prochain sprint (actions à mener à court ou moyen terme, sprint goal intermédiaire…).
S’ensuit la démo. Cette étape permet à des rôles moins exposés, notamment les développeurs, de faire valoir leur travail : ils peuvent ainsi montrer au sponsor ce sur quoi ils ont travaillé, ce qui peut être une source de motivation. Durant cette étape, une ou plusieurs fonctionnalités clés sont montrées aux participants. Cette présentation est particulièrement importante parce qu’elle permet d’illustrer concrètement l’avancement de l’équipe et le travail accompli, à travers des éléments visuels.
Pour qu’une démo soit réussie, il est important de privilégier des fonctionnalités abouties, mais aussi d’organiser une rotation des présentateurs, afin de varier les sujets, et d’offrir une perspective globale au sponsor de l’ensemble des thématiques appréhendées par l’équipe. Parfois, plusieurs sujets peuvent être présentés lors d’une même démo, avec différents intervenants (sujet front, sujet back, sujet data…). L’important est d’illustrer, à travers la démo, le travail 360 de l’équipe, et ses accomplissements concrets.
La sprint review sert aussi à évaluer la vélocité de l’équipe, c’est-à-dire le nombre de story points réalisés, et de comparer cette performance avec la vélocité prévisionnelle et la vélocité moyenne de l’équipe. La vélocité est un indicateur permettant d’identifier la performance globale de l’équipe : une baisse de vélocité peut être un indicateur de mauvaise organisation et des actions correctives sont alors nécessaires. En effet, si l’équipe est très en-dessous de sa vélocité prévisionnelle, cela peut être le signe d’une difficulté à clarifier l’ensemble des tickets lors du technical refinement et à les estimer correctement. La vélocité est donc un indicateur d’amélioration continue, illustrant l’état de santé de l’équipe.
Jira propose des outils intégrés, comme la « Velocity chart » qui permet de calculer la vélocité moyenne de l’équipe sur les 7 derniers sprints. Voici un exemple de velocity chart proposée par Jira :
Un des outils pour analyser le fonctionnement de l’équipe est la burndown chart. La burndown chart illustre le nombre de story points réalisés le temps d’un sprint, versus une courbe de référence. Elle montre aussi ce qu’il reste à accomplir. La burndown chart permet de comprendre la façon dont travaille l’équipe. Elle illustre à quelle fréquence l’équipe clôture les tickets et elle apporte des clés de compréhension sur le fonctionnement de l’équipe.
Par exemple, si l’équipe finit tous ses tickets au début du sprint et vient rajouter des tickets dans le sprint (ce qui s’illustre par une burndown qui monte au lieu de descendre), cela montre que le technical refinement n’a pas été suffisamment bien anticipé ou que les tickets ont été surestimés. En revanche, si à la fin du sprint, la burndown n’a pas beaucoup descendu, cela montre que l’équipe a été trop ambitieuse, a mal estimé ses tickets ou n’a pas préparé correctement le technical refinement.
La burndown chart permet en un clin d’œil de voir l’état d’avancement de l’équipe et le travail accompli. Elle permet de comprendre l’organisation de l’équipe (si les tickets sont bien estimés, si le technical refinement a été correctement accompli, s’il a été nécessaire de rajouter des tickets en cours de sprint…). Voici un exemple de burndown chart proposée par Jira :
La fin de la sprint review est un moment clé pour faire le point sur la roadmap, voir les étapes qui seront abordées lors des prochains sprints, prendre de la hauteur et mettre en perspective accomplissements du sprint et bénéfices Produit et utilisateurs. La sprint review incite à comprendre que l’important n’est pas de clôturer des tickets mais de développer des fonctionnalités qui auront un impact sur les utilisateurs.
En outre, la fin de la sprint review invite à un moment d’échange entre le sponsor et l’équipe : elle permet de clarifier certains points. Par ailleurs, l’ensemble des personnes de l’équipe étant présentes, toutes les compétences sont réunies pour répondre aux questions d’intervenants extérieurs ou d’équipes dépendantes.
La sprint review n’est pas le lieu de la résolution de problèmes : elle est plus dédiée à la présentation des réussites de l’équipe. Dans ce contexte, il peut être intéressant de faire intervenir ponctuellement des personnes extérieures à l’équipe technique, pour présenter un sujet spécifique : par exemple, lors d’une mise en production importante, le Data Product Manager peut présenter les premiers résultats de la release. Lorsqu’un test utilisateur a été mené, l’UX designer peut venir montrer les conclusions du test à l’ensemble de l’équipe. La sprint review est vraiment un moment d’émulation où l’ensemble des compétences se mêlent, afin de servir le produit. Ce rituel permet de casser les silos.
En étant orienté résultat, l’équipe démontre qu’elle avance sur des sujets variés et complexes (data, design, front, back) et que toutes les facettes du Produit sont envisagées.
La sprint review peut être envisagée comme un moment privilégié pour faire valoir les réussites de l’équipe : elle favorise l’émulation et la recherche de solutions, elle incite à prendre de la hauteur sur les réalisations quotidiennes et permet de tirer une fierté individuelle et collective des accomplissements produits.
Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !
