Après chaque sprint, il est important de savoir comment organiser une Sprint Review pour que l’équipe et les parties prenantes échangent et évaluent les tâches terminées.
Un élément clé de cette réunion implique la démonstration des résultats des fonctionnalités développées lors du Sprint.
Mais il est important de comprendre que la démonstration n’est pas le seul objectif de la réunion.
Voyons ce qu’il faut mettre en place pour mener une Sprint Review réussie.
Qu’est ce qu’une Sprint Review ?
La Sprint Review ou démo de sprint est une des cérémonies du cadre méthodologique Scrum.
En savoir plus sur les rituels de Scrum.
Elle sert à optimiser la valeur du produit et à créer de la transparence entre l’équipe Scrum et les parties prenantes au sujet du Product Backlog et l’incrément de produit.
En savoir plus sur le Backlog et l’incrément produit.
Cependant l’objectif de la Sprint Review n’est pas seulement de fournir une mise à jour de la roadmap ou une présentation aux parties prenantes.
Il s’agit de collecter et de traiter les commentaires sur le travail réalisé.
«Il s’agit d’une réunion informelle, pas d’une réunion de mise en état, et la présentation de l’incrément vise à susciter des feedbacks et à favoriser la collaboration.»
La sprint review a lieu à la fin du sprint juste avant la rétrospective et le Sprint Planning.
La durée de l’échange ne doit pas dépasser une heure et elle nécessite une bonne maîtrise pour être vecteur de succès, nous allons découvrir pourquoi.
L’importance du succès de la Sprint Review
Les retours utilisateurs sont un des éléments clés de la culture Agile.
Il est donc bien entendu essentiel de pouvoir collecter ces feedbacks durant les sprints Scrum.
En savoir plus sur la culture Agile.
En donnant la possibilité aux équipes de montrer l’incrément produit réalisé pendant l’itération, on permet aux parties prenantes de pouvoir clarifier le besoin utilisateur.
Il est essentiel que la réunion soit participative.
En utilisant les commentaires obtenus lors de cette réunion, le Product Owner (PO) est en mesure d’adapter le backlog produit pour atteindre les objectifs de chacun.
En savoir plus sur les différents rôles de Scrum.
Le but de cette rencontre est donc simple: revoir, évaluer et adapter à partir du sprint précédent.
Voyons ensemble les étapes à suivre pour réussir sa Sprint Review.
La revue de Sprint : déroulé de la réunion
Chacun peut organiser une Sprint Review à sa manière.
Il est encore plus appréciable si vous l’adaptez au fur et à mesure avec ce qui fonctionne pour vous et vos équipes.
Un seul conseil, tenez vous à un timing précis pour que la réunion ne soit pas trop longue et reste structurée.
Voici un exemple de comment organiser une sprint Review :
Le PO accueille les parties prenantes et les équipes.
Il rappelle le(s) objectif (s) de sprint et l’engagement pris par l’équipe lors du dernier Sprint Planning.
Il peut aussi partager les événements pertinents qui ont eu lieu durant l’itération.
Toutefois, prenez le soin de vous concentrer sur l’incrément produit et le travail effectué. N’abusez pas de cette réunion pour des mises à jour managériales ou opérationnelles.
Le Scrum Master présente l’agenda de la Sprint Review. Il rappelle que l’équipe a besoin de feedbacks et qu’elle respecte un calendrier précis.
Il incite activement les personnes à échanger, commenter et débattre.
Pour chaque fonctionnalité présentée, un membre de l’équipe de développement réalise un court pitch (une sorte de résumé).
Personnellement, j’aime bien leur laisser la responsabilité d’introduire et de démontrer le travail qu’ils ont réalisé. Je trouve que cela est très engageant et gratifiant pour chacun d’entre eux.
Cependant, certains peuvent ne pas être à l’aise à l’oral ou au contact des parties prenantes. S’ils n’ont pas le souhait de présenter leur travail c’est au PO de le faire.
Une fois la tâche expliquée et exposée, les parties prenantes doivent prendre 1 à 2 minutes pour réfléchir et noter leurs commentaires.
Ensuite, le PO leur demande ce qu’ils ont appris et s’ils ont des remarques. Il ne faut pas hésiter à choisir une personne au hasard pour lancer les échanges.
Si il n’y a ni discussion active, ni commentaire, il faut continuer à interpeller des membres au hasard pour partager leurs ressentis.
Le PO doit s’assurer qu’un mélange pertinent de personnes se sont exprimés afin de récolter le maximum de feedbacks.
Le PO résume les commentaires pertinents recueillis.
Si possible, il partage son avis sur les retours et explique ses choix.
Enfin, le PO remercie tout le monde pour sa contribution et rappelle la date de la prochaine Démo de Sprint.
4 astuces pour organiser une Sprint review réussie
1) Préparer votre réunion
Cette réunion vous permet de rencontrer une fois par sprint vos parties prenantes.
Il est essentiel qu’elle soit fluide et agréable pour favoriser les échanges et les retours utilisateurs.
De ce fait, je vous conseille de bien préparer ce rituel.
Généralement, je prends le temps, les jours précédents, de noter dans un endroit accessible les éléments dont je vais avoir besoin lors de la démonstration:
Imaginons que l’équipe travaille sur une application bancaire et qu’une fonctionnalité de modification des informations du profil va être présentée lors de la Sprint review.
Dans ce cas je prépare le scénario de test suivant :
2) Rendre la réunion informelle… aux yeux des participants
Les gens ignorent souvent le fait que la Sprint Review est une réunion informelle.
Il ne devrait pas s’agir, à première vue, d’une présentation PowerPoint travaillée pendant des heures.
Cela devrait être un résultat naturel du Sprint. Cependant gardez à l’esprit que pour faciliter les échanges, vous devez avoir préparé les éléments nécessaires à la démo.
Assurez-vous qu’il n’y a pas de longs discours qui pourraient se poursuivre sans fin.
La Sprint Review est une question de collaboration et l’atmosphère doit la faciliter.
Si les gens se sentent suffisamment à l’aise, ils partageront leurs idées et donneront des commentaires qui mèneront à une revue de sprint réussie.
3) Inclure les bonnes personnes pour obtenir les bons commentaires
Laissez moi partager avec vous un fait : si toutes vos Sprint reviews se terminent par une salve d’applaudissements et sans questions ou commentaires…ne vous en vantez pas !
Cela signifie que votre revue de Sprint est un échec.
La collecte de commentaires est cruciale pour prendre les bonnes décisions concernant votre produit.
Si vous n’obtenez pas de feedbacks, vous conduisez votre produit à l’échec. Vos décisions ne seront pas centrées sur les retours utilisateurs mais sur vos opinions.
Les personnes qui doivent participer à vos Sprint reviews sont :
L’objectif principal est d’essayer d’obtenir des commentaires de qualité que vous pouvez utiliser pour vous améliorer dans les sprints suivants, alors incluez tous ceux dont les commentaires vous sont précieux.
4) Notez toutes les suggestions, mais ne prenez pas de décisions hâtives
Je vous ai dit ci-dessus de créer une atmosphère informelle pour favoriser l’échange de commentaires.
Il y a un revers de la médaille qu’il faut être prêt à maîtriser.
Si votre Sprint Review est réussie, les retours utilisateurs vont fuser à grande vitesse. Les participants vont vous exposer tous leurs avis et opinions.
Assurez-vous de noter toutes les suggestions, même si vous décidez plus tard de ne pas les intégrer dans le sprint.
Rappelez-vous que ce sont des suggestions pas des ordres.
Vous restez le maître de votre produit.
Soyez prudent lorsque vous prenez la décision de modifier votre backlog produit.
Si les feedbacks entraînent des changements importants dans le Backlog, ne faîtes pas de modifications drastiques avant de les analyser avec l’équipe de développement après la réunion.
En conclusion
Vous savez à présent comment organiser une Sprint Review réussie ! Cependant, comme beaucoup d’éléments dans un projet Agile, le succès de la Sprint Review dépend de la volonté et l’engagement des participants.
Cela nécessite une approche différente des réunions classiques, ainsi qu’un niveau de transparence qui peut être un défi pour de nombreuses organisations.
Dîtes moi en commentaire si vous luttez avec vos parties prenantes lors de vos démos ou si l’équipe de développement redoute ces revues de sprint.
