Fiche de révision : Scrum : rôles et fonctionnement

📋 Plan du Cours

1. Définir un projet et ses marqueurs
2. Approches classiques et planification
3. Principes et valeurs agiles
4. Contraintes et suivi des projets
5. Cadre et principes de Scrum
6. Rôles et responsabilités Scrum
7. Événements et rythme des sprints
8. Artefacts et définitions de fini
9. Rédiger et découper les User Stories
10. Prioriser le backlog produit
11. Estimer l’effort des User Stories
12. Vélocité et capacité du sprint
13. Burndown et burnup du projet
14. Flux de travail et outils de suivi
15. Pertinence et limites de l’agile

📖 1. Définir un projet et ses marqueurs

🔑 Notions clés & Définitions

• Projet selon ISO 10006 : ISO 10006 (1997) définit un projet comme un processus unique composé d'activités coordonnées et maîtrisées, avec des dates de début et de fin, visant un objectif conforme à des exigences spécifiques de délais, de coûts et de ressources.
• Projet selon le PMBOK 7 : Le PMI définit dans le PMBOK 7 un projet comme une entreprise temporaire initiée pour fournir un produit, un service ou un résultat unique.
• Chef de projet : Selon le PMI, le chef de projet est la personne désignée par l'organisation pour diriger l'équipe vers ses objectifs, faciliter son travail, gérer les processus et créer de la valeur.

★ À maîtriser

📌 Un projet livre un résultat selon un coût, un délai et un périmètre ; un programme coordonne plusieurs projets liés et leurs interdépendances, ressources et budgets ; un portefeuille sélectionne et aligne les projets sur la stratégie et la valeur business.

Compléments

📌 Une activité répétitive ou récurrente relève des opérations courantes et non d'un projet.

📖 2. Approches classiques et planification

🔑 Notions clés & Définitions

• Chemin critique : Le chemin critique est le chemin le plus long d'un réseau de tâches avec durées et antériorités ; il fixe la durée minimale du projet.

★ À maîtriser

📌 L'approche classique planifie en détail au départ puis exécute phase par phase, l'approche agile s'adapte par itérations courtes et livraisons fréquentes, et l'approche hybride combine les deux selon le contexte.

Compléments

• Le modèle en cascade enchaîne les exigences, la conception, l'implémentation, la vérification et les tests, puis le déploiement et la maintenance ; chaque phase commence à la fin de la précédente.

• Dans le cycle en V, chaque étape de conception correspond à une étape de test ou de validation, et le modèle est utilisé pour des projets complexes.

• Le PMI distingue cinq phases de projet : initiation avec la charte, planification du périmètre et du budget, exécution, pilotage et contrôle, puis clôture. - PMBOK

• Dans l'exemple, le chemin A-D-E-F dure 10 jours et est critique, tandis que B-C dure 7 jours et dispose d'une marge de 3 jours.

💡 Astuce mémo

Cascade : exigences → conception → réalisation → tests → déploiement.

📖 3. Principes et valeurs agiles

★ À maîtriser

• Les quatre principes agiles présentés en cours sont :

  • satisfaire le client par des livraisons précoces et régulières
  • accepter et adapter le changement même tardivement
  • collaborer régulièrement avec le client
  • réfléchir périodiquement aux moyens d'améliorer l'efficacité

• Le Manifeste agile privilégie quatre éléments :

  • les individus et leurs interactions plutôt que les processus et les outils
  • les fonctionnalités opérationnelles plutôt qu'une documentation exhaustive
  • la collaboration avec le client plutôt que la négociation contractuelle
  • la réponse au changement plutôt que le suivi d'un plan

• Le rapport Chaos 2015 du Standish Group indique, pour l'approche traditionnelle, 11 % de succès, 29 % d'échecs et 60 % de résultats mitigés, contre 39 % de succès, 9 % d'échecs et 52 % de résultats mitigés pour l'approche agile. - Chaos Report

Compléments

📌 Dans le Manifeste agile, les éléments moins valorisés conservent de la valeur ; Scrum ne supprime donc ni la documentation ni les spécifications, et le Product Owner décide du niveau de détail utile.

💡 Astuce mémo

