Beaucoup de gens ont détourné le but initial de la sprint review mais il faut bien l’accepter la sprint review n’est pas une démo. Il est parfois important de regarder les mythes qui se font autour du Scrum car il peut être intéressant d’analyser les raisons de ces mythes.
Qu’est-ce que la sprint review ?
Si on regarde à la source du Scrum, soit le Scrum Guide (source la plus à jour), voici concrètement comment la sprint review est qualifiée :
« Une revue de Sprint (Sprint Review) est tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Backlog Produit si nécessaire. Pendant la revue de Sprint, l’équipe Scrum et les parties prenantes échangent sur ce qui a été fait durant le Sprint. »
Sur cette première phrase du Scrum Guide, on comprend clairement que l’idée se situe sur une inspection du « Done ». Cependant, est-ce qu’une liste suffit pour que les parties prenantes voire les utilisateurs clés (parfois eux-mêmes parties prenantes) ou doit-on bel et bien présenter le rendu afin d’améliorer l’échange entre l’équipe et les parties prenantes ?
« Sur la base de cela et de tout changement du Backlog Produit survenus pendant le sprint, les participants collaborent sur les prochains travaux qui pourraient être faits pour optimiser la valeur. Cette réunion se veut informelle, pas une réunion de pilotage, et la présentation de l’incrément est destinée à susciter les réactions et à favoriser la collaboration. »
Le Scrum Guide est sans appel sur le fait que la Sprint Review a pour but de susciter des réactions telles que des feedback ; les utilisateurs clés, parties prenantes et sponsors seraient les mieux placés pour réaliser ces feedbacks.
« Il s’agit au maximum d’une réunion de quatre heures pour les sprints d’un mois. Pour les sprints plus courts, l’événement est généralement plus court. Le Scrum Master s’assure que l’événement ait lieu et que les participants en comprennent son but. Le Scrum Master apprend à tous ceux qui y sont impliqués à le garder dans la boîte de temps (time-boxé).
Cette partie du Scrum Guide est en général bien compris par l’ensemble des équipes que je rencontre. Cependant, je vois quand même certaines équipes peu matures, allonger le temps de la sprint review sans raison majeure : tentative de régler un soucis de câble sur place, démo pas préparée, pas de facilitateur, Product Owner qui ne maitrise pas son sujet…
« La Revue de sprint comprend les éléments suivants :
• Les participants incluent l’équipe Scrum et les principales parties prenantes invitées par le Product Owner ;
• Le Product Owner indique quels éléments du Backlog Produit ont été « Finis » et ceux qui n’ont pas été « Finis » ;
• L’équipe de développement discute de ce qui s’est bien passé pendant le Sprint, quels problèmes ont été rencontrés, et comment ces problèmes ont été résolus ;
• L’équipe de développement démontre le travail « Fini » et répond aux questions sur l’incrément ;
• Le Product Owner discute de l’état actuel du Backlog Produit tel qu’il est. Il ou elle projette les dates prévisionnelles et celles de livraison en fonction des progressions réalisées à ce jour (si nécessaire) ;
• L’ensemble du groupe convient de ce qu’il faut faire pour la suite, de sorte que la revue de sprint fournisse une contribution précieuse à la prochaine réunion de Planification du Sprint ;
• La revue de la façon dont les conditions de marché ou un usage potentiel du produit pourrait avoir dicté ce qu’il conviendrait mieux de faire dorénavant ; et,
• La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les prochaines versions prévues de la fonctionnalité du produit. »
En effet contrairement à de nombreuses idées reçues, on peut parler des items qui n’ont pas été terminé. Cependant dans certains contextes où l’idée de deadline est forte, je conseille à l’équipe d’éviter cela afin de ne pas avoir des réactions telles que « ah ba c’est livré demain alors ».
Le rappel des problèmes rencontrés se fait bien lors de le Review et non lors de la rétrospective ; cela permet souvent de justifier aux différentes personnes présentes les raisons des éventuels retards voire de trouver des supports importants pour la résolution de problèmes.
« Le résultat de la revue de sprint est un Backlog Produit révisé qui définit les éléments probables pour le prochain Sprint. Le Backlog Produit peut également être globalement ajusté pour répondre aux nouvelles opportunités d’affaires. »
Comme l’indique la dernière phrase, en effet l’intérêt de la review est de récupérer du feedback pour améliorer le produit. Ne pas inviter vos utilisateurs clés comme on le voit encore trop souvent diminue considérablement l’intérêt de cette review.
Conclusion : la sprint review n’est pas une démo
En effet, copier des méthodes sans réfléchir n’a pas de sens mais cet article avait juste pour but d’enlever certaines croyances que j’entends encore aujourd’hui dans les équipes Scrum que le Sprint Démo est une cérémonie indispensable définie par le Scrum Guide…
Si la démo est intéressante en cours de review, c’est dans le but d’avoir une meilleure visibilité du produit ; cela ne doit pas remplacer le but premier de la sprint review : faire un point sur l’avancement du produit et de récupérer un maximum de feedback constructifs.
Le Scrum Guide est consultable en ligne gratuitement dans de nombreuses langues différentes, si vous désirez le lire.
Rien ne vous interdit d’adapter une cérémonie mais il est intéressant de connaitre les origines de celle-ci afin de mieux comprendre la méthodologie dans son ensemble.
Bonjour et merci pour cet article, lors d’une review, j’ai eu le malheur de montrer 2 slides sur notre « nouvelle façon de fonctionner » (comment on définit ce qui ira aux prochains sprint) et rassurer les personnes présentes sur le fait qu’on les intègre en amont, ainsi que les utilisateurs. Je suis UX specialist. Cette présentation a été bien accueillie. Elle a duré 5 à 8 min. Par contre en Rétrospective, certains dev ont déclaré que ça n’avait rien à faire là : « on doit montrer ce qu’on a dev, point ! » « c’est une réunion dans la réunion ». « il aurait fallu faire une réunion à part pour ça ».
Pouvez-vous me donner votre avis ?
Parce que réunir ces mêmes personnes à un autre moment est très difficile.
Merci d’avance,
La review ne permet pas que de présenter ce qui a été développer mais de aussi faire un point sur l’état d’avancement par rapport à un projet global. Il est parfaitement possible d’expliquer le nouveau fonctionnement surtout si le but est de rassurer les personnes invités.
Attention, la review ce n’est pas « on doit montrer ce qu’on a dev, point ! », c’est le Product Owner qui présente tout ce qui a été réalisé en cours de sprint pour délivrer de la valeur : « développement, recherche, travail sur une offre… ». Faire un point sur l’état d’avancement sur le projet prévu est également à ne pas oublier car le Product Owner doit présenter une vision et non que le sprint seul.
Je conseille par contre fortement de faire simple et concis (que ça ne prenne pas beaucoup de temps) ; ce n’est pas évident d’expliquer quelque chose sans que ça se transforme pas en nouveau débat. Vous pouvez profiter de cette présentation concise, de vous proposer de vous mettre à disposition pendant le sprint suivant pour donner plus de détail.
Dans le passé lointain, quand j’étais Scrum Master, je faisais passer (ou le PO) des messages intéressants justement lors de la review de façon concise et je me proposais d’aller voir chacun des invités intéressés plus tard.
Il n’y a pas un format parfait de la review, vous pouvez l’adapter si besoin. Je conseille juste de garder un format court (1h max) afin que les invités ne se désistent pas les fois suivantes parce qu’ils pensent que ça prend trop de temps.