7 – Evénements Scrum : Sprint Review

La Sprint Review est l’événement au cours duquel l’Équipe Scrum et les parties prenantes (invitées par le Product Owner) se retrouvent pour inspecter l’Incrément et adapter le Product Backlog. Cette fréquence d’inspection et adaptation du travail effectué est très importante pour comprendre si la direction prise est correcte et ensemble décider de la modifier.

Il s’agit d’un événement informel, qu’il n’a donc pas besoin de préparation, car on inspectera un Incrément « fini » et par définition en état de marche et sans anomalies, prêt à être mis en production si le Product Owner le décide.

Un déroulé possible de cet événement pourrait être, voir le Scrum Guide :

  • Présentation du Sprint Goal (définit en Sprint Planning) par le Product Owner
  • Description des éléments du Product Backlog « finis » et pas « finis », en relation avec le Sprint Goal, par le Product Owner
  • Partage du contenu de l’incrément par l’équipe de développement, avec les choix techniques faites pour les solutions implémentés
  • Mise à disposition de l’Incrément pour les parties prenantes présentes afin d’obtenir leur feedback
  • Adaptation du Product Backlog avec les nouvelles idées, un nouveau ordonnancement, l’élimination de certains éléments, etc.
  • Revue du Product Backlog et partage des dates prévisionnelles de livraison en fonction des progrès réalisés à ce jour (données empiriques).
Sprint Review
Sprint Review

La Sprint Review n’est pas

Une démo : par exemple juste une vidéo montrée aux parties prenantes des nouvelles fonctionnalités implémentés, ou une présentation de la part d’un membre de l’équipe Scrum.

La lecture d’un Power Point : théorique, éventuellement avec captures d’écran, qui explique ce qui a été fait.

Une présentation du travail fait par l’équipe de Développement au Product Owner.

Nous n’avons rien à montrer en Sprint Review

Il y a toujours quelque chose à Inspecter en Sprint Review, si vous êtes dans une situation ou vous n’avez rien à montrer aux parties prenantes, il faut avoir le courage de maintenir l’événement et, de manière transparente expliquer les obstacles (impediments) qui vous ont empêché de créer un Incrément « Fini » à la fin du Sprint.

Des dysfonctionnement constatés sur le terrain, qui conduisent à ce type de situation, sont :

  • un découpage à améliorer des éléments du Product Backlog, avec des trop gros « morceaux » à développer au cours du Sprint
  • une équipe de développement qui n’a pas toutes les compétences pour créer un Incrément « Fini »
  • une équipe de développement qui travaille sur plusieurs projets / produit en multi-tasking, sans pouvoir se concentrer à la création d’un Incrément
  • un Produit existant qui est découpé en couches techniques
  • l’absence d’un Sprint Goal

Quoi qu’il arrive, l’équipe Scrum doit s’auto-organiser pour pouvoir, en Sprint Review, intéresser les parties prenantes. L’intérêt viens du fait d’avoir réussi à créer une évolution de valeur du produit par rapport à la dernière fois. Cela peut être difficile au début, dans certaines situations. Annuler la Sprint Review ne vous aidera pas à vous améliorer, au contraire, cela aura un effet négatif sur la transparence de votre travail et vous empêchera d’obtenir un précieux feedback.

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum, selon le Scrum Guide. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.

6 – Evénements Scrum : Daily Scrum

Le Daily Scrum est un évènement quotidien destiné à l’Équipe de Développement et qui a pour but de planifier le travail des prochaines 24 heures. C’est un time-box de 15 minutes.

Le Daily Scrum a lieu toujours au même endroit et à la même heure, pour réduire la complexité. C’est l’Équipe de Développement qui décide de l’organisation.

Le Daily Scrum permet à l’Equipe de Développement de comprendre si le Sprint Goal sera atteint ou pas pour la fin du Sprint. Pour ce faire, l’équipe s’auto-organise pour échanger sur ce qui a été fait, ce qui reste à faire et les obstacles qui empêchent le travail de se réaliser.

On le remarque dans l’affiche, il n’y a pas d’intervention du Product Owner dans cet événement et le Scrum Master doit uniquement s’assurer que le Daily Scrum a lieu tous les jours avec tous les membres de l’Équipe de Développement.

Si vous êtes surpris par le fait que la participation du Product Owner est proscrite, relisez le rôle du Product Owner, quelles sont ses responsabilités ?

Voici quelque questions pour vous permettre de réfléchir et mieux comprendre ce point :

  • Y-a-t-il une difference entre participer et observer ?
  • Si le Product Owner participe au Daily Scrum, quelles seraient les consequences sur l’auto-organisation de l’Équipe de Développement ?
  • Si le Product Owner observe un Daily Scrum, quelles seraient les consequences sur l’auto-organisation de l’Équipe de Développement ?