Le Manifeste valorise les interactions, le produit, la collaboration et le changement plutôt que leurs équivalents de droite.

📖 4. Contraintes et suivi des projets

★ À maîtriser

📌 Dans l'approche classique, le périmètre est fixe et le délai ainsi que le coût sont estimés et variables ; en Scrum, le délai et le coût sont fixes tandis que le périmètre des fonctionnalités livrées varie.

📌 Un diagramme de Gantt suit les heures ou les jours réalisés même si le produit n'est pas livré, tandis qu'un burndown chart ne compte que le travail effectivement livré.

Compléments

• L'approche classique est guidée par le plan, tandis que Scrum est guidé par la valeur et voit le risque diminuer au fil des itérations.

📌 Le modèle classique déroule une seule fois l'analyse, la planification, la conception, la réalisation, les tests et le déploiement, tandis que l'agile répète ce cycle à chaque itération et fait se chevaucher les disciplines.

• Un diagramme de Gantt représente les tâches en lignes et le temps en colonnes, avec une barre par tâche, des liens d'antériorité fin-début, des jalons en losange et une mise en évidence des tâches critiques.

📐 Formule - Le coût d'une tâche correspond à $\text{charge en jours-personnes} \times \text{coût journalier} + \text{coûts matériels et externes}$, et le budget du projet est la somme des coûts des tâches augmentée d'une provision pour risques.

📖 5. Cadre et principes de Scrum

🔑 Notions clés & Définitions

• Scrum : Cadre de développement où des équipes pluridisciplinaires réalisent des produits de manière itérative et incrémentale, en cycles de durée fixe appelés sprints.

★ À maîtriser

• Le thème central de Scrum est d’inspecter et d’adapter en boucle.

• Les trois piliers de Scrum sont la transparence, l’inspection et l’adaptation : les indicateurs sont visibles, l’avancement est suivi régulièrement et les ajustements visent à minimiser les déviations futures.

Compléments

• Les éléments clés de Scrum sont les timeboxes, les rôles et les artefacts ; les timeboxes comprennent le sprint, le sprint planning, le daily scrum, la sprint review et la rétrospective.

• Scrum est surtout utilisé en informatique, mais convient aussi aux projets de conception innovants, aux besoins incertains, aux cahiers des charges susceptibles d’évoluer, à la conception avec les parties prenantes, à l’amélioration continue et à la conduite du changement.

💡 Astuce mémo

Une mêlée où l’équipe inspecte le jeu puis adapte sa stratégie.

📖 6. Rôles et responsabilités Scrum

🔑 Notions clés & Définitions

• Équipe de développement : Pluridisciplinaire, auto-organisée, stable et dédiée à 100 % au produit ; elle choisit les éléments du sprint et la manière de les réaliser.

★ À maîtriser

• Le Product Owner porte la vision du produit, maximise sa valeur et son ROI, et crée, priorise et affine le product backlog.

📌 Le Product Owner accepte ou refuse le travail en revue, mais ne fixe pas la quantité de travail du sprint, qui est choisie par l’équipe.

• Le Scrum Master aide l’équipe, le Product Owner et l’organisation à apprendre et appliquer Scrum ; il supprime les obstacles, protège l’équipe des interférences et facilite les réunions.

Compléments

• Un produit n’a qu’un seul Product Owner, qui anime les décisions sans imposer ses choix de manière autoritaire.

• L’équipe de développement compte environ 7 personnes, soit 7 ± 2 selon le guide, et la diapositive indique un maximum de 8 personnes.

• Le Scrum Master n’est ni chef de projet, ni manager, ni chef d’équipe : il n’assigne pas les tâches et ne dit pas à chacun quoi faire.

• Scrum n’a pas de chef de projet : ses responsabilités sont réparties entre l’équipe et le Product Owner, surtout, et ne sont pas transférées au Scrum Master.

• Le Scrum Master et le Product Owner ne peuvent pas être la même personne, car leurs objectifs diffèrent et leur cumul risque de favoriser le micro-management.

💡 Astuce mémo

Le PO porte la valeur ; le Scrum Master sert l’équipe.

📖 7. Événements et rythme des sprints

🔑 Notions clés & Définitions

