La sprint review n’est pas une démo !

Ecrit par << Paquet Judicaël >>

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 et 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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.