Bienvenue à la Sprint Review, où le sprint se termine, et les développeurs tentent de convaincre tout le monde que ‘Done’ signifie ‘parfait’, même si ça ressemble encore un peu à ‘en développement‘ 😄
La Sprint Review est une cérémonie Scrum qui se déroule à la clôture de chaque sprint. Elle représente le travail engagé lors du sprint planning. Elle a plusieurs objectifs, notamment :
- Examiner le travail accompli au cours du sprint en présence du Product Owner et des Key Users.
- Présenter les résultats obtenus à l’issue du sprint.
- Favoriser les échanges et la discussion entre les différentes équipes impliquées dans le projet.
- Responsabiliser l’équipe de développement en l’incitant à présenter elle même le travail fait.
- Obtenir un feedback immédiat de la part des parties prenantes (Stakeholders).
Point Clès
Cet article sur la Sprint Review vous dévoilera les moments opportuns pour sa tenue, les acteurs clés qui y participent, les phases essentielles du processus, et se conclura par une série de recommandations et de conseils pratiques.
Quand Faut-il Faire la Sprint Review ?
Les principaux éléments d’une sprint review sont:
Fréquence
Le dernier jour de chaque Sprint et juste avant la Rétrospective.
Il est important de maintenir la régularité de la Sprint Review en la tenant à la fin de chaque sprint, ce qui contribue à maintenir un flux de travail efficace.
Durée
Maximum 1h par semaine de Sprint. Mais au-delà de 2h, ce peut être compliqué :
- D‘avoir les utilisateurs finaux.
- De conserver la motivation et la concentration.
Inputs
Les inputs de la Sprint Review incluent principalement :
- Incréments de produit et de sprint : Les User Story et les tâches effectuées au cours du sprint.
- Critères d’acceptation : Les critères définis pour chaque élément du sprint.
- Documentation : Toute documentation pertinente, telle que des rapports de tests ou des spécifications techniques.
- Kanban Board ou Tâches : Les tableaux Kanban ou les tâches individuelles mises à jour.
Outputs
Les outputs (résultats) de la Sprint Review incluent :
- Feedback et commentaires : Les commentaires des parties prenantes, y compris le Product Owner, sur les fonctionnalités présentées.
- Éventuels changements au Product Backlog : Des ajouts, des modifications ou des suppressions d’éléments du Product Backlog.
- Validation des objectifs du sprint : La confirmation que les objectifs du sprint ont été atteints, ou des ajustements si nécessaire.
Agilité: Lire Aussi
Qui Participe à la Sprint Review?
Les parties prenantes (Stakeholders) :
Evaluateur
Telles que les utilisateurs clés, les membres de l’entreprise ou les clients, peuvent être invitées à la Sprint Review pour examiner les résultats et fournir des feedbacks.
Dev Team
Réalisateurs
L’équipe qui a travaillé sur les fonctionnalités et les éléments de travail du sprint est présente pour présenter les User Story réalisées et démontrer le travail accompli.
Product Owner
Sponsor
Le Product Owner, en tant que représentant des parties prenantes et détenteur de la vision du produit, est essentiel pour évaluer les fonctionnalités développées et fournir des commentaires.
Scrum Master
Facilitateur
Le Scrum Master facilite la Sprint Review, mais il n’est pas un participant actif dans le sens de fournir des commentaires sur le travail accompli.
Business Analyst
Contributeur
L’analyste métier peut apporter une expertise en matière de besoins et de spécifications métier. Sa participation peut aider à s’assurer que les fonctionnalités développées correspondent aux exigences métier et aux objectifs du produit.
QA Lead (Responsable de l'Assurance Qualité)
Contributeur
Le responsable de l’assurance qualité peut examiner les fonctionnalités développées sous l’angle de la qualité et de la conformité aux normes. Sa présence peut aider à identifier des problèmes de qualité potentiels et à s’assurer que le travail accompli est conforme aux critères d’acceptation.
Exemple de Sprint Review en Trois Étapes : Préparation, Présentation, et Feedback
Prérequis
La veille de la Sprint Review réservez un créneau pour dérouler les scénarios de la présentation sur un serveur d’intgération et s’assurer que l’application ne bug pas.
Etape 1 : Préparation (15 minutes)
15 Minutes : pour revoir / préparer les éléments suivants :
l’équipe Scrum se prépare en envisageant des scénarios pour présenter les différentes User Stories qui ont été implémentées dans l’incrément du Sprint. Il est important de noter que seules les User Stories qui sont considérées comme ‘Done‘ sont incluses dans l’incrément.
L’équipe vérifie que tout le matériel nécessaire à la démonstration est opérationnel (Connexion, Projecteur, Tableau..etc)
Elle effectue un calcul de la vélocité réelle en additionnant les Story Points associés aux fonctionnalités ‘Done.’
Important !
Une fonctionnalité partiellement terminée ne rapporte aucun story point, car elle n’est pas encore utilisable.
Etape 2 : Démonstration (45 minutes)
45 Minutes pour dérouler la présentation de l'application en suivant ce modèle :
- Le Product Owner commence par rappeler l’objectif du Sprint.
- Ensuite, la Scrum Team présente les indicateurs du Sprint, notamment:
- les KPI tels que la burndown chart, la vélocité du Sprint, les comparaisons par rapport à l’engagement initial en début de Sprint.
- un bilan des User Stories considérées comme ‘Done‘, ainsi que les événements marquants du Sprint qui peuvent aider à expliquer les résultats obtenus.
- L’équipe de développement prend le relais en présentant les fonctionnalités considérées comme ‘Done‘ et engage un échange avec les Stakeholders.
Etape 3 : Feedback (15 minutes)
15 Minutes pour recueillir le feedback des utilisateurs
Le Product Owner et les Stakeholders offrent leur feedback à l’équipe de développement.
Il est important de noter que le Product Backlog peut être mis à jour en fonction de ces commentaires.
Le rôle du Scrum Master est crucial à ce stade, car il doit guider les parties prenantes pour donner un feedback constructif et positif.
Enfin, le Product Owner prend la décision d’accepter ou de refuser les fonctionnalités présentées.
Etape 4 (facultative) : Ajuster le Plan de Release
La réalisation de cette étape dépendra de l'appréciation de l'équipe projet quant à son importance.
- Analyse des indicateurs globaux projet :
- Vélocité moyenne, évolution de la vélocité, Burn Down Chart cumulé…
- Analyse de l’état du Product Backlog
- En particulier suite aux feedbacks utilisateurs et aux éventuels nouveaux besoins intégrés dans le Product Backlog pendant le Sprint.
- A partir de ces éléments, vérifier s’il faut mettre à jour le Release Plan.
- Les Stakeholderss sont impliqués dans cette étape, afin de renforcer la transparence et la confiance.
- Si une mise à jour mineure du Release Plan est nécessaire, la faire en séance. Si une discussion plus poussée s’impose, prévoir une réunion dédiée.
- Dans tous les cas, confirmer le Release Plan aux Stakeholders.
Conseils et astuces
Féliciter l'équipe
Féliciter toute l’équipe à la fin de la sprint review, cela donne un sentiment d’estime et de reconnaissance de l’effort fourni pendant le Sprint.
Quoi et pas Comment
Se concentrer sur « ce que nous avons fait » plutôt que sur « comment nous l’avons fait » pour éviter des considérations techniques qui alourdissent inutilement la Sprint Review.
Revue à blanc
Si l’équipe n’est pas à l’aise, organiser une revue à blanc avant la sprint review.
Essayage
Si possible, laisser le Product Owner et les utilisateurs finaux essayer eux-mêmes le produit.
Captiver l'attention
Utiliser une approche de storytelling ou de scénario peut être captivant, car cela permet à chaque représentant métier de s’identifier à l’utilisation du produit.
Resonsabiliser l'équipe
Privilégier le pilotage de la réunion par les membres de l’équipe pour partager la responsabilité.
Focus sur ce qui marche
Ignorer ce qui ne marche pas et se concentrer sur la démonstration du code qui marche.
Clarifier l'objectif
Avant de plonger dans la Sprint Review, assurez-vous de clarifier l’objectif du Sprint. Si des participants ne sont pas familiers avec le produit, prenez quelques minutes pour leur offrir une brève présentation. Cela garantira une compréhension commune et une réunion plus productive.
0 commentaires