Gestion de projet Scrum : le guide complet

Cette courte leçon annonce le glossaire des termes anglais employés en Scrum, comme sprint, product backlog ou scrum master, afin de faciliter la compréhension de la suite de la formation sur la méthodologie Scrum.

Cet article regroupe la définition en français des principaux termes du vocabulaire Scrum : sprint, product backlog, sprint planning, daily scrum, sprint review, sprint retrospective, planning poker, product owner, scrum master, story point, user story et burndown chart. Une ressource pratique à garder sous la main tout au long de la formation.

Cette leçon présente une vue d'ensemble complète du cadre de travail Scrum, défini en 1995 par Ken Schwaber et Jeff Sutherland : l'équipe Scrum et ses trois rôles, le product backlog composé de user stories priorisées, et le déroulement d'un sprint à travers un exemple concret de développement d'une application mobile de fitness. Un point de départ clair avant d'entrer dans le détail de chaque rôle et évènement Scrum.

Cette leçon détaille les trois piliers sur lesquels repose la méthodologie Scrum, la transparence, l'inspection et l'adaptation, ainsi que les cinq valeurs Scrum résumées par l'acronyme mnémotechnique F.O.R.C.E (Focus, Ouverture, Respect, Courage, Engagement). Des repères essentiels pour comprendre la philosophie qui sous-tend le cadre de travail Scrum, au-delà des simples rôles et évènements.

Cet article complète la leçon précédente en listant plusieurs outils en ligne pour gérer un tableau Scrum de façon transparente, comme Trello, Yodiz, ScrumDo, ScrumWise, VivifyScrum ou ZohoSprints.

Cette leçon détaille le rôle du Product Owner dans une équipe Scrum : porter la voix du client, créer et prioriser le product backlog, et garder la responsabilité finale sur son contenu. Elle précise que ce rôle peut être occupé par un chef de produit ou tout autre profil ayant une bonne connaissance du produit, un repère utile pour toute organisation qui démarre une transformation Agile.

Cette leçon présente le rôle des développeurs dans l'équipe Scrum, c'est-à-dire tous les membres qui transforment le product backlog en incrément de produit à chaque sprint, quelle que soit leur spécialité (développement, analyse fonctionnelle, qualité, architecture). Elle rappelle leurs responsabilités : élaborer un plan d'actions, respecter la Definition of Done et ajuster leur travail quotidiennement.

Cette leçon explique les deux caractéristiques essentielles d'une équipe Scrum : elle est pluridisciplinaire, capable de livrer une fonctionnalité de bout en bout sans ressource externe, et autogérée, sans hiérarchie interne. Un retour d'expérience sur une équipe scindée en deux pour rester productive illustre pourquoi il est recommandé de ne pas dépasser une dizaine de personnes par équipe Scrum.

Cette leçon détaille le rôle du Scrum Master, à la fois coach de l'équipe et de l'organisation, facilitateur des évènements Scrum et protecteur de l'équipe face aux sollicitations externes qui menacent l'objectif du sprint. Elle précise aussi ce que le Scrum Master n'est pas : ni le chef de l'équipe, ni son secrétaire, ni un intermédiaire obligatoire entre le Product Owner et les développeurs.

Cette leçon distingue les parties prenantes internes et externes d'un projet Scrum, comme les équipes marketing et commerciale, les managers, les clients ou les investisseurs, et précise leur rôle lors de la sprint review. Elle rappelle l'importance d'une communication régulière entre l'équipe Scrum et les parties prenantes pour bien comprendre leurs besoins et leurs contraintes.

Cette leçon définit le sprint, cycle de travail Scrum d'un mois ou moins au cœur duquel toute la valeur du produit est créée, et rappelle les règles qui encadrent son déroulement : l'objectif du sprint et les standards de qualité restent fixes, tandis que le scope peut être clarifié avec le product owner en cours de route. Elle précise aussi que seul le product owner peut annuler un sprint, et uniquement si son objectif devient obsolète.

Cette leçon détaille le sprint planning, l'évènement Scrum qui ouvre chaque sprint et répond à trois questions : pourquoi ce sprint est important, que peut faire l'équipe pendant le sprint et comment le travail sera réalisé. Elle précise la durée maximale de cette réunion et rappelle que ce sont les développeurs, et non le Product Owner, qui décident de la quantité de travail à laquelle ils s'engagent.

