Méthode Scrum : définition, rôles, événements et mise en place

La méthode Scrum est un cadre agile conçu pour piloter un projet complexe : un produit dont le besoin évolue, une équipe qui doit livrer souvent, des priorités qui changent. Elle repose sur peu d’éléments : trois responsabilités, cinq événements, trois artefacts et des règles qui les relient. Ces éléments sont définis dans un document unique, le Scrum Guide, rédigé par les deux créateurs de Scrum, Ken Schwaber et Jeff Sutherland.

Ce guide présente la méthodologie Scrum telle qu’elle est décrite dans la version en vigueur du Scrum Guide (novembre 2020, traduite en français) : sa définition, ses piliers et ses valeurs, les rôles de l’équipe Scrum, le déroulé d’un Sprint, les artefacts, puis la mise en place pas à pas, les avantages, les limites et les erreurs fréquentes. Pour choisir un logiciel, reportez-vous à notre comparatif des logiciels de gestion de projet agile.

Qu’est-ce que la méthode Scrum ?

Le Scrum Guide donne cette définition : « Scrum est un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. » On parle couramment de « méthode Scrum », mais ses auteurs emploient le terme de cadre de travail (framework) : Scrum ne décrit pas comment faire chaque tâche, il fixe une structure dans laquelle l’équipe choisit ses propres pratiques.

Le guide résume le fonctionnement en quatre temps. Un Scrum Master favorise un environnement où :

• un Product Owner ordonne le travail à faire dans le Product Backlog ;
• la Scrum Team transforme une sélection de ce travail en un Increment de valeur lors d’un Sprint ;
• la Scrum Team et ses parties prenantes inspectent les résultats et s’adaptent pour le Sprint suivant ;
• et le cycle se répète.

Le cadre est volontairement incomplet : il ne définit que ce qui est nécessaire pour appliquer la théorie Scrum. Le guide précise aussi que Scrum « n’existe que dans sa totalité » : appliquer seulement certaines parties est possible, mais le résultat n’est alors plus du Scrum.

En résumé, la méthode Scrum tient en une grille simple, souvent appelée « 3-5-3 » :

Scrum et agile : quelle différence ?

L’agilité désigne un ensemble de valeurs et de principes formalisés dans le Manifeste pour le développement Agile de logiciels, publié en 2001. Scrum est un cadre de travail concret qui applique cette philosophie. Toute équipe qui pratique Scrum travaille de manière agile, mais une équipe agile peut utiliser d’autres approches, comme Kanban ou l’Extreme Programming (XP). Les deux créateurs de Scrum, Ken Schwaber et Jeff Sutherland, figurent d’ailleurs parmi les signataires du Manifeste. Pour une vue d’ensemble de l’agilité, consultez notre article sur l’essentiel de la gestion de projet agile.

Origine et histoire de Scrum

Le mot « scrum » vient du rugby : il désigne la mêlée. Dans l’article de 1995 où il présente la méthode, Ken Schwaber explique l’avoir nommée ainsi en référence à la mêlée du rugby et à un article de Hirotaka Takeuchi et Ikujiro Nonaka, « The New New Product Development Game », publié dans la Harvard Business Review en janvier 1986. Takeuchi et Nonaka y décrivaient le travail de petites équipes très performantes dans le développement de nouveaux produits, chez des industriels comme Honda, Canon ou Fuji-Xerox, et soulignaient qu’il fallait désormais de la vitesse et de la flexibilité en plus de la qualité, du coût et de la différenciation.

Les grandes étapes, d’après les créateurs de Scrum :

