Règles des cérémonies Scrum — Réunion de revue de sprint

La réunion de revue de Sprint est limitée à 4 heures.

• L’équipe ne doit pas consacrer plus d’une heure à la préparation de la revue de sprint.
• L’objectif de la revue de sprint est que l’équipe présente au Product Owner et aux parties prenantes les fonctionnalités réalisées. Bien que la signification de « terminé » puisse varier d’une organisation à l’autre, cela signifie généralement que la fonctionnalité est entièrement conçue et pourrait éventuellement être livrée ou implémentée. Si « terminé » a une autre
  signification, assurez-vous que le Product Owner et les parties prenantes la comprennent.
• Une fonctionnalité qui n’est pas « faite » ne peut pas être présentée.
• Les artefacts qui ne sont pas fonctionnels ne peuvent pas être présentés, sauf lorsqu’ils sont utilisés pour aider à comprendre la fonctionnalité démontrée.
  Les artefacts ne peuvent pas être présentés comme des produits de travail et leur utilisation doit être minimisée pour éviter de confondre les parties prenantes ou de les obliger à comprendre comment fonctionne le développement de systèmes.
• Les fonctionnalités doivent être présentées sur les postes de travail des membres de l’équipe et exécutées à partir du serveur le plus proche de la production, généralement un serveur d’environnement d’assurance qualité (QA).
• La revue de Sprint commence par un membre de l’équipe présentant l’objectif du Sprint, le Product Backlog engagé et le Product Backlog terminé. Différents membres de l’équipe peuvent alors discuter de ce qui s’est bien passé et de ce qui ne s’est pas bien passé dans le Sprint.
• La majorité de la revue de Sprint est consacrée aux membres de l’équipe présentant les fonctionnalités, répondant aux questions des parties prenantes concernant la présentation et notant les modifications souhaitées.
• A l’issue des présentations, les parties prenantes sont sondées, une à une, pour connaître leurs impressions, les éventuelles évolutions souhaitées, et la priorité de ces évolutions.
• Le Product Owner discute avec les parties prenantes et l’équipe de la réorganisation potentielle du Product Backlog en fonction des retours.
• Les parties prenantes sont libres d’exprimer leurs commentaires, observations ou critiques concernant l’augmentation de la fonctionnalité du produit potentiellement livrable entre les présentations.
• Les parties prenantes peuvent identifier les fonctionnalités qui n’ont pas été livrées ou qui n’ont pas été livrées comme prévu et demander que ces fonctionnalités soient placées dans le Product Backlog pour la hiérarchisation.
• Les parties prenantes peuvent identifier toute nouvelle fonctionnalité qui leur vient à l’esprit lorsqu’elles visualisent la présentation et demander que la fonctionnalité soit ajoutée au Product Backlog pour la hiérarchisation.

Articles sur les événements Scrum

• Qu’est-ce que la planification de sprint ?
• Qu’est-ce que la revue de sprint ?
• Qu’est-ce que la réunion rétrospective Sprint dans Scrum ?
• Qu’est-ce que le Product Backlog Refinement ?
• Qu’est-ce que l’Intégration Continue / Livraison / Déploiement dans Scrum ?
• Que sont les événements à durée limitée dans Scrum ?
• Qu’est-ce que Spike dans Scrum ?
• Qu’est-ce que le Planning Poker en Agile ?