• Sprint : Itération de durée constante, d’un mois maximum, qui produit un incrément potentiellement livrable ; les sprints s’enchaînent sans pause.

★ À maîtriser

• Le sprint planning comporte une première partie où le Product Owner présente les éléments prioritaires et où le but du sprint est fixé, puis une seconde partie où l’équipe décompose le travail en tâches pour créer le sprint backlog.

• Le daily scrum s’appuie sur trois questions : Qu’ai-je fait hier ?, Que vais-je faire aujourd’hui ?, Qu’est-ce qui me bloque ?

• La sprint review inspecte et adapte le produit par la manipulation de l’incrément et l’échange avec les parties prenantes, tandis que la rétrospective inspecte et adapte le processus de travail.

• Un sprint ne peut pas être prolongé ; seul le Product Owner peut l’arrêter en cas de changement majeur de priorité.

• Toute nouvelle demande formulée en cours de sprint est ajoutée au product backlog et sera traitée lors d’un sprint suivant.

Compléments

• Le sprint planning dure au maximum une heure par semaine de sprint pour chacune de ses deux parties, soit quatre heures pour un sprint de deux semaines.

• Le daily scrum dure 15 minutes, se tient debout à la même heure chaque jour et est obligatoire pour l’équipe.

• La sprint review dure au maximum une heure par semaine de sprint et sa préparation ne dépasse pas 30 minutes.

• La rétrospective dure au maximum 45 minutes par semaine de sprint ; l’équipe et le Scrum Master y participent, le Product Owner peut être présent et d’autres personnes sont invitées par l’équipe.

• L’affinage du backlog consiste à découper, analyser, ré-estimer et reprioriser les éléments des un ou deux sprints suivants, et ne dépasse pas 10 % de la capacité du sprint.

📌 L’équipe choisit la quantité de travail en prenant les éléments en haut du backlog, et l’objectif du sprint constitue une prévision plutôt qu’une promesse ferme.

📌 Un élément choisi pour un sprint doit pouvoir être terminé par l’équipe en un quart de la durée du sprint au maximum.

• Une release regroupe une série de sprints dont le résultat cumulé a assez de valeur pour être livré au client ; sa durée est fixée par le Product Owner et validée par l’équipe.

• Le pré-sprint sert à constituer l’équipe, définir la vision, produire le backlog initial et planifier la release.

• La vision partagée comprend :

  • L’énoncé du problème à résoudre
  • Une définition claire du produit
  • La liste des fonctionnalités essentielles

📖 8. Artefacts et définitions de fini

🔑 Notions clés & Définitions

• Product backlog : Liste ordonnée de tout ce qui peut être fait sur un produit ; unique par produit, géré par le Product Owner et évoluant tout au long du projet.
• Sprint backlog : Ensemble des éléments retenus pour le sprint et de leur décomposition en tâches, créé par l’équipe.
• Definition of Ready : Indique si une User Story est prête à entrer dans un sprint ; elle vise notamment une description claire et testable, une priorité fixée, des dépendances identifiées et une estimation de l’équipe.
• Definition of Done : Indique si un élément est réellement terminé, avec notamment un code testé, des critères d’acceptation validés, une intégration et une documentation réalisées, et un élément déployable sans travail restant.

★ À maîtriser

• Un bon product backlog est DEEP : détaillé de manière appropriée, estimé, émergent et priorisé par le Product Owner.

• La charte de projet comporte neuf rubriques :

  • vision du produit
  • mission
  • objectifs SMART
  • périmètre
  • parties prenantes et attentes
  • contraintes
  • risques et hypothèses
  • critères de succès
  • KPI de suivi

📌 Les objectifs SMART sont spécifiques, mesurables, atteignables, réalistes et temporellement définis ; par exemple, atteindre 80 % d’utilisateurs testant le module sous 30 jours est mesurable, contrairement à « améliorer l’expérience utilisateur ».

Compléments

• Le product backlog peut contenir :

  • Des nouvelles fonctionnalités
  • Des améliorations techniques
  • Des objectifs d’ingénierie
  • Des travaux exploratoires
  • Des anomalies connues

• Au début, le product backlog contient au plus environ 20 User Stories et ses éléments sont précis à court terme mais grossiers à long terme.

