Contexte: La revue de sprint fait partie des 4 événements Scrum.
Objectifs: Présenter le travail terminé durant le sprint aux parties prenantes, collecter le feedback et mettre à jour le plan de release.
Participants: L’équipe de dev, le scrum master, le product owner. Les parties prenantes sont invités et leur participation est vivement encouragée.
Préparation de la revue
- L’équipe de développement prépare la démo des story
- Le Product Owner invite les parties prenantes en leur partageant le programme de la revue de sprint
Déroulement de la revue
Le Product Owner rappele l’objectif du sprint
En utilisant le produit de fin de sprint (incluant des items répondant à la définition de ‘fini’), l’équipe montre l’avancement. Les parties prenantes peuvent poser des questions ainsi que manipuler le produit.
Le feedback est ensuite sollicité (bug, amélioration mineures, …)
En fonction des retours, la vélocité est calculée.
Le burdown de release est montré et le plan de release est ajusté (le cas échant).
De mon coté, j’en profite également pour montrer d’autres graphiques comme le suivi de la dette technique ou des bugs. Ces graphiques sont souvent demandés par l’équipe et les parties prenantes.
Durée: 1h par semaine de sprint
A éviter:
- Préparer des vidéos ou des documents formelles au lieu de montrer le produit
- Ne pas collecter le feedback
- La démonstration n’est pas réalisée par l’équipe de développement
- Les parties prenantes sont toujours absentes
- Le PO n’est pas présent
Conclusion
La revue de sprint permets de montrer l’avancement en utilisant le produit et échanger avec les parties prenantes. Il faut être vigilant sur son organisation et le timing pour mettre les parties prenantes dans les meilleures conditions pour qu’elles soient le plus souvent possible présentes. Leur feedback étant une mine d’information pour réaliser le bon produit.
scrumontherocks.wordpress.com 