Les 4 évènements Scrum
Les événements Scrum sont décrits dans le Scrum Guide comme des boîtes de temps (timebox). La timebox principale est le Sprint qui possède une durée fixe allant de une semaine à un mois (qui pour des raisons pratiques est souvent réduit à 4 semaines au maximum). Tout Sprint possède donc une durée fixe, un objectif fixe (Sprint Goal) et un périmètre (Sprint Backlog) qui peut être renégocié entre l’équipe de développemnt et le Product Owner en fonction de ce qui va être appris durant le Sprint.
A l’intérieur du Sprint on retrouve d’autres timeboxes qui servent à organiser le travail de l’équipe et cadrer le temps passé en réunion :
1. Le Sprint Planning
Dans chaque Sprint, l’ équipe Scrum définit un objectif pour le Sprint: le Sprint Goal. Quelle(s) fonctionnalité(s) utilisables du produit peut-on livrer dans le Sprint ? Attention une liste pure et simple de fonctionnalités(ex: les Jira 3, 4, 5) ne forment PAS un bon Sprint Goal. C’est la balise qui va aider l’équipe Scrum à se diriger au fur et à mesure des découvertes lors du Sprint. Seul le PO peut invalider un Sprint Goal lorsque l’objectif devient obsolète avec la direction que doit prendre le produit. C’est une chose qui est heureusement rare, vu la durée des Sprints.
Avant le Sprint Planning, généralement le Product Owner(PO) doit avoir une idée du Sprint Goal. Cela va orienter quels éléments du Product Backlog seront à préférer pour ce Sprint. L’ordonnancement, le raffinement et la clarté du Product Backlog jouent un grand rôle pour le Sprint Planning (ce qui ne veut pas dire qu’il faut pour autant avoir tout raffiné). Le Product Backlog comporte des éléments ou Product Backlog Items(PBI) qui se trouvent être souvent des User Stories (voir La boîte à outils de Scrum ).
L’équipe Scrum entière concocte le Sprint Goal et aussi estime la charge de PBI qui peut être réalisée pendant la durée du Sprint en fonction du contexte de l’équipe (capacité, vélocité, …) et de la complexité des PBI. L’évènement du Sprint Planning nécessite une collaboration active de toute l’équipe Scrum. L’équipe de Développement s’engage collectivement sur le Sprint Goal. Elle prend les PBI à livrer durant le Sprint du Product Backlog et les mets dans le Sprint Backlog. Cela constitue en quelque sorte l’estimation de comment livrer l’Incrément ce Sprint.
Un Sprint Planning a une timebox de 8h pour un Sprint de 1 mois.
Afin de réaliser l’estimation des PBI , le planning poker est un outil souvent utilisé dans les équipes Scrum.
Le planning poker
- Se fait idéalement en présence du Product Owner,
- Avec des cartes ou une appli mobile si équipé (ex : Scrum Poker Cards Agile),
- Le PO doit avoir bien préparé les PBI (Users Stories par exemple) en les détaillant suffisamment,
- Le PO peut faire parvenir aux développeurs en avance les PBI à chiffrer,
- Le PO refait une lecture en détail avec les développeurs des PBI à chiffrer afin que le besoin soit vraiment bien compris,
- Tous les membres de l’équipe de Développement doivent proposer en même temps un chiffrage, même pour ceux qui ne travailleront pas sur le PBI estimé.
2. Le Daily Scrum
Le Daily Scrum ( quelques fois communément appelé daily meeting ou daily stand up) est un événement de 15 min qui permet à l’équipe de se synchroniser. Cet évènement a pour objectif de donner de la visibilité à l’équipe sur les tâches effectuées permettant d’atteindre l’objectif (Sprint Goal) et sur les obstacles qui freinent les développeurs dans l’accomplissement de ces tâches. Le Daily Scrum est donc l’occasion pour chaque membre de l’équipe de se synchroniser avec les autres, de demander de l’aide si besoin et de préparer dans des conditions optimales une nouvelle journée de Sprint.
Afin de respecter le délai très court du daily, on peut s’aider des trois questions suivantes auxquelles chaque membre de l’équipe peut répondre ( ces questionw sont indicatives et non obligatoires, c’est le but de celles-ci ainsi que l’inspection vers le Sprint Goal qu’il faut réaliser) :
- Qu’est ce que j’ai fait hier (engagement réussi ou non) ?
- Quelles sont les difficultés rencontrées ?
- Qu’est ce que je vais faire aujourd’hui ?
Le PO peut participer au Daily Scrum, tout en se rappelant que c’est un évènement pour l’équipe de développement :
- Il peut le faire en présentiel ou à distance
- Il doit rester en retrait et noter des points de discussions qui pourront être nécessaire après le Daily
- Bien sûr si l’équipe a une question particulière pour le PO, il peuvent demander, mais cela doit rester ponctuel et exceptionnel car cela n’est principalement pas le moment
Le Scrum Master doit faire en sorte de faire apprendre à l’équipe de Développment comment rester dans les 15 minutes afin que cela ne se change pas en réunion.
A éviter lors d’un daily Scrum
- Détailler toutes ses actions
- Faire une réunion dans la réunion
- Prendre trop de temps de parole
- Inviter des participants qui n’ont pas leur place
3. La Sprint Review
La revue de Sprint a pour but de faire le point sur ce qui a été réalisé durant le Sprint et de voir si l’objectif du Sprint est atteint. Elle permet de démontrer aux parties prenantes (stakeholders) ce qui a été terminé pendant le Sprint, ainsi que de faire l’inspection de l’Incrément.
Elle sert également de transition à la prochaine réunion de planning. Durant la revue de Sprint, l’équipe Scrum présente les stories terminées, explique les problèmes rencontrés, comment ils ont été résolus, répond aux questions des participants et prend note de leurs retours. Elle permet au Product Owner de faire le point sur le backlog produit et d’effectuer des ajustements pour la suite.
Une Sprint Review a une timebox de 4h pour un Sprint de 1 mois.
4. La rétrospective
La rétrospective de Sprint permet de se focaliser sur les personnes, les relations et les process dans le but d’analyser à chaque fin de Sprint ce qui à bien fonctionné, ce qui doit être abandonné et ce qui peut être amélioré (Keep, Drop, Start). C’est un moment important pour prendre du recul, exprimer son ressenti et apprendre des expériences passées pour progresser.
Pour que la rétrospective soit une expérience mémorable pour l’équipe et pour éviter la routine, il existe de nombreux formats ludiques qui peuvent servir d’exemple pour les animer :
- Keep - Drop - Start,
- Speed boat,
- On refait le match,
- Bâton de parole,
- Etc.
Quelques soit le format choisi pour animer votre rétrospective, le déroulé se fait généralement selon les étapes suivantes :
- Mise en place,
- Récolter les données,
- Générer les idées,
- Décider quoi faire,
- Clore la rétrospective.
L’essentiel pour votre rétrospective est qu’elle permette de générer des actions concrètes qui seront mises en oeuvre pour le prochain Sprint. Il faut placer impérativement un item désigné par l’ensemble de l’équipe dans la prochaine Sprint Backlog afin de favoriser l’amélioration continue.
Une Sprint Retrospective a une timebox de 3h pour un Sprint de 1 mois.