Qu’est-ce qu’une revue de Sprint (Sprint review) ?

La Revue de sprint (Sprint review) est l’un des cinq événements du cadre Scrum. Cet événement permet à l’équipe Scrum et aux parties prenantes d’examiner les progrès accomplis dans la réalisation de l’objectif du produit et de déterminer les adaptations futures.

Comme tous les événements Scrum, la revue de sprint a lieu pendant le sprint lui-même. Elle ne se produit pas en dehors de la cadence du sprint.

Qu’est-ce qu’une Revue de sprint ?

C’est une réunion collaborative qui a lieu à chaque sprint. Cela dit, il n’est pas nécessaire de la considérer comme une “réunion” au sens traditionnel du terme. Cette réunion est en fait appelée un “événement” dans Scrum. Il existe cinq événements :

  • Le sprint
  • La planification du sprint (Sprint planning)
  • La mêlée quotidienne (Daily scrum)
  • La revue de sprint (Sprint review)
  • La rétrospective du sprint (Sprint retrospective)

Tous ces événements sont des occasions d’inspecter et d’adapter.

Vous devriez organiser une revue de sprint avant la rétrospective de sprint. De cette façon, l’équipe peut discuter librement de tout retour d’information qu’elle a reçu sur ses processus dans un environnement psychologiquement sûr.

Les revues de sprint ont une durée qui varie suivant la taille des sprints. Par exemple :

Durée du sprint Durée revue de sprint
4 semaines 4 heures
2 semaines 2 heures

La durée de la revue de sprint est un maximum : les équipes Scrum ne remplissent pas la totalité du temps si elles ont atteint leur objectif avant la fin.

Cet événement doit être plus qu’une simple présentation. C’est l’occasion pour l’équipe de scrum d’avoir une discussion avec les parties prenantes et d’obtenir un retour d’information précieux.

L’événement comprend, sans s’y limiter, les éléments suivants :

  • Inspection des résultats du sprint et questions sur les résultats
  • Inspection de la manière dont les résultats contribuent à l’objectif du produit
  • Inspection des conditions externes, telles que les conditions du marché
  • Inspection des contraintes internes, telles que les étapes, les budgets et les calendriers
  • Adaptations si nécessaire

Lors de la revue de sprint, l’équipe Scrum partage les résultats du sprint en cours avec les parties prenantes et les autres participants qu’elle a invités. L’équipe présente les éléments du backlog qui répondent à sa définition de réalisation (Definition Of Done) et discute des difficultés rencontrées. Cet événement permet de faire le point sur les progrès accomplis dans la réalisation de l’objectif du produit, sur les difficultés rencontrées et sur la marche à suivre.

Objectifs d’une revue de sprint

Les objectifs typiques d’une revue de sprint sont les suivants :

  • Partager les incréments et le travail : L’équipe de mêlée peut montrer les incréments de travail qu’elle a réalisés au cours du sprint, ce qui permet aux parties prenantes de voir les progrès accomplis. L’équipe peut également expliquer ce qui a changé dans son environnement et ce qui a pu limiter ses capacités dans les domaines où elle n’a fait que des progrès partiels.
  • Demander aux parties prenantes de faire part de leurs commentaires : L’événement ne doit pas se limiter à une démonstration de l’incrément. Cet événement permet aux parties prenantes de donner leur avis sur le travail et d’engager une discussion avec l’équipe Scrum. Il aide l’équipe à comprendre si elle avance dans la bonne direction et si elle doit faire des ajustements.
  • Mettre à jour le Product Backlog : Sur la base du retour d’information reçu, le Product Owner peut mettre à jour le Product Backlog pour refléter les nouvelles idées ou les changements nécessaires. Dans des cas extrêmes, l’ensemble du backlog peut être supprimé si l’orientation du développement du produit nécessite un tel changement.
  • Identifier les prochaines étapes : En collaboration, l’équipe de mêlée et les parties prenantes peuvent discuter et identifier les priorités, les besoins et les changements. Ces informations aident l’équipe de mêlée lors de son prochain événement de planification du sprint, au cours duquel elle crée un objectif de sprint et un plan pour l’atteindre.
  • Faciliter la collaboration : La revue de sprint favorise la collaboration entre l’équipe Scrum et les parties prenantes. Elle encourage une communication ouverte, permettant à l’équipe de comprendre les attentes des parties prenantes et de déterminer les prochaines étapes. Comme tous les événements Scrum, la revue de sprint est une occasion de transparence, d’inspection et d’adaptation – les trois piliers du processus empirique Scrum.

Qui doit assister à la revue de sprint ?

L’équipe Scrum y assiste : les développeurs, le Scrum Master et le Product Owner. La revue de sprint est ouverte à toutes les parties prenantes. Souvent, les équipes de mêlée invitent des personnes qui ont un intérêt dans le travail le plus récent qu’elles ont réalisé. L’équipe peut inviter des clients ou des utilisateurs.