• Début des années 1990 : Ken Schwaber et Jeff Sutherland développent Scrum. Selon sa biographie sur scrumguides.org, Jeff Sutherland a développé la méthode en 1993 et l’a formalisée en 1995 avec Ken Schwaber.
• 1995 : les deux auteurs présentent Scrum pour la première fois ensemble à la conférence OOPSLA, ce qui rend publique la première définition formelle de Scrum (article « SCRUM Development Process » de Ken Schwaber).
• 2001 : dix-sept spécialistes du développement logiciel, dont des représentants de Scrum et de l’Extreme Programming, se réunissent en février à Snowbird (Utah). Il en sort le Manifeste agile.
• 2010 : première version du Scrum Guide, « pour aider les gens du monde entier à comprendre Scrum ».
• Novembre 2020 : version actuelle du guide, plus courte et moins prescriptive que celle de 2017.

Les changements de 2020 expliquent pourquoi beaucoup de contenus en ligne sont aujourd’hui datés : l’« équipe de développement » a disparu au profit d’une seule Scrum Team, les trois questions du Daily Scrum ont été supprimées, l’Objectif de Produit a été ajouté et l’équipe est désormais décrite comme « autogérée » plutôt qu’« auto-organisée ».

Les 3 piliers de Scrum : transparence, inspection, adaptation

Scrum est fondé sur l’empirisme et la pensée Lean. L’empirisme affirme que la connaissance provient de l’expérience et que les décisions s’appuient sur l’observation des faits ; la pensée Lean réduit le gaspillage et se concentre sur l’essentiel. Scrum adopte donc une approche itérative et incrémentale pour améliorer la prévisibilité et maîtriser le risque. Trois piliers rendent cet empirisme possible :

• Transparence : le processus et le travail doivent être visibles pour ceux qui le réalisent comme pour ceux qui le reçoivent. Les décisions importantes reposent sur l’état des trois artefacts ; des artefacts opaques conduisent à de mauvaises décisions.
• Inspection : les artefacts et la progression vers les objectifs sont examinés fréquemment pour détecter les écarts. Les cinq événements Scrum donnent la cadence de cette inspection.
• Adaptation : si un aspect du processus ou du produit s’écarte des limites acceptables, il est ajusté le plus vite possible.

Les piliers s’enchaînent : la transparence permet l’inspection, et l’inspection permet l’adaptation. Une inspection sans adaptation est jugée « infructueuse » par le guide.

Les 5 valeurs Scrum

Selon le guide, la réussite de Scrum dépend de la capacité des personnes à vivre cinq valeurs : engagement, focus, ouverture, respect et courage.

• Engagement : la Scrum Team s’engage à atteindre ses objectifs et à se soutenir mutuellement.
• Focus : le but principal de l’équipe est la réalisation du Sprint, pour progresser le plus possible vers ses objectifs.
• Ouverture : l’équipe et ses parties prenantes sont ouvertes sur le travail et les défis à relever.
• Respect : les membres se considèrent mutuellement comme des personnes compétentes et indépendantes.
• Courage : les membres ont le courage de mener les bonnes actions et de travailler sur des problèmes difficiles.

Lorsque ces valeurs sont partagées, les trois piliers (transparence, inspection, adaptation) prennent vie et la confiance s’installe entre l’équipe et ses interlocuteurs.

Les rôles Scrum : la Scrum Team et ses 3 responsabilités

L’unité de base de Scrum est une petite équipe, la Scrum Team, composée d’un Scrum Master, d’un Product Owner et de Developers. Il n’y a ni sous-équipe ni hiérarchie à l’intérieur. L’équipe est pluridisciplinaire (elle réunit toutes les compétences nécessaires pour créer de la valeur à chaque Sprint) et autogérée (elle décide en interne qui fait quoi, quand et comment).

Depuis 2020, le guide ne parle plus de « rôles » mais de trois responsabilités (accountabilities). Dans la pratique, les deux termes restent utilisés.

Le Product Owner

Le Product Owner est responsable de maximiser la valeur du produit issu du travail de l’équipe. Il est aussi responsable de la gestion du Product Backlog : formuler et communiquer l’Objectif de Produit, créer et expliquer les éléments du backlog, les ordonner et s’assurer que le backlog est transparent, visible et compris. Il peut déléguer une partie de ce travail, mais en reste redevable.