📌 Un incrément interne réduit les risques techniques sans être livrable, un incrément pilote est destiné à des utilisateurs sélectionnés pour valider des spécifications et remonter des défauts, et une mise en production est livrée au client et aux utilisateurs finaux.

📌 La Definition of Done est fixée par le Product Owner et l’équipe avant le premier sprint, doit tendre vers un produit potentiellement livrable et s’étend à mesure que l’équipe progresse.

• La charte de projet comporte un en-tête indiquant le nom du projet, le sponsor, le Product Owner, le Scrum Master et la date.

• La charte distingue le périmètre inclus (in-scope) du périmètre explicitement exclu (out-of-scope).

• La charte prévoit trois conditions de Definition of Ready et trois conditions de Definition of Done, définies pour le projet.

📖 9. Rédiger et découper les User Stories

🔑 Notions clés & Définitions

• User Story : Demande fonctionnelle formulée en langage naturel par un utilisateur et apportant une valeur business au produit.

★ À maîtriser

• Le format d’une User Story comprend trois parties :

  • « En tant que » indique le rôle
  • « Je veux » indique le besoin ou l’action
  • « Afin de » indique le bénéfice métier

• Les critères INVEST caractérisent une User Story :

  • indépendante
  • négociable
  • porteuse de valeur
  • estimable
  • suffisamment petite pour un sprint
  • testable

Compléments

• Une User Story est complétée par des critères d’acceptation testables, une estimation en points et une priorité, par exemple selon MoSCoW ou la valeur.

• La granularité des éléments du backlog va du thème à l’epic, puis à la story et enfin à la tâche.

• Le story mapping permet d’obtenir des User Stories en identifiant les phases d’utilisation, en listant les fonctions sous chaque phase, en les hiérarchisant selon leur importance, puis en transformant chaque fonction en User Story ; les fonctions peuvent ensuite être regroupées par type d’utilisateur.

• Pour rédiger une User Story, il faut : rester simple, décrire le quoi plutôt que le comment, rester dans le périmètre, remplacer les termes ambigus par des valeurs mesurables

📖 10. Prioriser le backlog produit

🔑 Notions clés & Définitions

• Dette technique : Constituée de raccourcis techniques accumulés qui ralentissent les développements suivants ; elle doit être visible dans le backlog et prise en compte dans la priorisation.

★ À maîtriser

📌 La priorisation du backlog repose sur le couple valeur-effort plutôt que sur la valeur seule, afin de traiter d’abord les éléments les plus importants et les plus faciles.

• La matrice de Kano distingue les attentes de base, dont l’absence insatisfait et la présence paraît normale, les attentes proportionnelles, qui augmentent la satisfaction avec leur quantité, et les attentes attractives, dont la présence enthousiasme sans que l’absence insatisfasse ; elle reconnaît aussi les fonctions indifférentes et répulsives.

• MoSCoW classe les éléments en quatre catégories :

  • Must : critique pour le lancement
  • Should : important mais contournable temporairement
  • Could : amélioration sacrifiable si le temps manque
  • Won’t this time : explicitement exclu du périmètre actuel

📐 Formule - Le ROI d’une User Story est $\mathrm{ROI} = \frac{\mathrm{Valeur}}{\mathrm{Effort}}$ et les User Stories sont traitées par ROI décroissant.

Compléments

• Dans une matrice impact-effort, les éléments à fort impact et faible effort sont des quick wins à traiter en premier ; ceux à fort impact et fort effort sont à planifier ; ceux à faible impact et faible effort sont à faire si le temps le permet ; ceux à faible impact et fort effort sont à éviter.

• La méthode de valeur répartie attribue aux User Stories une valeur globale définie, par exemple 500 points, répartis ici en 350 points pour Must, 120 pour Should et 30 pour Could.

• Dans l’exemple de classement, US1 a un ROI de 3,12 et arrive première, US4 a 2,50 et arrive deuxième, US6 a 2,27 et arrive troisième, et US3 a 0,48 et arrive quatrième.

• En agile, le délai et le coût sont fixes ; il faut sécuriser les Must et ajuster les Should et les Could.

💡 Astuce mémo