En tant que créateurs de l’incrément, les développeurs jouent un rôle essentiel en partageant leur travail et en répondant aux questions.

Le Product Owner participe à la réunion pour fournir des conseils sur les décisions relatives au produit et pour intégrer les commentaires des parties prenantes dans le Product Backlog. Les décisions du Product Owner sont visibles dans le contenu et l’ordre du backlog et dans l’incrément inspectable. Le Product Owner peut soutenir les développeurs lorsqu’ils partagent les résultats.

Le rôle du Scrum Master dans cet événement peut varier d’une réunion à l’autre. Il est là pour soutenir et guider l’équipe de mêlée qui apprend à animer cet événement et à l’utiliser comme une occasion de maintenir la transparence, l’inspection et l’adaptation. Le Scrum Master peut parfois animer lui-même la revue de sprint, bien que celà ne fasse pas partie de sa responsabilité.

Conseils pour une revue de sprint réussie

A quoi doit ressembler l’agenda ?

Voici un exemple d’ordre du jour de la revue de sprint. Vos discussions au cours de cet événement peuvent inclure :

  • Rappeler à tous l’objectif du produit et l’objectif du sprint,
  • Montrer le travail achevé ou l’incrément du sprint en cours,
  • Discuter de la publication de l’incrément par rapport au budget, aux délais, au marché et à d’autres facteurs pertinents,
  • Discuter du travail le plus utile pour les sprints à venir.

Qui doit animer une revue de sprint ?

L’équipe Scrum facilite cet événement et invite les parties prenantes et d’autres participants si nécessaire. Comme le Product Owner est responsable de la maximisation de la valeur du produit résultant du travail des développeurs, il prendra souvent la tête ou lancera la conversation dans la revue de sprint.

Votre équipe Scrum et votre contexte seront uniques, et dans le cadre d’une rétrospective, vous devriez discuter des meilleures façons pour votre équipe de mener la réunion, que cela implique que le Product Owner guide la revue ou un format différent.

Quelle est la différence entre une Revue de sprint et une Rétrospective de sprint ?

La meilleure façon de comprendre la différence entre ces deux événements est de reconnaître la différence d’objectif et de participation entre les événements.

La revue porte sur le produit. La rétrospective concerne la collaboration et l’interaction de l’équipe.

La revue de sprint a lieu en premier afin que l’équipe puisse prendre en compte les commentaires des parties prenantes lorsqu’elle prend des décisions sur les actions à entreprendre au cours de la rétrospective de sprint. Les parties prenantes assistent à la revue de sprint, mais la rétrospective est un événement réservé à l’équipe Scrum.

Une occasion d’inspecter et d’adapter

L’équipe Scrum peut partager ses résultats et recevoir des commentaires précieux des parties prenantes lors de la revue de sprint. Le cadre Scrum favorise la transparence, la collaboration et l’amélioration continue au sein de l’équipe. En exploitant efficacement la revue de sprint, les équipes Scrum peuvent s’assurer qu’elles apportent de la valeur à leurs clients et qu’elles répondent aux attentes des parties prenantes.

Glossaire Agile – Scrum

Ce glossaire Agile et Scrum fournit une sélection de termes couramment utilisés dans les pratiques agiles. D’autres termes spécifiques peuvent être utilisés en fonction du cadre de travail ou de la pratique Agile adoptée par une équipe ou une organisation.

Volontairement et pour faciliter l’appropriation du vocabulaire, j’ai décidé de faire figurer les termes de ce glossaire en anglais. En effet, il est courant, même dans les équipes francophones, d’utiliser les concepts dans la langue de Shakespeare.

A

Agile

Une approche de gestion de projet axée sur la flexibilité, la collaboration et l’adaptation aux changements.

B

Backlog (ou carnet de produit)

Une liste ordonnée des fonctionnalités, des tâches ou des éléments de travail à réaliser dans un projet.

Burn-down Chart

Un graphique qui représente la quantité de travail que l’on estime restante dans un sprint par rapport au temps écoulé, permettant de suivre la progression de l’équipe.

Burn-up Chart

Un graphique qui montre la quantité de travail qui a été réalisé. Le temps est indiqué sur l’axe horizontal et le travail accompli sur l’axe vertical. Au fur et à mesure que le temps passe et que des éléments sont tirés de la backlog et achevés, on peut s’attendre à ce que la ligne du graphique montrant le travail accompli augmente. La quantité de travail peut être évaluée de plusieurs manières, comme les points d’estimation d’une User Story ou les heures de travail. La quantité de travail considérée comme étant dans le scope d’application peut également être représentée par une ligne ; on peut s’attendre à ce que le Burn-up se rapproche de cette ligne au fur et à mesure que le travail est achevé.