Deux règles du guide sont souvent oubliées : le Product Owner est une personne et non un comité, et toute l’organisation doit respecter ses décisions. Ceux qui veulent modifier le backlog doivent le convaincre. Pour approfondir ce rôle, lisez ce qu’il faut pour être un bon Product Owner.

Le Scrum Master

Le Scrum Master est responsable de la mise en place de Scrum tel que défini dans le guide et de l’efficacité de la Scrum Team. Le guide le décrit comme « un véritable leader au service de la Scrum Team et de l’ensemble de l’organisation ». Ce n’est pas un chef de projet qui distribue les tâches.

• Pour l’équipe : il accompagne l’autogestion et la pluridisciplinarité, aide à créer des Increments qui respectent la Definition of Done, fait lever les obstacles et veille à ce que les événements aient lieu, soient productifs et respectent leur durée maximale.
• Pour le Product Owner : il l’aide à définir l’Objectif de Produit et à gérer le backlog, et facilite la collaboration avec les parties prenantes.
• Pour l’organisation : il forme et accompagne l’adoption de Scrum et aide à lever les obstacles entre les parties prenantes et les équipes.

Les Developers

Les Developers sont les membres de la Scrum Team qui s’engagent à produire un Increment utile à chaque Sprint. Le terme ne désigne pas uniquement des développeurs informatiques : le guide cite aussi les chercheurs, les analystes, les scientifiques et d’autres spécialistes, et précise employer le mot « Developers » « pour simplifier ». Les Developers sont redevables de quatre choses :

• créer le plan du Sprint, c’est-à-dire le Sprint Backlog ;
• garantir la qualité en respectant la Definition of Done ;
• adapter leur plan chaque jour en fonction de l’Objectif de Sprint ;
• se tenir mutuellement responsables en tant que professionnels.

Quelle taille pour une équipe Scrum ?

La Scrum Team doit être assez petite pour rester réactive et assez grande pour accomplir un travail significatif : habituellement 10 personnes au plus. Au-delà, le guide recommande de se réorganiser en plusieurs Scrum Teams qui partagent le même Objectif de Produit, le même Product Backlog et le même Product Owner. Pour coordonner beaucoup d’équipes, des cadres complémentaires existent, comme le Scaled Agile Framework (SAFe).

Gouvernance d’un projet agile : qui décide quoi ?

La gouvernance d’un projet agile mené avec Scrum est répartie entre les trois responsabilités, ce qui évite le « chef de projet fourre-tout » :

Les 5 événements Scrum (cérémonies)

Scrum combine quatre événements formels d’inspection et d’adaptation à l’intérieur d’un événement conteneur, le Sprint. On parle souvent de « cérémonies » ou de « rituels », mais le guide emploie le mot événements. Chacun a une durée maximale (on parle de timebox). Idéalement, ils se tiennent toujours à la même heure et au même endroit. Notre article sur les cérémonies Scrum détaille leur animation.

Le Sprint

Le Sprint est le cœur de Scrum : une période de durée fixe, d’un mois ou moins, pendant laquelle les idées deviennent de la valeur. Un nouveau Sprint commence immédiatement après la fin du précédent. Pendant le Sprint :

• aucun changement mettant en cause l’Objectif de Sprint n’est permis ;
• les exigences de qualité ne sont jamais revues à la baisse ;
• le Product Backlog est affiné si nécessaire ;
• le périmètre peut être clarifié et renégocié avec le Product Owner.

Des Sprints plus courts raccourcissent le cycle d’apprentissage et limitent le risque. Un Sprint peut être annulé si son objectif devient obsolète, et seul le Product Owner peut prendre cette décision.

Le Sprint Planning (planification de sprint)

Le Sprint Planning lance le Sprint. Toute la Scrum Team y travaille sur trois questions :

