À la fin d’un sprint, une liste de tickets ne suffit pas toujours à faire comprendre les résultats. La revue permet de les examiner avec les parties prenantes et de discuter des adaptations utiles pour la suite.
La Sprint Review est une séance de travail collaborative. Une démonstration ou quelques diapositives peuvent la soutenir, mais le support doit laisser de la place aux questions et à l’inspection du produit.
Voici comment préparer les informations, la démonstration et les échanges, avec Presenti si un diaporama est utile.
Partie 1 : Définir l’objectif de la Sprint Review
Selon le Scrum Guide, la Sprint Review sert à inspecter le résultat du sprint et à déterminer les adaptations futures. La Scrum Team et les parties prenantes examinent les progrès vers l’objectif de produit et les changements de contexte ; le Product Backlog peut être ajusté.
Expliquez les travaux techniques dans leur contexte. Une refonte d’API ou une migration de données peut répondre à un besoin de fiabilité, de maintenance ou d’évolution, même si elle n’a pas de nouvel écran à montrer.
Un support visuel peut relier le besoin, le changement et les observations. Il reste facultatif : choisissez le format qui facilite le mieux la discussion, sans consacrer une part disproportionnée du sprint à sa mise en page.
Partie 2 : Presenti : L'Allié IA du Scrum Master et du Product Owner
Presenti peut aider à organiser un résumé et à produire une première version des diapositives. Préparez les faits et les questions à discuter avant de générer le support.
Les crédits gratuits permettent un essai limité. Vérifiez les quotas, les exports et les règles de votre organisation avant de partager des informations sur le produit ou les clients.
Choisissez un modèle lisible pour les captures, les schémas et les questions. Plusieurs modes peuvent servir de point de départ :
- Sujet vers Présentation : Vous manquez d'inspiration pour structurer la réunion ? Tapez simplement "Agenda Sprint Review Scrum" et l'IA génère la trame (Introduction, Rappel des objectifs, Démo, Métriques, Feedback).
- Fichier vers Présentation : Si votre offre permet l’import Word/PDF, utilisez une synthèse autorisée des travaux et comparez les diapositives au document source.
- Texte vers Présentation : Idéal pour copier-coller rapidement les points clés d'un email ou d'un ticket Jira.
- Lien ou Plan vers Présentation : Partez d’un plan ou d’une page accessible. Pour une page privée de Confluence ou Notion, préparez un extrait autorisé : la simple URL ne garantit pas l’accès au contenu.
Si vous utilisez une proposition de remise en forme, vérifiez les captures, les légendes et les informations de statut. La présentation doit rester fidèle au produit.
Partie 3 : Tutoriel : Préparer le support de revue en quatre étapes
Rassemblez les résultats du sprint, les éléments de démonstration et les questions à examiner. Les indicateurs présentés doivent aider à discuter du produit ; la vélocité n’est pas une mesure de valeur pour l’utilisateur.
Étape 1 : définir le plan. Indiquez le produit et le sprint, puis organisez le support autour de l’objectif, des résultats, des observations et des sujets à discuter. Ajustez le plan proposé par l’IA.
Étape 2 : ajouter les informations. Utilisez une synthèse autorisée des travaux terminés, avec les critères utiles à leur compréhension. Vérifiez les noms, les statuts et les limites plutôt que de reprendre automatiquement une diapositive par ticket.
Étape 3 : préparer la démonstration. Montrez le produit lorsque cela aide à l’inspection. Des captures ou un enregistrement peuvent compléter la démonstration ; indiquez leur contexte et leur version. Testez la lecture des médias dans l’environnement utilisé.
Étape 4 : tester le déroulement. Vérifiez la lisibilité et les liens, puis prévoyez le temps des échanges. Gardez une solution de secours pour les éléments de démonstration importants.
Partie 4 : Raconter l'Histoire du Produit : Contextualisation et Statut
Les deux distinctions suivantes permettent d’éviter les malentendus pendant la revue.
Le problème et le changement réalisé
Une comparaison avant/après peut montrer ce qui a changé dans un parcours. Décrivez le problème observé et l’effet attendu, puis ajoutez les mesures disponibles. Une interface plus simple en apparence ne prouve pas encore un gain d’usage.
La Definition of Done et le déploiement
Un élément qui ne satisfait pas la Definition of Done ne fait pas partie de l’incrément et ne doit pas être présenté comme tel à la Sprint Review. Précisez séparément son éventuel statut de déploiement : un incrément terminé n’est pas nécessairement déjà en production. Un badge « en test » ne remplace pas cette distinction.
Partie 5 : Discuter de la valeur et préparer les retours
Préparez les éléments qui permettront de discuter de la valeur, des observations et des prochaines adaptations.
Relier le travail à un résultat ou à une hypothèse
Expliquez l’effet recherché, par exemple réduire les demandes au support liées à la recherche. Si vous annoncez un objectif chiffré, précisez qu’il s’agit d’une hypothèse ou d’une cible et indiquez comment elle sera évaluée. N’inventez pas un pourcentage pour donner du poids à la démonstration.
Préparer une démonstration fidèle
Testez l’environnement et les données de démonstration. Un enregistrement de secours peut être utile, mais présentez-le comme tel. Ne faites pas passer un prototype ou un parcours simulé pour une fonctionnalité disponible.
Recueillir les retours et adapter la suite
Posez des questions précises sur les résultats et les changements de contexte. Notez les observations et les adaptations à examiner dans le Product Backlog. La revue ne remplace pas le Sprint Planning et ne doit pas être utilisée comme une simple validation du plan du prochain sprint.
Conclusion
Une revue utile permet d’examiner les résultats et de partager les informations nécessaires aux prochaines décisions. La qualité des échanges compte davantage que l’effet produit par les diapositives.
Gardez un support court et fidèle au produit, avec les éléments de détail disponibles si nécessaire. Faites évoluer son format en fonction des retours des participants.
Presenti peut aider à préparer les diapositives ; la Scrum Team et les parties prenantes donnent à la revue sa valeur par l’inspection et la discussion.