Cette leçon présente le daily scrum, la réunion quotidienne de 15 minutes maximum réservée aux développeurs pour se synchroniser et lever les points bloquants du sprint en cours. Elle donne des bonnes pratiques concrètes comme la méthode des 3 questions, l'intérêt de faire cette réunion debout et un exemple de daily scrum organisé à distance pour une équipe répartie sur plusieurs sites.

Cette leçon explique le rôle de la sprint review, l'avant-dernier évènement du sprint pendant lequel l'équipe Scrum présente aux parties prenantes et au client le travail accompli et recueille leurs retours. Elle insiste sur le fait que cette réunion doit être une vraie session de travail collaborative, et non une simple présentation où le client reste spectateur.

Cette leçon détaille la sprint retrospective, le dernier évènement du sprint consacré à l'amélioration continue du processus de travail de l'équipe Scrum plutôt qu'au produit lui-même. Elle explique le déroulement type d'une rétrospective en cinq étapes, de l'ouverture de la session jusqu'à l'élaboration d'un plan d'actions concret pour le sprint suivant.

Cet article complète la leçon sur la sprint retrospective avec des activités supplémentaires pour animer cette réunion de façon ludique et des outils en ligne pour faciliter son organisation.

Cette leçon bonus présente le speed boat retrospective, une technique ludique et visuelle pour animer une sprint retrospective à l'aide d'un dessin de bateau, d'une île, du vent, de rochers et d'une ancre symbolisant respectivement l'équipe, l'objectif, les éléments moteurs, les risques futurs et les freins rencontrés pendant le sprint. Un format concret et facile à reproduire pour dynamiser les rétrospectives d'une équipe Scrum.

Cette leçon présente le backlog refinement, une réunion qui ne fait pas officiellement partie du guide Scrum mais que la plupart des équipes utilisent pour clarifier, détailler et estimer les prochains éléments du product backlog. Elle explique qui y participe, à quel rythme l'organiser et comment elle prépare concrètement l'équipe à démarrer le sprint suivant sereinement.

Cette leçon explique comment organiser un product backlog volumineux à l'aide de différents niveaux de granularité : les thèmes, les epics, les user stories et les tâches, illustrés par un exemple de fonctionnalité de liste de favoris sur une boutique en ligne. Elle présente aussi les notions de spike et de bug dans le product backlog, deux éléments à intégrer à la même liste que les user stories pour garder une visibilité complète du travail à faire.

Cette leçon donne une méthode simple pour rédiger une user story claire et compréhensible par tous les acteurs d'un projet Scrum : un titre explicite, une phrase suivant le modèle « en tant que… je souhaite… pour… » et des critères d'acceptation. Un exemple concret de fonctionnalité de liste de favoris illustre comment transformer une demande fonctionnelle classique en user story exploitable par une équipe Scrum.

Cette leçon présente la Definition of Ready, une liste de critères qu'une user story doit remplir pour être candidate au développement, comme un titre explicite, une estimation et des critères d'acceptation clairs. Une pratique qui n'est pas officiellement décrite dans le guide Scrum mais qui aide l'équipe à garantir un certain niveau de qualité avant qu'une user story n'entre dans un sprint.

Cette leçon présente la méthode INVEST, un ensemble de six critères pour vérifier la qualité d'une user story : Indépendante, Négociable, apportant de la Valeur, Estimable, suffisamment petite (Small) et Testable. Des exemples concrets, notamment issus d'un projet de gestion de bibliothèque, illustrent chaque critère pour rédiger des user stories réellement exploitables par une équipe Scrum.

Cette leçon présente la méthode MoSCoW pour prioriser un product backlog volumineux : Must have, Should have, Could have et Won't have. Elle explique le lien entre la catégorie Must have et le concept de Produit Minimum Viable, et propose d'organiser cette priorisation sous forme d'atelier collectif avec les parties prenantes du projet.

Cette leçon présente la Definition of Done, l'ensemble des critères qui permettent de dire qu'une user story est réellement terminée, comme les tests de régression passés ou la documentation client mise à jour. Elle explique qui définit cette Definition of Done au sein d'une organisation et pourquoi elle doit rester fixe pendant toute la durée d'un sprint.