C

Cycle de vie itératif

Une approche de développement où le projet est découpé en itérations ou en cycles, avec des versions fonctionnelles du produit livrées à chaque itération.

Cycle de vie de valeur (Value Stream)

La séquence complète des activités nécessaires pour transformer les matières premières en un produit fini, en incluant toutes les étapes de création de valeur et les éventuels gaspillages.

D

Daily Scrum (ou Daily Stand-up Meeting)

Une réunion quotidienne de courte durée, généralement tenue debout, au cours de laquelle les membres de l’équipe Scrum se mettent à jour mutuellement sur leurs tâches, leurs progrès et leurs obstacles.

Definition of Done (DoD)

Les critères spécifiques qui définissent lorsque les éléments de backlog sont considérés comme terminés et prêts à être livrés.

Développement itératif

Un processus de développement où les fonctionnalités du produit sont conçues, développées et testées de manière itérative et progressive.

E

Empirisme

Estimation

Le processus d’évaluation de la taille, de la complexité ou de l’effort requis pour réaliser une tâche ou une fonctionnalité.

F

Feedback (ou rétroaction)

Les commentaires, les suggestions et les évaluations reçus des parties prenantes ou des utilisateurs du produit.

G

Grooming de backlog

Le processus de revue, de clarification et de priorisation des éléments du backlog, généralement réalisé lors de réunions de planification.

H

I

Increment

Le résultat du travail effectué pendant un sprint, qui doit être fonctionnel et potentiellement livrable.

Intégration continue

Une pratique de développement où les modifications de code sont régulièrement intégrées à un référentiel commun, permettant une détection précoce des problèmes et une collaboration continue.

IPO (ou Input-Process-Output)

Un modèle conceptuel qui décrit les entrées, les processus et les sorties d’un système ou d’un processus.

Itération

Une période définie de temps pendant laquelle un ensemble spécifique de tâches ou de fonctionnalités est développé et testé.

J

K

L

M

MVP (Minimum Viable Product)

La version minimale d’un produit qui satisfait les besoins de base des utilisateurs et qui peut être utilisée pour recueillir des commentaires et des apprentissages.

N

O

P

Planning Poker

Une technique d’estimation collaborative où les membres de l’équipe utilisent des cartes numérotées pour donner leur estimation relative de l’effort requis pour réaliser une tâche ou une user story.

Product Backlog

Un artefact Scrum qui consiste en une liste ordonnée du travail à effectuer pour créer, maintenir et pérenniser un produit. Le Product Backlog est géré par le Product Owner.

Product Backlog refinement

Une activité continue visant à affiner et à clarifier les éléments du backlog, généralement réalisée par le Product Owner et l’équipe de développement. C’est l’activité d’un sprint par laquelle le Product Owner et les développeurs ajoutent de la granularité au backlog (carnet de produit).

Product Goal (l’objectif de produit)

Décrit un état futur du produit qui peut servir de cible à l’équipe Scrum pour planifier. Il se trouve dans le Backlog produit. Le reste du Backlog permet de visualiser ou définir ce qui reste pour atteindre l’objectif du produit.

Product Increment

La somme de tous les éléments de backlog terminés pendant un sprint et intégrés au produit existant.

Product Owner

La personne responsable de la définition des fonctionnalités et des priorités du produit, ainsi que de la coordination avec les parties prenantes. Rôle dans Scrum responsable de la maximisation de la valeur d’un produit, principalement en gérant et en exprimant de manière incrémentale les attentes commerciales et fonctionnelles d’un produit aux développeurs.

Q

R

Refactoring

Le processus d’amélioration de la structure interne du code sans en changer le comportement externe, afin d’améliorer la maintenabilité et la lisibilité.

Release Planning

Le processus de planification à plus long terme visant à déterminer le moment et le contenu des livraisons de versions du produit.

S

Scrum

Un cadre de travail agile qui utilise des itérations courtes appelées “sprints” pour développer un produit de manière itérative et incrémentale.

Scrum Master

La personne chargée de guider et de soutenir l’équipe Scrum, de veiller au respect des principes et des pratiques de Scrum, et de faciliter les processus.

Sprint

Une période de temps fixe pendant laquelle une équipe de développement travaille sur un ensemble spécifique de tâches ou de fonctionnalités.

Sprint Backlog

La liste des éléments de backlog sélectionnés pour être réalisés pendant un sprint, ainsi que les tâches et les estimations associées.

Sprint Planning

La réunion au début de chaque sprint où l’équipe Scrum sélectionne les éléments du backlog à réaliser et planifie les tâches nécessaires pour les terminer.

Sprint Review (Revue de sprint)