• Pourquoi ce Sprint est-il important ? L’équipe définit un Objectif de Sprint.
• Que peut-on faire pendant ce Sprint ? Les Developers sélectionnent, avec le Product Owner, les éléments du Product Backlog à traiter.
• Comment le travail sera-t-il réalisé ? Les Developers planifient le travail, souvent en découpant les éléments en tâches d’une journée ou moins.

Durée maximale : 8 heures pour un Sprint d’un mois, généralement moins pour un Sprint plus court. Voir aussi notre guide du sprint planning.

Le Daily Scrum (mêlée quotidienne)

Le Daily Scrum est un événement de 15 minutes réservé aux Developers, chaque jour ouvré du Sprint, à la même heure et au même endroit. Son but : inspecter la progression vers l’Objectif de Sprint et adapter le plan pour la journée suivante. Le Product Owner et le Scrum Master n’y participent en tant que Developers que s’ils travaillent eux-mêmes sur des éléments du Sprint Backlog.

Les trois questions classiques (ce qui a été fait la veille, ce qui sera fait dans la journée, les obstacles rencontrés) ne figurent plus dans le guide depuis 2020 : les Developers choisissent librement la structure du Daily, du moment qu’il porte sur l’Objectif de Sprint et produit un plan d’action.

La Sprint Review (revue de sprint)

La Sprint Review sert à inspecter le résultat du Sprint et à décider des adaptations futures. La Scrum Team présente son travail aux principales parties prenantes, puis tous examinent ce qui a été fait et ce qui a changé dans l’environnement ; le Product Backlog peut être ajusté en conséquence. Le guide insiste : c’est une session de travail, pas une simple démonstration. Durée maximale : 4 heures pour un Sprint d’un mois.

La Sprint Retrospective (rétrospective de sprint)

La Sprint Retrospective clôt le Sprint. La Scrum Team examine le déroulement du Sprint (personnes, interactions, processus, outils, Definition of Done), identifie ce qui a bien fonctionné et les problèmes rencontrés, puis retient les améliorations les plus utiles, qui peuvent être ajoutées au Sprint suivant. Durée maximale : 3 heures pour un Sprint d’un mois. Pour des idées d’animation, consultez notre article sur la rétrospective de sprint.

Durées maximales des événements Scrum

Pour un Sprint plus court, le guide indique seulement que les événements sont « généralement plus courts ». Les règles proportionnelles que l’on trouve en ligne (par exemple une heure de Sprint Review par semaine de Sprint) sont des habitudes de terrain, pas des règles du guide.

Les 3 artefacts Scrum et leurs engagements

Les artefacts représentent un travail ou une valeur. Ils servent à rendre visibles les informations clés, pour que tous ceux qui les inspectent partagent la même base. Depuis 2020, chaque artefact est relié à un engagement qui permet de mesurer la progression. Notre article sur les artefacts Scrum les détaille avec des exemples.

Le Product Backlog et l’Objectif de Produit

Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. C’est l’unique source du travail de la Scrum Team. Ses éléments sont régulièrement affinés (on parle de refinement) : découpés, décrits, ordonnés et dimensionnés. Les Developers qui feront le travail sont responsables du dimensionnement. Sur ce sujet, voir notre article sur le backlog refinement.

Son engagement est l’Objectif de Produit : l’état futur du produit vers lequel l’équipe travaille. C’est l’objectif à long terme de la Scrum Team, qui doit l’atteindre (ou l’abandonner) avant de passer au suivant.

Le Sprint Backlog et l’Objectif de Sprint

Le Sprint Backlog réunit trois choses : l’Objectif de Sprint (le pourquoi), les éléments du Product Backlog retenus pour le Sprint (le quoi) et le plan pour livrer l’Increment (le comment). Il est élaboré par et pour les Developers et mis à jour tout au long du Sprint.

Son engagement est l’Objectif de Sprint, but unique du Sprint fixé pendant le Sprint Planning. Si le travail s’avère différent de ce qui était prévu, les Developers renégocient le périmètre avec le Product Owner sans remettre en cause cet objectif.

