Revues de sprint (SP1 - SP4)

Objectifs des revues

Les revues ont pour but de faire le bilan d’un sprint. L’équipe de développement présente les éléments réalisés et finalisés pendant le sprint afin de discuter des résultats obtenus et éventuellement de faire évoluer le produit final.

Une revue est l’occasion de voir l’avancée concrète du produit et de discuter les directions suivies. Pour les développeurs, c’est le moment de faire le bilan du sprint : finaliser un élément produit et analyser sa méthode de travail pour améliorer le sprint suivant.

D’un point de vue pédagogique, les enseignants évaluent les capacités des étudiants à s’exprimer en anglais, l’avancement du projet et la gestion du projet.

Planning et salle

 Vous devez assister à toutes les revues. Elles sont ouvertes à tous. 

Organisation

Tous les membres de la promo doivent participer à toutes les revues.

Le scrum master n'est pas obligé de parler à la revue.

Les revues doivent suivre les contraintes suivantes :

• toutes les discussions et les supports sont entièrement en anglais (questions en français à la marge possible),

• La revue se déroule sur 30 minutes pour présenter le résultat du sprint. Ce temps inclut les discussions (comptez sur 20 min pour vous et 10 min d'interaction, tout cela pouvant être entre-mêlé),

• La revue commencera par un rappel succinct du projet et de l'objectif du sprint, ainsi que la présentation de l'organisation du sprint.

• Le reste de la durée de la revue est consacrée à la présentation par chaque équipe dans l'ordre qu'elle préfère, des points suivants:

  • stories prévues/réalisées, tests d'acceptation

  • Démonstrations (pensez à TOUJOURS avoir une vidéo de back up si la démo ne marche pas) (TAs, DoD pour toutes les stories)

  • schedule control: points estimés vs points réalisés (vélocité vs capacité),

• La fin de la revue présentera brièvement le sprint suivant (stories, tâches planifiées avec évaluation des points), réorganisation des équipes si nécessaire.

Conseils à suivre :

• nommer un "time keeper" qui gère le temps et les imprévus de présentation (parler avec les clients en cas de soucis de projecteur, de démo, etc)

• le produit réalisé pendant le sprint doit être présenté (démonstration, documents, tests finis, etc.) et ouvrir à discussion.

• Le produit est le livrable, il doit être utilisable

• La revue est faite pour parler avec les clients de l’avancée du produit.

• La revue n'est pas faite pour exposer en détail les aspects techniques. Les réunions hebdomadaires avec les tuteurs projet sont là pour ça.

• votre objectif est de recueillir un feedback sur le produit

Conseils

La suite est extrait des considérations du blog de Claude Aubry.

Une revue d’un sprint permet un feedback concret sur le produit (c’est mieux que sur de la

documentation). 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 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 obtenue comme

résultat du sprint

Etapes

1. Préparer la démonstration : La préparation de la réunion consiste à imaginer un scénario pour présenter les différentes stories 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.

2. 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 stories initialement sélectionnées.

3. 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 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.

4. Évaluer les résultats du sprint : 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.

5. 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é.

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 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 stories inachevées sont montrées

• la démonstration est trop rapide et ne permet pas à toutes les personnes de suivre

• la/les démonstrations ne met pas en évidence toutes les stories réalisées pendant le sprint

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