Module 3Adopter l'approche Agile dans la gestion de projet
Chapitre 5 sur 11
Piliers, rôles, événements, artefacts et engagements de Scrum, user stories, story points, vélocité et burndown.
Objectifs
Avec ce chapitre, tu sauras…
Leçon 1
Objectifs de Scrum (résumé) : améliorer la productivité des équipes, optimiser le produit grâce aux retours réguliers du marché, donner à chaque partie prenante une vue d'ensemble du projet, réduire les bugs et mettre à jour les priorités régulièrement.
L'empirisme : trois piliers
Scrum repose sur l'empirisme : la connaissance vient de l'expérience, et les décisions se prennent sur ce qu'on observe. Trois piliers le soutiennent :
| Pilier | Sens | Exemple |
|---|---|---|
| transparence | le travail et son avancement sont visibles de tous | le tableau du sprint, le backlog accessible au client |
| inspection | on examine souvent le produit et la façon de travailler | Daily Scrum, revue, rétrospective |
| adaptation | on ajuste dès qu'un écart est détecté | changer les priorités du backlog, modifier une pratique de l'équipe |
Vidéo · À regarder
FRSCRUM : la méthode agile en 10 minutes (Projet agile)
StrategeMarketing · YouTube
Leçon 2
| Phase | Contenu |
|---|---|
| pre-game (avant-jeu) : planification et architecture | création du Product Backlog ; découpage des epics en user stories plus petites ; conception de haut niveau et choix d'architecture |
| game (jeu) : les sprints | l'équipe réalise le travail sprint après sprint : Sprint Planning, développement, tests et documentation, Daily Scrum, mise à jour du burndown chart, revue et rétrospective à la fin de chaque sprint |
| post-game (après-jeu) : démonstration et clôture | le développement est terminé ; on prépare la mise en production : tests finaux, intégration, formation, documentation utilisateur, supports marketing |
Leçon 3
| Responsabilité | Rôle | Ce qu'il fait | Ce qu'il ne fait pas |
|---|---|---|---|
| Product Owner (PO) | maximiser la valeur du produit | définit et communique l'objectif de produit ; crée, ordonne et clarifie les éléments du Product Backlog ; représente les besoins des clients et des parties prenantes ; accepte ou non le travail réalisé | il ne dit pas aux Developers comment faire ; c'est une personne, pas un comité |
| Scrum Master (SM) | l'efficacité de l'équipe Scrum |
Leçon 4
| Événement | Quand ? | Qui ? | Durée maximale (sprint d'un mois) | But |
|---|---|---|---|---|
| Sprint | en continu, l'un après l'autre | toute l'équipe | 1 mois au plus (souvent 2 semaines) | le conteneur de tous les autres événements ; produire un incrément ; sa durée reste fixe |
| Sprint Planning | au début du sprint | toute l'équipe Scrum | 8 heures |
Leçon 5
| Artefact | Contenu | Responsable | Engagement associé |
|---|---|---|---|
| Product Backlog | la liste ordonnée et évolutive de tout ce qui pourrait améliorer le produit : fonctionnalités, corrections, exigences non fonctionnelles, tâches techniques ; le « réservoir » du produit | le Product Owner | l'objectif de produit (Product Goal) : l'état futur visé du produit |
| Sprint Backlog | l'objectif du sprint, les éléments du Product Backlog choisis pour le sprint et le plan pour les réaliser ; une vue en temps réel du travail du sprint | les Developers | l'objectif du sprint (Sprint Goal) |
Leçon 6
| Niveau | Définition | Exemple |
|---|---|---|
| epic (épopée) | un grand besoin, trop gros pour un sprint, à découper | « Commande en ligne » |
| user story | un besoin réalisable en un sprint | « payer ma commande par carte » |
| tâche | une étape technique pour réaliser la story | « intégrer l'API de paiement », « écrire les tests », « créer la page de confirmation » |
Leçon 7
1Les trois piliers de l'empirisme sont…
2Celui qui ordonne le Product Backlog est…
3La durée maximale d'un sprint est…
4La durée maximale du Daily Scrum est…
5L'engagement associé à l'incrément est…
6Les parties prenantes participent surtout à…
7Selon le Guide Scrum, peut annuler un sprint…
8Une story terminée à 90 % compte dans la vélocité pour…
L'essentiel du chapitre
Dans le résumé
| fait comprendre et appliquer Scrum ; coache l'équipe vers l'autogestion ; fait lever les obstacles ; veille à ce que les événements aient lieu et soient utiles ; aide le PO (techniques de backlog) et l'organisation |
| ce n'est pas un chef de projet ni un chef d'équipe : il est un leader au service de l'équipe |
| Developers | créer à chaque sprint un incrément utilisable | établissent le Sprint Backlog ; adaptent leur plan chaque jour ; respectent la Définition de terminé ; se rendent mutuellement responsables | « Developers » désigne tous ceux qui réalisent l'incrément : développeurs, testeurs, designers… |
| Hors de l'équipe Scrum | |
|---|---|
| parties prenantes (stakeholders) | toute personne ayant un intérêt dans le produit sans faire partie de l'équipe Scrum : clients, utilisateurs, direction, service commercial ; elles participent notamment à la Sprint Review |
Vidéo · À regarder
FRScrum Master : guide 2020 en français par Scrum Life
Scrum Life · YouTube
| répondre à trois questions : pourquoi ce sprint a-t-il de la valeur (l'objectif du sprint) ? quoi : quels éléments du backlog ? comment : quel plan pour les réaliser ? |
| Daily Scrum | chaque jour, même heure, même lieu | les Developers (PO et SM s'ils travaillent sur les éléments) | 15 minutes | inspecter l'avancement vers l'objectif du sprint et adapter le plan de la journée |
| Sprint Review | à la fin du sprint | équipe Scrum et parties prenantes | 4 heures | inspecter l'incrément (démonstration), recueillir les retours, adapter le Product Backlog |
| Sprint Retrospective | après la revue, dernier événement du sprint | équipe Scrum | 3 heures | améliorer la façon de travailler : ce qui s'est bien passé, ce qui pose problème, ce qu'on change au prochain sprint |
Vidéo · À regarder
FRComprendre le Daily Scrum : qu'est-ce que c'est et comment ça fonctionne ?
YouTube (FR) · YouTube
Vidéo · À regarder
FRSprint Review : c'est l'événement Scrum qu'on préfère ? On vous explique tout en détails !
YouTube (FR) · YouTube
Vidéo · À regarder
FRRétrospective en Scrum - La Minute Agile #46
La Minute Agile · YouTube
| Incrément | un pas concret vers l'objectif de produit ; chaque incrément s'ajoute aux précédents et est vérifié : il doit être utilisable | l'équipe Scrum | la Définition de terminé (Definition of Done, DoD) |
| Si la courbe réelle est… | Cela signifie… |
|---|---|
| au-dessus de la ligne idéale | l'équipe est en retard : à discuter au Daily Scrum (obstacle ? story trop grosse ?) |
| en dessous | l'équipe est en avance : elle peut prendre un élément de plus avec le PO |
| plate pendant plusieurs jours | rien n'est terminé : les stories sont trop grosses, ou du travail est commencé partout et fini nulle part |
| qui remonte | du travail a été ajouté pendant le sprint |
Vidéo · À regarder
FRLe poker planning en 3 mins !
YouTube (FR) · YouTube
Les cinq valeurs
Engagement (envers les objectifs de l'équipe), focus (se concentrer sur le travail du sprint), ouverture (sur le travail et les difficultés), respect (des compétences et de l'autonomie de chacun), courage (de faire ce qui est juste, de traiter les problèmes difficiles).
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : un tour complet de Scrum : les rôles (Product Owner, Scrum Master, développeurs), les événements (sprint, planning, daily, review, rétrospective) et les artefacts (backlogs, incrément). Elle donne la vue d'ensemble de Scrum avant le détail des sections suivantes.
Le résumé présente Scrum en trois phases, issues de la première présentation de la méthode par Ken Schwaber (1995) :
L'équipe Scrum est une petite équipe sans sous-équipes ni hiérarchie, composée d'un Product Owner, d'un Scrum Master et de Developers. Elle compte en général 10 personnes au plus. Elle est pluridisciplinaire (elle a toutes les compétences pour créer de la valeur à chaque sprint) et autogérée (elle décide elle-même qui fait quoi, quand et comment).
Chaque événement est une occasion formelle d'inspecter et d'adapter. Chacun a une durée maximale (timebox), proportionnelle à la durée du sprint.
Une user story (récit utilisateur) est un élément du backlog qui décrit un besoin du point de vue de l'utilisateur, en une phrase : En tant que [type d'utilisateur], je veux [action] afin de [bénéfice]. Elle est complétée par des critères d'acceptation qui permettent de vérifier qu'elle est réalisée.
KIT-12 · En tant que cliente,
je veux filtrer les livres par catégorie et par prix
afin de trouver rapidement un livre adapté à mon budget.
Critères d'acceptation (format Étant donné / Quand / Alors) :
1. Étant donné que je suis sur la page « Livres »,
quand je choisis la catégorie « Jeunesse »,
alors seuls les livres de cette catégorie s'affichent, avec leur nombre.
2. Étant donné que je filtre de 50 à 100 DH,
quand la liste s'affiche,
alors tous les prix affichés sont compris entre 50 et 100 DH.
3. Quand aucun livre ne correspond, un message propose de retirer un filtre.
Estimation : 5 pointsLes story points et le planning poker
Les éléments du backlog sont souvent estimés en points d'histoire (story points) : une mesure relative de l'effort (complexité, quantité de travail, incertitude), et non une durée. On utilise une suite proche de Fibonacci : 1, 2, 3, 5, 8, 13, 21… Les écarts grandissent avec la taille, car plus une tâche est grosse, plus l'estimation est incertaine.
Le planning poker
La vélocité
La vélocité est le nombre de points de user stories terminées (selon la DoD) par l'équipe au cours d'un sprint. Sa moyenne sur les derniers sprints sert à prévoir ce que l'équipe pourra faire. Une story « presque terminée » compte zéro.
Exemple : sur trois sprints, l'équipe de Kitab a terminé 18, 22 et 20 points : vélocité moyenne = (18 + 22 + 20) / 3 = 20 points par sprint. S'il reste 120 points dans le backlog de la version, il faut environ 120 / 20 = 6 sprints, soit 12 semaines avec des sprints de 2 semaines.
Le burndown chart
Le graphique d'avancement (burndown chart) montre, jour après jour, le travail restant dans le sprint (en points ou en heures), comparé à une ligne idéale qui va du total au début jusqu'à zéro à la fin.
points
restants
20 |*.
18 | *. . ligne idéale (2 points par jour)
16 | .* * travail réellement restant
14 | .* *
12 | . * Jours 3 à 5 : la courbe est au-dessus de l'idéal,
10 | . * l'équipe est en retard ; le jour 6, une story de
8 | . 5 points est terminée d'un coup.
6 | . * *
4 | . *
2 | . *
0 |_____________________.______*___
0 1 2 3 4 5 6 7 8 9 10 joursEn équipe (un PO, un SM, des Developers) : (1) écrivez l'objectif de produit et la Définition de terminé ; (2) rédigez un Product Backlog d'au moins 15 user stories ordonnées (avec des epics) ; (3) estimez-les en planning poker ; (4) organisez un Sprint Planning : objectif du sprint, stories retenues pour une vélocité supposée de 20 points, découpage en tâches ; (5) jouez trois Daily Scrums de 15 minutes et une rétrospective, et notez une amélioration.
Pour chaque action, indique qui en est responsable (Product Owner, Scrum Master, Developers, parties prenantes) : (1) décider que le paiement à la livraison passe avant les avis clients ; (2) découper la story « payer par carte » en tâches techniques ; (3) obtenir du service informatique un accès au serveur de recette qui bloque l'équipe ; (4) donner son avis sur la démonstration de la recherche ; (5) proposer un nouveau format de rétrospective ; (6) refuser une story qui ne respecte pas un critère d'acceptation ; (7) choisir quel développeur prend quelle tâche.
Écris quatre user stories de Kitab (pour une cliente, un visiteur, une libraire et l'administrateur), chacune avec deux critères d'acceptation au format Étant donné / Quand / Alors. Vérifie chacune avec les critères INVEST et classe-les avec MoSCoW.
Ce découpage en trois phases ne figure pas dans le Guide Scrum actuel, qui ne décrit qu'un cycle de sprints sans phase préalable ni finale : la préparation et l'architecture se font dans les premiers sprints, et chaque sprint produit un incrément qui peut être mis en production. Le résumé indique aussi que le Scrum Master ou le Product Owner peut « arrêter le sprint, s'adapter puis le redémarrer » : selon le Guide, seul le Product Owner peut annuler un sprint, et seulement si son objectif devient obsolète ; on ne « redémarre » pas un sprint, on en planifie un nouveau.
┌──────────────────────── Sprint (1 à 4 semaines) ───────────────────────┐
Product Backlog ──►│ Sprint Planning ─► Sprint Backlog ─► travail + Daily Scrum (chaque jour) │──► Incrément
(priorisé par │ │ (« Terminé »)
le Product Owner) │ Sprint Review ─► Sprint Retrospective │
└────────────────────────────────┬─────────────────────────────────────────┘
└──► le sprint suivant commence aussitôtLe résumé appelle le Scrum Master « le gourou » et « le responsable de projet » ; il donne au Product Owner le profil de « souvent le fondateur ou le boss » ; il fixe l'équipe à « 6 à 10 personnes ». Selon le Guide Scrum 2020 : le Scrum Master n'a pas d'autorité hiérarchique sur l'équipe ; le Product Owner est celui qui connaît le mieux le métier et les clients (dans une petite entreprise, c'est parfois le dirigeant, mais pas forcément) ; l'équipe Scrum entière compte 10 personnes ou moins (sans minimum fixé), PO et SM compris.
Ce que tu vas voir (9 min) : les chapitres « Ce que le Scrum Master n'est PAS », « Maîtriser Scrum plutôt qu'en être le maître », « Assurer l'amélioration continue », « Les 3 groupes à accompagner », « Accompagner l'équipe Scrum », « Accompagner le Product Owner », « Accompagner l'organisation ». Ces chapitres expliquent le rôle du Scrum Master selon le Guide Scrum 2020 : ce qu'il n'est pas (un chef de projet), l'amélioration continue et l'accompagnement de l'équipe, du Product Owner et de l'organisation.
Pour un sprint plus court, les durées maximales sont en général plus courtes (par exemple 4 heures de planning pour un sprint de 2 semaines).
Le résumé décrit le Daily Scrum comme une réunion de « 5 à 10 minutes », debout, autour de trois questions (qu'ai-je fait hier ? quels problèmes ? que vais-je faire aujourd'hui ?). Ces trois questions sont une pratique courante, mais le Guide Scrum 2020 les a retirées : le Daily dure 15 minutes au plus et l'équipe choisit le format qui l'aide le mieux à progresser vers l'objectif du sprint. Le résumé place aussi la revue « tous les vendredis » : elle a lieu à la fin du sprint, quel que soit le jour.
Le raffinement (backlog refinement) n'est pas un événement mais une activité continue : le Product Owner et les Developers découpent, précisent et estiment les éléments du Product Backlog pour qu'ils soient prêts à être sélectionnés lors d'un prochain Sprint Planning. On y consacre en général moins de 10 % du temps de l'équipe.
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : le Daily Scrum : 15 minutes chaque jour, à heure fixe, pour que les développeurs fassent le point sur l'objectif du sprint et ajustent leur plan. C'est le Daily Scrum de cette section.
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : la Sprint Review : l'équipe présente l'incrément aux parties prenantes, recueille leurs retours et met à jour le Product Backlog. C'est la Sprint Review de cette section.
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : la rétrospective : à la fin du sprint, l'équipe examine sa façon de travailler et choisit des améliorations concrètes pour le sprint suivant. C'est la Sprint Retrospective de cette section.
La Définition de terminé est la description formelle de l'état que doit atteindre un élément pour être considéré comme terminé. Exemple pour Kitab : « le code est revu par un autre développeur, les tests automatisés passent, l'analyse SonarQube ne signale aucun problème bloquant, la page est responsive, la fonctionnalité est déployée sur l'environnement de recette, le Product Owner l'a acceptée. » Un élément qui ne respecte pas la DoD ne peut pas être présenté à la revue ; il retourne dans le Product Backlog.
Indépendante (réalisable sans attendre une autre), Négociable (le détail se discute), de Valeur (elle apporte quelque chose à un utilisateur), Estimable, Small (petite : tient dans un sprint), Testable (des critères d'acceptation vérifiables).
Le premier objectif est souvent un MVP (Minimum Viable Product, produit minimum viable) : la plus petite version du produit qui apporte déjà de la valeur aux utilisateurs et permet d'apprendre. Pour Kitab : chercher un livre, le commander, le retirer en magasin.
Prioriser le backlog
La méthode MoSCoW classe chaque élément en Must have (indispensable), Should have (important), Could have (souhaitable), Won't have this time (pas pour cette version). On peut aussi comparer la valeur apportée et l'effort demandé : on commence par les éléments à forte valeur et faible effort.
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : le planning poker : chaque membre choisit une carte (suite de Fibonacci) en secret, on retourne les cartes ensemble, on discute des écarts puis on revote. C'est la technique d'estimation de cette section.
Une équipe a terminé 23, 19, 25 et 21 points lors de ses quatre derniers sprints de deux semaines. Le backlog de la version 1 contient encore 132 points. (1) Calcule la vélocité moyenne. (2) Combien de sprints faut-il encore, et combien de semaines ? (3) Pendant le sprint suivant, l'équipe a terminé 3 stories de 5 points et une story de 8 points est restée « en recette » : quelle est la vélocité de ce sprint ?