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.
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.
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.
Modèle du Sprint Review (+ 25 Templates)
Evaluez l'avancement de votre produit
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.» Le Scrum guide
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.
Il est important de noter que certaines équipes pourraient percevoir cette cérémonie, entre autres, comme étant chronophage.
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 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.
Ceci contribue également à identifier et prioriser la dette technique.
Voyons ensemble les étapes à suivre pour réussir sa Sprint Review.
Modèle de la Sprint Review
Evaluez le lancement de votre projet
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 :
5 minutes de bienvenue
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.
Introduction de 5 minutes
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.
5 minutes de présentation par nouvelle fonctionnalité
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.
Prévoir 10 minutes d’échanges pour chaque fonctionnalité présentée
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.
S'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.
Garder 15 minutes de conclusion
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:
- Les identifiants et mots de passe des différents cas de tests pour accéder du produit,
- Les différentes fonctionnalités qui vont être présentés avec leurs objectifs,
- Le scénario que je (ou l’équipe de développement) vais emprunter durant la réunion. Je veux dire par là, que je prépare de manière visible les boutons sur lesquels je dois cliquer, les informations que je dois renseigner, les pages que je dois visiter pour montrer l’incrément produit.
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 :
- Connexion avec l’identifiant et mot de passe,
- Aller dans “Mon profil”
- Présentation des informations du cas de test,
- Capture d’écran des anciennes informations (pour pouvoir montrer le changement)
- Modification de l’adresse du cas de test avec : une rue, un code postal et une commune déterminés à l’avance pour ne pas laisser place à l’improvisation.
- Enregistrement des nouvelles informations,
- Présentation des nouvelles informations bien enregistrées,
- Déconnexion et fermeture de l’application,
- Reconnexion avec le même cas de test,
- Présentation des informations modifiées correctement affichées.
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 tous 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 :
- Celles qui s’intéressent à votre produit.
- Celles qui ont des avis tranchés et des suggestions qui aideront à faire avancer le produit.
- Celles qui ne comprennent pas le produit pour challenger vos idées.
Si ces personnes sont issues d’une unité totalement différente de votre entreprise, c’est encore mieux. Elles n’auront pas le jargon et exposeront des remarques très pertinentes. Par exemple, si vous développez une application bancaire avec un objectif de simplifier les démarches, invitez dans votre démo de sprint une personne qui utilise très peu son téléphone portable ou les applications. - Celles qui vont entendre parler du produit sans réellement travailler dessus. N’hésitez pas à inclure des personnes, des ventes, du marketing etc.
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.
