En ce moment En ce moment
Méthodologie

La boîte à outils du chef de projet
Chapitre VII : La méthode Scrum

Fiche 10 : La revue de sprint

  • Retrouvez 12 fiches outils dans ce chapitre
  • Publié le 1 sept. 2016
©

La boîte à outils du chef de projet

7 chapitres / 74 fiches

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.

  • Imprimer

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

La revue vise à " démontrer " ce qui a été réalisé pour mieux préparer la suite du projet.

  • 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 !

Avantages

  • C'est la réunion essentielle sur le produit : elle permet de supprimer les " comités " (de pilotage, de suivi...).
  • Cette réunion permet d'éviter de faire un compte-rendu fastidieux sur l'état d'avancement du produit, dans la mesure où l'ensemble des parties prenantes en ont vu une démonstration en direct.

Précautions à prendre

  • Parler des stories (ce qui a été livré), et pas des tâches (ce qui a été fait).
  • Solliciter un maximum de feedbacks pour enrichir le backlog de produit.

Jérôme MAES, François DEBOIS © Dunod

Martine Fuxa,<br/>rédactrice en chef Martine Fuxa,
rédactrice en chef

La Lettre de la Rédac

Recevez l'essentiel de l'actu

E-commerce

Small Business

Event