L’Increment et la Definition of Done

Un Increment est une étape concrète vers l’Objectif de Produit. Il s’ajoute aux Increments précédents et doit être utilisable. Plusieurs Increments peuvent être créés pendant un Sprint, et un Increment peut être livré avant la fin du Sprint : la Sprint Review n’est pas le seul moment pour livrer de la valeur.

Son engagement est la Definition of Done (définition de « fini ») : la description formelle de l’état de l’Increment lorsqu’il atteint les exigences de qualité du produit. Un travail qui ne la respecte pas n’est pas un Increment : il ne peut être ni publié ni présenté en Sprint Review et retourne dans le Product Backlog.

Pratiques complémentaires : user stories, estimation, burndown et scrum board

Beaucoup de notions associées à Scrum ne figurent pas dans le Scrum Guide. Elles sont utiles, mais facultatives, et le guide laisse l’équipe libre de les adopter :

• User stories : courtes descriptions d’un besoin du point de vue de l’utilisateur. Elles figurent parmi les règles de planification de l’Extreme Programming (« User stories are written »), pas dans le Scrum Guide.
• Estimation (story points, planning poker) : techniques pour dimensionner les éléments du backlog, une tâche que le guide confie aux Developers sans imposer de méthode.
• Burndown, burn-up, diagramme de flux cumulé : le guide les cite comme pratiques utiles pour suivre la progression, tout en rappelant qu’elles ne remplacent pas l’empirisme.
• Scrum board : tableau (physique ou numérique) qui rend visible le Sprint Backlog, colonne par colonne (à faire, en cours, terminé). Voir notre comparaison scrum board vs kanban board.

Comment mettre en place la méthode Scrum dans une équipe

Le guide recommande d’essayer Scrum « tel qu’il est » avant de juger s’il aide à atteindre les objectifs. Voici une mise en place pas à pas, valable pour une équipe informatique comme pour une équipe marketing ou produit.

• 1. Lire le Scrum Guide. Le document officiel, gratuit, est disponible en français sur scrumguides.org. C’est le référentiel officiel de Scrum ; toute l’équipe et ses managers devraient le lire.
• 2. Constituer la Scrum Team. Désignez un Product Owner disponible et légitime pour décider, un Scrum Master et des Developers qui couvrent toutes les compétences nécessaires (10 personnes au plus en général).
• 3. Formuler l’Objectif de Produit et créer le Product Backlog. Le backlog n’a pas besoin d’être complet : il doit contenir assez d’éléments clairs et ordonnés pour démarrer, puis il évoluera.
• 4. Écrire la Definition of Done. Que signifie « fini » pour votre produit (relu, testé, validé, mis en ligne…) ? Sans cette définition, il n’y a pas d’Increment mesurable.
• 5. Choisir la durée du Sprint et caler l’agenda. Une durée fixe d’un mois maximum, et des événements à heure et lieu réguliers.
• 6. Lancer le premier Sprint Planning. Définissez l’Objectif de Sprint, sélectionnez les éléments et construisez le Sprint Backlog.
• 7. Tenir le Daily Scrum chaque jour, en 15 minutes, centré sur l’Objectif de Sprint.
• 8. Organiser la Sprint Review avec les parties prenantes, puis ajuster le Product Backlog.
• 9. Faire la Sprint Retrospective et choisir une ou deux améliorations concrètes pour le Sprint suivant.
• 10. Recommencer. Le Sprint suivant démarre immédiatement après.

Pour structurer le cadrage en amont, vous pouvez vous appuyer sur notre méthode en 5 étapes pour planifier un projet.

Avantages et inconvénients de la méthode Scrum

Les avantages de Scrum