Valeur seule ≠ couple valeur-effort : un même bénéfice peut passer après s’il coûte davantage.

📖 11. Estimer l’effort des User Stories

🔑 Notions clés & Définitions

• Effort : Coût de réalisation estimé de manière relative en combinant effort, complexité et incertitude, et non en heures ; l’équipe l’estime tandis que le Product Owner apporte la valeur.

★ À maîtriser

• 🔄 Au planning poker, l’équipe suit ces étapes :
  1. Retourner une User Story.
  2. Chaque membre pose sa carte simultanément.
  3. Les valeurs extrêmes sont expliquées.
  4. Revoter jusqu’à un accord.

Compléments

• Avec le T-shirt sizing, l’équipe choisit une User Story de référence, par exemple de taille M correspondant à deux jours, puis classe les autres par comparaison en XS, S, M, L ou XL.

• Le planning poker utilise une suite de Fibonacci, par exemple 1, 2, 3, 5, 8, 13, 20, 40, ∞ et ?, où ∞ signifie que l’élément est trop gros et doit être découpé, et ? qu’il manque d’information.

• Les écarts entre les valeurs de Fibonacci grandissent avec la taille de l’estimation, comme l’incertitude.

📌 Les points ne sont pas des heures et ne sont comparables qu’au sein d’une même équipe.

📌 Une User Story estimée à 20, 40 ou ∞, ou dépassant un quart du sprint, doit être découpée avant d’entrer dans un sprint.

• La vélocité s’exprime dans la même unité que les estimations, c’est-à-dire en points.

💡 Astuce mémo

Planning poker : révéler, voter, expliquer les extrêmes, puis revoter.

📖 12. Vélocité et capacité du sprint

🔑 Notions clés & Définitions

• Vélocité : Somme des points des User Stories terminées conformément à la Definition of Done pendant un sprint ; elle se mesure a posteriori en points.
• Capacité réelle : Capacité théorique diminuée des absences connues et des aléas, tels que les blocages, les incidents et la dette imprévue.

★ À maîtriser

📐 Formule - La capacité théorique est égale au nombre de personnes multiplié par le nombre de jours du sprint : $\mathrm{Capacité\ théorique} = \mathrm{personnes} \times \mathrm{jours\ du\ sprint}$.

📐 Formule - La capacité théorique se calcule ainsi : $\text{Capacité théorique} = \text{nombre de personnes} \times \text{nombre de jours du sprint}$.

Compléments

• La capacité théorique et la capacité réelle s’expriment en jours-personnes, tandis que la vélocité s’exprime en points.

• Pour 4 développeurs et 10 jours ouvrés, la capacité théorique est de 40 jours-personnes ; après 2 jours d’absence et 1 jour d’incident, la capacité réelle est de 37 jours-personnes.

• Avec 37 jours-personnes de capacité réelle, 28 points d’US terminées donnent une vélocité de 28 points.

• Une vélocité moyenne stable, par exemple 26 points par sprint, permet de projeter une date de release ou le nombre de fonctionnalités livrables à une date donnée.

• La planification compte souvent 4 à 6 heures productives par jour et par personne.

📌 Si le rapport entre vélocité et capacité réelle se dégrade à capacité égale, cela signale un problème d’efficacité.

💡 Astuce mémo

Vélocité après le sprint, capacité théorique avant le sprint.

📖 13. Burndown et burnup du projet

🔑 Notions clés & Définitions

• Burndown chart : Un graphique qui affiche jour après jour le travail restant du sprint, en points ou en heures, afin d’évaluer si l’équipe peut terminer le travail prévu ou doit reprioriser.

• Burnup chart : Un graphique qui représente le périmètre total et le travail accompli cumulé ; le projet est terminé lorsque les deux courbes se rejoignent.

★ À maîtriser

• Sur un burndown, le réel au-dessus de la ligne idéale indique un retard et le réel en dessous indique une avance.

Compléments

📐 Formule - Le restant idéal au jour j se calcule ainsi : $\text{Restant idéal}(j) = \text{total} - \left(\frac{\text{total}}{N}\right) \times j$, où N est le nombre de jours.