Cet article présente les DOD Kards, un jeu de cartes créé par Camilo Velasquez et Thomas Wallet pour construire collectivement la Definition of Done d'une équipe Scrum de façon ludique, en votant oui, non ou plus tard sur chaque critère proposé. Une méthode concrète et facile à mettre en place lors d'un atelier d'équipe.

Cette leçon introduit les techniques d'estimation utilisées en Scrum et explique pourquoi l'estimation des user stories, bien que facultative selon le guide Scrum, permet de vérifier qu'une user story tient dans un sprint et de générer des indicateurs de performance utiles à l'équipe. Elle précise que l'estimation Scrum se fait toujours de façon collective et relative, par comparaison avec des user stories de référence.

Cette leçon présente le planning poker, la technique d'estimation la plus utilisée en Scrum, basée sur des cartes reprenant la suite de Fibonacci pour estimer l'effort global d'une user story. Elle détaille le déroulement d'une session de vote et comment gérer les désaccords entre développeurs pour converger vers une estimation partagée par toute l'équipe.

Cette leçon présente deux techniques d'estimation alternatives au planning poker : le bucket system, qui utilise des conteneurs pour classer rapidement un grand nombre de user stories, et le T-shirt sizing, qui utilise des tailles de vêtement (XS à XL) pour estimer rapidement la complexité d'une fonctionnalité. Des méthodes utiles quand il faut estimer beaucoup d'éléments du product backlog en peu de temps.

Cette leçon présente le mouvement NoEstimate, qui propose de ne plus estimer numériquement les éléments du product backlog et d'avancer selon une vision qui s'adapte au fur et à mesure. Elle explique les raisons qui poussent certaines équipes Scrum à abandonner l'estimation chiffrée tout en gardant une compréhension globale de l'effort nécessaire à chaque user story.

Cette leçon présente la vélocité, un indicateur de performance qui mesure la quantité de travail accomplie par une équipe Scrum à chaque sprint en additionnant les story points des user stories terminées. Elle met en garde contre une mauvaise utilisation de la vélocité par le management, notamment la comparaison entre équipes, qui n'a pas de sens puisque chaque équipe possède son propre système d'estimation.

Cette leçon présente le burndown chart, un graphique qui représente la quantité de travail restant à effectuer avant la fin d'un sprint par rapport au temps, et explique comment le construire à partir des tâches estimées par les développeurs. Un outil de suivi visuel qui permet à l'équipe Scrum de voir rapidement si elle est en avance ou en retard sur son objectif de sprint.

Cette leçon présente le burn up chart, qui montre le travail accompli par rapport au scope prévu d'un projet, à la différence du burndown chart qui montre le travail restant. Elle explique pourquoi une augmentation du scope sur ce graphique n'est pas un signal d'alerte en Agile, et comment cet indicateur permet d'estimer la date de fin approximative d'un projet mené en Scrum.

Cette leçon présente le diagramme de flow cumulé, ou cumulative flow diagram, qui représente graphiquement les tâches à faire, en cours et terminées d'un sprint pour repérer les goulots d'étranglement dans le travail d'une équipe Scrum. Un exemple concret montre comment ce graphique permet de détecter qu'une équipe commence trop de tâches en parallèle sans les terminer.

Cette leçon déroule un exemple complet et concret de projet mené en Scrum, la mise en place d'un système de gestion pour une bibliothèque municipale, de la constitution de l'équipe et du product backlog jusqu'au premier sprint planning, daily scrum, sprint review et rétrospective. Une synthèse pratique qui permet de voir comment tous les rôles, évènements et artefacts Scrum vus dans la formation s'articulent réellement sur un projet.

Cet article donne accès au Guide Scrum officiel en anglais et à sa traduction en français, la référence principale pour préparer la certification PSM et pour approfondir sa compréhension du cadre de travail Scrum au-delà de cette formation.

Cette leçon de conclusion félicite les participants pour avoir terminé la formation sur la méthodologie Scrum et les encourage à mettre en pratique le cadre de travail vu tout au long du cours.

Cette leçon indique comment rester en contact avec le formateur et suivre son actualité au-delà de la formation.

Cette leçon bonus donne accès à des ressources complémentaires liées à la méthodologie Scrum.