• Un risque mieux maîtrisé : l’approche itérative et incrémentale vise à améliorer la prévisibilité et le contrôle du risque. Des Sprints courts raccourcissent le cycle d’apprentissage.
• Une visibilité permanente : les artefacts et les événements rendent l’avancement et les problèmes visibles pour l’équipe comme pour les parties prenantes.
• Des livraisons régulières : la Scrum Team est responsable de créer un Increment utile à chaque Sprint, et un Increment peut même être livré avant la fin du Sprint.
• Moins de réunions improvisées : le guide indique que les événements créent de la régularité et réduisent le besoin d’autres réunions.
• Une équipe responsabilisée : l’autogestion laisse aux Developers le choix du « comment ».
• Un cadre léger et gratuit : le guide officiel est gratuit et le cadre tient en quelques règles.

Les inconvénients et limites de Scrum

• Un cadre volontairement incomplet : Scrum ne dit pas comment estimer, découper ou tester. L’équipe doit choisir ses pratiques, ce qui demande de l’expérience.
• Une forte dépendance au Product Owner : s’il est peu disponible ou si ses décisions ne sont pas respectées par l’organisation, le backlog se dégrade vite.
• Une exigence d’autogestion : le modèle suppose que le management délègue réellement le « comment » à l’équipe.
• Un révélateur plus qu’un remède : le guide indique que Scrum « rend visible l’efficacité relative du management existant, de l’environnement et des techniques de travail ». Il montre les problèmes, il ne les corrige pas seul.
• Tout ou rien : appliquer une partie seulement du cadre n’est plus du Scrum, selon ses auteurs.
• Moins d’intérêt pour un travail prévisible : Scrum est pensé pour des problèmes complexes. Pour un projet au périmètre figé, une approche séquentielle comme le cycle en V ou la méthode Waterfall peut suffire.

Les erreurs fréquentes dans un projet Scrum

• Faire du Scrum Master un chef de projet qui assigne et valide les tâches, alors que son rôle est de servir l’équipe et de faire respecter le cadre.
• Un Product Owner en comité ou sans pouvoir de décision : le guide exige une seule personne dont les décisions sont respectées.
• Un Daily transformé en point de reporting vers un manager, au lieu d’un moment de replanification entre Developers.
• Une Sprint Review réduite à une démonstration, sans discussion sur la suite ni ajustement du backlog.
• Pas de Definition of Done, ou une définition qui change à chaque Sprint : impossible alors de dire ce qui est réellement terminé.
• Changer l’Objectif de Sprint en cours de route ou rallonger un Sprint pour finir le travail.
• Sauter la rétrospective, seul événement consacré à l’amélioration de l’équipe.
• Une « équipe dans l’équipe » (Product Owner d’un côté, développeurs de l’autre), que la version 2020 du guide a justement voulu supprimer.

Scrum, Kanban, XP, cycle en V : quelles différences ?

Scrum n’est pas la seule approche agile. Le choix dépend du type de travail et du niveau de structure souhaité.

Selon le Kanban Guide, Kanban est « une stratégie pour optimiser le flux de valeur » qui repose sur trois pratiques : définir et visualiser le flux de travail, gérer activement les éléments en cours et améliorer le flux. Le Kanban Guide précise que Kanban « peut et doit » servir à compléter d’autres approches : une équipe Scrum peut par exemple limiter le travail en cours sur son scrum board. Pour aller plus loin : la méthode Kanban et notre panorama des méthodes de gestion de projet web.

Quels outils pour gérer un projet Scrum ?

Scrum ne prescrit aucun outil : un tableau blanc et des post-it suffisent pour démarrer. Dès que l’équipe travaille à distance ou que le backlog grossit, un logiciel devient utile. Les fonctions à vérifier pour un usage Scrum :

• gestion du Product Backlog (ordre, estimation, affinement) ;
• création de Sprints de durée fixe et d’un Sprint Backlog ;
• scrum board avec colonnes personnalisables et limites de travail en cours ;
• graphiques de suivi (burndown, burn-up, vélocité) ;
• champ ou modèle pour la Definition of Done et l’Objectif de Sprint ;
• intégrations avec les outils de l’équipe (messagerie, dépôt de code, documentation).

