La revue de sprint

Une revue qui permet un feedback concret sur le produit (c'est mieux que sur de la documentation).

Dans la série des réunions d'un projet Scrum, voici la revue de sprint.

Le but de la revue est de montrer ce qui a été réalisé pendant le sprint afin d'en tirer les conséquences pour la suite du projet.

Participants

  • L'équipe Scrum étendue, avec le ScrumMaster et le ProductOwner, est présente à la réunion. Toutes les personnes qui sont partie-prenantes[1] du projet y sont invitées et leur présence encouragée.

Produit en entrée

  • le produit partiel potentiellement livrable. C'est la version opérationnelle[2] obtenue comme résultat du sprint

Etapes

  • Préparer la démonstration

La préparation de la réunion consiste à imaginer un scénario pour présenter les différentes histoires d'utilisateur qui seront présentées et à vérifier que le matériel utilisé pour la démonstration fonctionne bien. La revue de sprint ne nécessite pas une présentation formelle.

  • Rappeler les objectifs du sprint

Le ScrumMaster rappelle le but du sprint défini lors de la réunion de planification. Il donne la liste des histoires d'utilisateur sélectionnées.

  • Effectuer la démonstration

L’équipe présente le produit partiel résultat de ses travaux en faisant une démonstration des éléments du backlog de produit (histoires d'utilisateur) réalisés. Seules les histoires d'utilisateur complètement finies[3] sont présentées. Cela permet d’avoir une mesure objective de l’avancement. La démonstration est faite par un ou plusieurs membres de l'équipe, en principe les plus impliqués dans les choses montrées. Si possible, les personnes présentes à la réunion sont aussi invitées à manipuler le produit.

  • Evaluer les résultats du sprint

Le Product Owner et les intervenants présents posent des questions à l’équipe et donnent leur impression sur le produit montré. Leur feedback se concrétise en propositions et demandes de changement. Le backlog de produit est enrichi avec les éventuels bugs découverts et les demandes d’évolution suggérées.

  • Calculer la vélocité réelle

La liste des éléments du backlog considérés comme finis est établie. La vélocité du sprint est obtenue en faisant la somme de tous les points attribués à ces éléments. Elle est comparée à celle des sprints précédents, pour obtenir une vélocité moyenne.

  • Ajuster le plan de la release

Les conditions ont changé depuis la dernière planification de la release : des éléments ont pu être ajoutés ou supprimés, les estimations modifiées, l'ordre dans lesquels les éléments sont classés (la priorité) a pu être modifié. De plus la vélocité moyenne a pu évoluer.
Le Planning de la release est ajusté en tenant compte de ces nouveaux paramètres. Le burndown chart de la release est produit. Avec cette mesure objective de l'avancement, il est possible de prendre une décision sur la date de la mise en production de la release.

Produit en sortie

Le backlog de produit actualisé, avec le plan de release mis à jour et son burndown chart

Considérations de timing

  • La préparation de la démonstration ne devrait pas excéder une heure.
  • La revue elle-même est limitée à 2 heures et dure en moyenne une heure.
  • La revue a lieu à la fin du sprint et elle est suivie de la rétrospective.

Erreurs à éviter

Avant la réunion

  • l'équipe modifie le code au dernier moment et présente une version mal testée

Pendant la démonstration

  • des histoires d'utilisateur inachevées sont montrées
  • la démonstration est trop rapide et ne permet pas à toutes les personnes de suivre
  • la démonstration ne met pas en évidence toutes les histoires d'utilisateur réalisées pendant le sprint

Voir aussi ce billet qui donne plus de détails.

Après la démonstration

  • le feedback n'est pas sollicité
  • le backlog de produit et le plan de release ne sont pas mis à jour

Notes

[1] stakeholders incluant les clients, utilisateurs, sponsors...

[2] build

[3] selon la définition de fini élaborée par l'équipe