Fiche 10 : La revue de sprint

L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. L'équipe commence par énoncer les items du carnet de produit qu'elle a réalisés. Elle effectue ensuite une démonstration du logiciel produit. C'est sur la base de cette démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint. Une fois le bilan du sprint réalisé, l'équipe et le propriétaire de produit proposent des aménagements sur le carnet du produit et sur la planification provisoire de la release. Il est probable qu'à ce moment des items soient ajoutés, modifiés ou ré-estimés, en conséquence de ce qui a été découvert.

Schéma de la validation de la solution qui a été produite pendant le sprint

Pourquoi l'utiliser ?

Objectif

• Valider l'incrément de solution (et la solution globale qui en découle !) qui a été produit pendant le sprint.
• Connaître l'état d'un projet, afin de décider des actions à mettre en oeuvre pour sa poursuite.

Contexte

La revue de sprint se déroule à la fin de chaque sprint, et dure au maximum 4 heures pour les sprints d'1 mois (2 heures pour ceux de 2 semaines).

Comment l'utiliser ?

Étapes

• Préparer la démonstration : vérifier que toutes les conditions matérielles et logistiques sont réunies pour pouvoir procéder à une démonstration probante de ce qui a été livré (ex : connexions réseau si nécessaire), et imaginer un scénario de démonstration le plus proche possible d'une situation de production réelle.
• Réunir l'équipe étendue (dont le Scrum master et le product owner), ainsi que l'ensemble des parties prenantes concernées par le projet.
• Rappeler les objectifs du sprint : c'est au product owner de rappeler la liste des stories qui figuraient dans le périmètre prévu lors de la réunion de planification de sprint.
• L'équipe commence alors par énoncer les items du carnet de produit qu'elle a réalisés.
• Elle effectue ensuite une démonstration du logiciel produit, story par story. C'est sur la base de cette démonstration que le product owner valide chaque fonctionnalité planifiée pour ce sprint. Les participants de cette revue peuvent poser des questions et transmettre leur feedback à l'équipe. Les propositions/demandes de changement qui émanent de ce feedback viendront enrichir le backlog de produit.
• Calculer la vélocité du sprint en faisant la somme de tous les points attribués à chaque story finie.
• Une fois le bilan du sprint réalisé, l'équipe et le product owner proposent des aménagements sur le carnet du produit et sur la planification provisoire de la release. Il est probable qu'à ce moment des items soient ajoutés, modifiés ou ré-estimés, en conséquence de ce qui a été découvert.

Méthodologie et conseils

• Il est bon d'inviter un maximum de parties prenantes, tout en expliquant que c'est à la démonstration d'un produit partiel (et peut-être imparfait !) à laquelle elles vont assister. S'il existe un risque de frustration par rapport à ça, le mieux est de les former à Scrum !
• Seules les stories complètement finies sont présentées lors de cette revue de sprint, ce qui permet d'avoir un bon indicateur de l'avancement du projet.
• Il est conseillé que ce soit le product owner qui procède lui-même à la démonstration de chaque story : c'est un excellent moyen de l'impliquer en amont !