Pour comparer les solutions, consultez notre comparatif des logiciels de gestion de projet agile, ainsi que nos sélections de logiciels Kanban et de logiciels de gestion de projet gratuits.

Formation, certification et ressources pour aller plus loin

Plusieurs organismes délivrent des certifications Scrum. Ken Schwaber a fondé la Scrum Alliance, puis Scrum.org ; la Scrum Alliance propose par exemple la certification Certified ScrumMaster (CSM). Notre sélection des formations pour devenir Scrum Master compare les parcours disponibles en France.

Ressources de référence, gratuites :

• Le Scrum Guide 2020 en français (PDF officiel) et sa version en ligne en anglais.
• Le Manifeste agile et ses 12 principes.
• The Scrum Primer, introduction disponible en plusieurs langues.
• L’article fondateur de Takeuchi et Nonaka, « The New New Product Development Game » (Harvard Business Review).

FAQ sur la méthode Scrum

Quels sont les 3 piliers de Scrum ?

La transparence, l’inspection et l’adaptation. Ils découlent de l’empirisme, sur lequel Scrum est fondé : on rend le travail visible, on l’examine régulièrement lors des événements et on ajuste dès qu’un écart apparaît.

Quelles sont les 5 valeurs Scrum ?

L’engagement, le focus, l’ouverture, le respect et le courage. Le Scrum Guide fait dépendre la réussite de Scrum de la capacité de l’équipe à vivre ces valeurs au quotidien.

Quels sont les 5 événements de Scrum ?

Le Sprint, qui contient les quatre autres : le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective. Le guide parle d’« événements », mais on entend souvent « cérémonies » ou « rituels ».

Quelle est la différence entre agile et Scrum ?

L’agilité est un ensemble de 4 valeurs et 12 principes définis par le Manifeste agile en 2001. Scrum est un cadre de travail précis qui permet de les appliquer. Scrum est agile, mais l’agilité ne se limite pas à Scrum : Kanban et XP en sont d’autres déclinaisons.

Quels sont les 4 valeurs et les 12 principes du Manifeste agile ?

Le Manifeste valorise les individus et leurs interactions plus que les processus et les outils, des logiciels opérationnels plus qu’une documentation exhaustive, la collaboration avec les clients plus que la négociation contractuelle, et l’adaptation au changement plus que le suivi d’un plan. Les 12 principes qui l’accompagnent sont publiés sur agilemanifesto.org.

Comment dit-on « scrum » en français ?

« Scrum » se traduit par mêlée, au sens du rugby. C’est pourquoi le Daily Scrum est appelé « mêlée quotidienne » dans l’ancienne traduction française du guide (version 2017). La traduction officielle du Scrum Guide conserve toutefois les termes anglais (Scrum, Sprint, Product Owner, Daily Scrum…).

Combien de personnes dans une équipe Scrum et combien de temps dure un sprint ?

Le guide indique une équipe de 10 personnes au plus en général, Product Owner et Scrum Master compris. Un Sprint dure un mois au maximum, avec une durée fixe pour créer une cohérence d’un Sprint à l’autre.

Scrum fonctionne-t-il hors informatique ou à distance ?

Oui pour le hors informatique : le guide constate son adoption dans de nombreux domaines au-delà du logiciel, et la version 2020 a retiré les références au monde informatique. Le travail à distance n’est pas traité par le guide, qui recommande des événements à heure et lieu fixes ; une équipe distribuée transpose cette règle avec un horaire et un espace en ligne stables, et un outil partagé pour le backlog.

Le Scrum Master est-il un chef de projet ?

Non. Le Scrum Master est responsable de l’efficacité de l’équipe et de la bonne application de Scrum. Il ne décide ni du contenu (rôle du Product Owner) ni de la façon de travailler (rôle des Developers). Pour comparer avec le métier de chef de projet, consultez notre fiche dédiée.