L’Équipe de Développement, pour savoir si le Sprint Goal est toujours atteignable, utilisera un moyen pour rendre transparent le travail fait et restant à faire. Très souvent on entendra parler de « Burndown Chart » (voir lexique Scrum), en format papier ou électronique, cela n’est pas une obligation. L’important c’est la transparence de l’information.

Le Daily Scrum n’est pas…

… une réunion pour résoudre des problèmes, son but est de les révéler pour les traiter au moment opportun selon leur gravité.

… une réunion de suivi et avancement des travaux de l’Équipe de Développement par le Scrum Master, le Product Owner ou un Manager.

… un événement hebdomadaire, son nom « Daily » signifie bien quotidien… vous avez la réponse à la question : « nous avons décidé de faire un daily un jour sur deux, car se voir tous les jours n’avait pas de sens ». Dans ce cas, pensez au manque de transparence que vous allez créer et à l’opportunité manquée de savoir si vous êtes toujours capables d’atteindre le Sprint Goal. Souvenez vous que la base d’une approche empirique est la transparence… comment pourriez vous inspecter correctement et adapter le travail sinon ?

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum, selon le Scrum Guide. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.

Évènements Scrum : Sprint Planning

5 – Evénements Scrum : Sprint Planning

Le Sprint Planning est le premier évènement d’un Sprint. Son objectif est de collaborer à la planification du travail à effectuer durant le Sprint. C’est un timebox de 8 heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court. Toute la l’Équipe Scrum y participe.

Un Sprint Planning est composé de deux parties principales.

1 – Quoi faire ?

Le Product Owner, présente une proposition de Sprint Goal correspondant à son objectif pour le Sprint et un Product Backlog ordonnancé en cohérence avec ce but.

La partie haute du Product Backlog sera composé d’éléments suffisamment petits, connus et compris par l’Équipe de Développement.

L’Équipe Scrum collabore pour définir un Sprint Goal réaliste et atteignable pour la fin du Sprint.

2 – Comment faire ?

Sprint Planning

L’Équipe de Développement sélectionne les éléments du Product Backlog qui sont réalisables dans le Sprint.

Certains facteurs ont un impact sur les estimations de l’Équipe de Développement, comme : la définition de « Fini », les performances passées, les actions d’améliorations à implémenter, la capacité de l’Équipe de Développement (congés, maladies, affectations partielles).

Pour chaque élément du Product Backlog (pas nécessairement tous), l’Équipe de Développement établira un plan de réalisation, avec plus ou moins de détail selon l’expérience.

Ce plan sera rendu transparent dans le Sprint Backlog et on acceptera qu’il change selon les informations qui émergeront au cours du Sprint.

Observations importantes

  • Dans un contexte complexe, tel que le développement logiciel par exemple, les interactions ne sont jamais linéaires. Attendez-vous à revenir sur le « quoi faire » quand vous êtes passés au « comment faire », parfois le Sprint Goal change plusieurs fois au cours de la session.
  • Le seul engament pris par l’équipe de Développement consiste en la réalisation du Sprint Goal. Ce n’est pas la quantité de travail, ou d’éléments du Product Backlog développés à la fin du Sprint qui compte, c’est le fait d’avoir réussi à atteindre le Sprint Goal et crée un Increment « Fini » potentiellement délivrable en production. Le plus petit qu’il soit.
  • Du « Push » au « Pull » : seule l’Équipe de Développement peut faire les prévisions sur combien d’éléments du Product Backlog seront réalisés au cours du Sprint. On dit que l’Équipe de Développement « tire » (« Pull ») le travail à faire sur la base des suggestions du Product Owner. Personne ne peut leur imposer ou « pousser » (« Push ») une quantité de travail à réaliser. Renoncer à accepter cette manière de travailler, signifie déresponsabiliser l’Équipe de Développement et amène souvent à des effets de bords tels que : manque d’engagement, manque de qualité, dette technique, turnover, etc.
  • La sélection des éléments du Product Backlog sera faite dans l’ordre défini par le Product Owner dans le Product Backlog. On ne choisira pas l’élément plus facile à réaliser, par convenance.
  • Le Product Owner doit-il/elle rester pour la deuxième partie du Sprint Planning, le « comment faire » ? Oui ! Il/elle reste pour la raison donnée dans le premier point de cette liste. Il faut toujours s’attendre à des interactions parmi Product Owner et Scrum Master tout au long du Sprint Planning.
  • Le Sprint Backlog ne sera pas détaillé pour tout le contenu du Sprint. L’important sera d’avoir suffisamment de détail pour pouvoir initier le Sprint. On acceptera l’émergence du travail au cours du Sprint.

A la fin du Sprint Planning, un Sprint Goal, des prévisions d’éléments de Product Backlog à développer (faites par l’Équipe de Développement) et un Sprint Backlog, constituant le plan de l’Équipe de Développement pour réaliser le Sprint Goal auront été créés et le Sprint pourra démarrer.

Évènements Scrum : Sprint Planning

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum, selon le Scrum Guide. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.