📐 Formule - Le travail restant réel se calcule ainsi : $\text{Restant}(j) = \text{Restant}(j-1) - \text{points terminés}(j) + \text{points ajoutés}(j)$.

• Pour construire un burndown, on fixe le total engagé au jour 0, trace la ligne idéale jusqu’à zéro, reporte chaque jour le restant réel selon les travaux terminés et ajoutés, puis compare les lignes et interroge l’équipe sur les écarts.

• Les cinq profils de burndown sont :

  • Le profil nominal.
  • Le retard progressif.
  • L’avance.
  • Le blocage puis rattrapage.
  • L’ajout de périmètre, ou scope creep.

• Un burndown déclenche des questions à l’équipe mais n’explique pas à lui seul la cause d’un écart ; une remontée peut notamment venir d’un ajout de périmètre ou d’une erreur de saisie.

• Dans l’exemple étudié, le périmètre passe de 192 à 205, 216 puis 231 points, avec des ajouts de 13, 11 et 15 points aux sprints 3 à 5, avant d’être réduit à 212 points au sprint 9.

• Dans cet exemple, la vélocité des dix sprints est de 25, 20, 19, 18, 22, 26, 25, 21, 20 et 16 points, soit une moyenne de 21,2 points par sprint.

• Dans l’exemple du burnup, les courbes se rejoignent au sprint 10 après le retrait de 19 points par le PO selon un arbitrage MoSCoW ; avec le périmètre de 231 points, il restait environ 19 points, soit près d’un sprint de travail.

💡 Astuce mémo

Le burndown suit le travail restant ; le burnup distingue aussi le périmètre.

📖 14. Flux de travail et outils de suivi

🔑 Notions clés & Définitions

• Cumulative Flow Diagram : Un diagramme qui représente dans le temps les bandes cumulées À faire, En cours et Terminé, et montre où le travail s’accumule dans le flux.

★ À maîtriser

📌 Le lead time va de l’arrivée dans le backlog à la livraison, tandis que le cycle time va du début du travail à la livraison.

Compléments

📌 L’élargissement de la bande « En cours » dans un CFD signale un goulot d’étranglement.

• Les outils et leurs possibilités de graphiques sont les suivants :
  • Jira propose nativement burndown, burnup et CFD.
  • Azure DevOps propose nativement burndown, burnup et CFD.
  • Trello avec Power BI nécessite des exports pour créer les graphiques.
  • ClickUp, Monday, iceScrum et Notion sont également cités.

💡 Astuce mémo

Dans le CFD, imaginez trois bandes qui s’élargissent ou se resserrent au fil du temps.

📖 15. Pertinence et limites de l’agile

★ À maîtriser

📌 L’agile est recommandée pour les produits ou services fortement innovants, tandis qu’une approche classique est préférable pour les variantes de produits existants dont les besoins sont stables.

📌 L’agile n’est pas une méthode universelle et, sans Product Owner, il est inutile d’imaginer pouvoir être agile.

• Le filtre de pertinence du PMI évalue trois blocs :
  • Culture : adhésion, confiance et autonomie de décision.
  • Équipe : taille, expérience et accès au client ou au métier.
  • Projet : taux de changement, criticité et livraison incrémentale.

Compléments

• L’agile peut échouer lorsqu’elle est considérée comme une solution miracle, ressentie comme lourde, privée de soutien managérial ou technique, ou imposée d’en haut sans corriger les problèmes révélés par Scrum.

• Les principaux freins à l’agile sont la résistance au changement, illustrée par le virage raté de la MACIF en 2012, et le manque de lâcher-prise du management, qui doit accepter de faire confiance à l’équipe.

📌 Dans la lecture du radar du filtre de pertinence, un profil proche du centre indique une approche agile, une position intermédiaire une approche hybride et un profil à l’extérieur une approche prédictive.

• Les exemples du guide associent un projet de pharmacie à l’agile et une messagerie militaire à l’approche prédictive.

• La maturité de l’agile se manifeste par la disponibilité d’outils, y compris open source, de formations et de certifications, ainsi que par des positions favorables d’organismes de référence comme le PMI ; le Gartner Group invite à abandonner le cycle en V.

📊 Tableaux de synthèse

Approches classique et agile

Definition of Ready et Definition of Done