La réunion à la fin de chaque sprint où l’équipe Scrum présente le travail réalisé aux parties prenantes et recueille leurs commentaires.
Lire l’article : Revue de sprint

Sprint Retrospective

La réunion à la fin de chaque sprint où l’équipe Scrum réfléchit à son fonctionnement, identifie les points à améliorer et établit un plan d’action pour les prochains sprints.

T

Test d’acceptation

Un type de test réalisé pour vérifier si le produit répond aux exigences et aux critères d’acceptation définis par les parties prenantes.

U

User story (histoire utilisateur)

Une description concise d’une fonctionnalité du point de vue de l’utilisateur, utilisée comme base pour le développement et les tests.

V

Value (valeur)

Un concept central du Lean qui définit ce que le client considère comme utile et pour lequel il est prêt à payer, en éliminant les activités non essentielles ou sans valeur ajoutée.

Velocity (vélocité)

Une mesure de la quantité de travail qu’une équipe de développement peut accomplir pendant une itération, généralement exprimée en points de story ou en unités de travail.

W

WIP (Work in Progress)

Les travaux en cours dans un processus, représentant les tâches ou les unités de travail qui ont été commencées mais qui ne sont pas encore terminées.

X

Y

Z

User Story dans Agile Scrum

Dans cet article, je vous propose d’apprendre ce qu’est une User Story et comment en écrire une. La User Story joue un rôle majeur dans la pratique agile Scrum. C’est la partie du processus Agile où, au lieu d’écrire des exigences complètes, nous écrivons une courte description d’une fonctionnalité.

Comme le dit le Manifeste Agile, “un logiciel fonctionnel” plutôt que des “documents complets”.

Qu’est-ce qu’une User Story ?

Une User Story est une description courte et simple de la fonctionnalité ou des exigences du projet. Généralement, les Users Stories sont écrites sur des notes autocollantes ou des cartes d’index comme une perspective basée sur l’utilisateur ou le rôle.

Modèle de User Story

En tant que < type d’utilisateur ou de rôle >, je veux < un objectif > pour que < une raison >.

Le modèle identifie 3 questions – “Qui”, “Quoi”, et “Pourquoi”.

Si l’équipe ne connaît pas ces trois réponses, cela signifie qu’elle ne comprend pas l’histoire, et si elle ne comprend pas l’histoire, alors il est difficile de bien la scinder.

Modèle de User Story
Modèle de User Story

Dans la carte ci-dessus, vous pouvez voir le format. Chaque histoire a un identifiant d’histoire, un titre d’histoire, un format, des critères d’acceptation, une priorité et des points d’estimation pour accomplir la tâche.

Les 3 C de l’histoire

  • Carte – Les histoires d’utilisateur sont écrites sur la carte, ayant juste assez de description de l’exigence.
  • Conversation – Les histoires doivent être conversationnelles, c’est-à-dire une conversation collaborative facilitée par le Product Owner avec l’équipe. Il s’agit d’une conversation en personne.
  • Confirmation (critères d’acceptation) – Les critères d’acceptation sont utilisés pour déterminer quand la user story a atteint l’objectif de l’utilisateur.

Une bonne user story utilise le modèle “INVEST“.

  • Indépendante – Dépendances réduites, donc plus facile à planifier.
  • Négociable – Effort de collaboration pour l’élaboration des détails
  • Valable – Apporte de la valeur au client et à l’entreprise.
  • Estimable – Assez petite et bien divisée pour que l’équipe puisse l’estimer.
  • Suffisamment petit – Peut être réalisé en moins d’une semaine par l’équipe.
  • Testable – Bons critères d’acceptation

Exemple de User Story

En tant qu’utilisateur, je veux pouvoir saisir mes informations personnelles pour l’inscription, afin de pouvoir m’inscrire et parcourir le tableau de bord de mon application web.

Critères d’acceptation

  • L’utilisateur doit saisir les données des champs obligatoires, identifiés par *(astérisques).
  • L’utilisateur doit saisir une adresse électronique et un numéro de téléphone portable valides.
  • Si l’utilisateur clique sur “Enregistrer”, les données doivent être sauvegardées dans les tableaux avec un message de réussite.
  • Si l’utilisateur clique sur “Réinitialiser”, les données qu’il a saisies sont actualisées et les champs sont effacés.

Résumé

Les user stories ne sont pas des documents de haut niveau car, en développement agile, la documentation n’est pas obligatoire. Une user story est un effort collaboratif dont l’intention est de favoriser la collaboration.

Merci de votre lecture.

N’hésitez pas à commenter ci-dessous j’aime vous aider. Si vous avez une suggestion de nouvel article ou tutoriel alors exprimez-vous en commentant.

N’oubliez pas de partager ce tutoriel avec vos amis sur Facebook et Twitter.