Sprint, daily, backlog, Scrum Master : ces mots circulent dans toutes les équipes projet, souvent sans que personne ne sache d’où ils viennent. On vous a peut-être présenté Scrum comme une méthode avec des réunions en plus. C’est l’idée fausse la plus répandue. Le texte officiel qui définit Scrum, le Guide Scrum, tient en moins de 13 pages, et il décrit un cadre volontairement incomplet, avec peu de règles, mais des règles qui ne se négocient pas.
Dans ce guide, nous repartons de la version officielle de novembre 2020 pour tout expliquer simplement : ce qu’est Scrum et pourquoi il fonctionne, les 3 responsabilités de l’équipe, le Sprint et ses 4 événements, les 3 artefacts et leurs engagements. Nous déroulons ensuite un sprint complet, jour par jour, avant de voir dans quels cas Scrum est un mauvais choix.
Vous préférez la vidéo ? Tout ce guide est expliqué en 16 minutes, schémas à l’appui.
Qu’est-ce que la méthode Scrum ?
Le Guide Scrum, écrit par ses 2 créateurs, Ken Schwaber et Jeff Sutherland, en donne une définition très courte : « 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. » Deux mots comptent plus que les autres dans cette phrase : léger, et complexe.
Un cadre, pas une méthode
Léger, parce que le guide ne dit ni comment rédiger une tâche, ni quel outil utiliser, ni comment estimer. Il définit une équipe, 5 événements et 3 artefacts, c’est-à-dire 3 supports de travail partagés. Le reste, c’est à l’équipe de le trouver. Toute la différence entre une méthode et un cadre est là : une méthode vous dit quoi faire à chaque étape, un cadre vous donne une structure et vous laisse remplir l’intérieur.
Complexe, parce que Scrum est fait pour les projets où l’on découvre la solution en avançant : un nouveau produit, un nouveau service, une refonte dont le besoin bouge. Pour une tâche que l’on sait déjà parfaitement réaliser, il n’apporte pas grand-chose. Scrum appartient à la famille des méthodes agiles, dont il est le cadre le plus connu.
D’où vient Scrum ?
Le nom vient du rugby : scrum veut dire mêlée. La métaphore est empruntée à un article de la Harvard Business Review publié en 1986 par deux chercheurs japonais, Hirotaka Takeuchi et Ikujiro Nonaka. Ils y comparaient les meilleures équipes produit à une équipe de rugby qui avance ensemble, plutôt qu’à une course de relais où chacun attend son tour.
| Année | Étape |
|---|---|
| 1986 | Article de Takeuchi et Nonaka dans la Harvard Business Review, origine de la métaphore |
| 1995 | Première présentation de Scrum par Ken Schwaber et Jeff Sutherland, à la conférence OOPSLA |
| 2010 | Première version du Guide Scrum |
| 2020 | Version en vigueur, plus courte et débarrassée des références à l’informatique |
La version de 2020 reste la référence officielle. Elle est gratuite et traduite en français : vous pouvez lire le Guide Scrum 2020 sur scrumguides.org. Voyons maintenant ce qui fait fonctionner ce cadre.
Pourquoi Scrum fonctionne : l’empirisme
Scrum part d’un constat simple : sur un projet complexe, un plan détaillé fait au départ devient faux très vite. Plutôt que de tout prédire, Scrum s’appuie sur l’empirisme : la connaissance vient de l’expérience, et les décisions se prennent sur ce que l’on a réellement observé. Le guide ajoute la pensée Lean, qui réduit le gaspillage et se concentre sur l’essentiel.
Les 3 piliers : transparence, inspection, adaptation
L’empirisme repose sur 3 piliers qui s’enchaînent. La transparence d’abord : le travail et son avancement doivent être visibles, par ceux qui le font comme par ceux qui le reçoivent. L’inspection ensuite : on regarde souvent où l’on en est, pour repérer les écarts tôt. L’adaptation enfin : dès qu’un écart apparaît, on corrige, le plus vite possible.
Ces piliers ne fonctionnent qu’ensemble. Le guide le dit sans détour : une inspection sans transparence est trompeuse, et une inspection sans adaptation est infructueuse. Chaque événement de Scrum existe pour faire tourner cette boucle.
Les 5 valeurs Scrum
Pour que la boucle tienne, le guide demande à l’équipe de vivre 5 valeurs :
- l’engagement, envers les objectifs et envers les collègues ;
- le focus, sur le travail du sprint en cours ;
- l’ouverture, sur le travail et les difficultés rencontrées ;
- le respect, entre professionnels compétents et indépendants ;
- le courage, celui de faire ce qui est juste et de traiter les problèmes difficiles.
Le courage, par exemple, c’est oser dire en milieu de sprint que l’objectif ne sera pas atteint. Sans lui, la transparence reste une intention. Ces valeurs portent une équipe : voyons comment elle est organisée.
L’équipe Scrum : 3 responsabilités, pas de chef de projet
Une équipe Scrum compte habituellement 10 personnes au plus. Elle ne contient ni sous-équipe, ni hiérarchie. Elle est pluridisciplinaire, c’est-à-dire qu’elle réunit toutes les compétences nécessaires, et elle est autogérée : c’est elle qui décide qui fait quoi, quand et comment. Le guide y définit 3 responsabilités, et le mot est choisi avec soin : il s’agit de responsabilités, pas de postes.
| Responsabilité | Ce dont elle répond | Ce qu’elle ne fait pas |
|---|---|---|
| Product Owner | Maximiser la valeur du produit, formuler l’objectif de produit, tenir et ordonner le Product Backlog | Décider à la place des Developers de la façon de réaliser le travail |
| Developers | Construire le plan du sprint, respecter la définition de fini, ajuster le plan chaque jour | Se limiter au développement informatique : rédacteurs, designers, ingénieurs ou analystes en font partie |
| Scrum Master | La bonne application de Scrum et l’efficacité de l’équipe : former, faciliter, aider à lever les obstacles | Distribuer les tâches ou piloter l’équipe comme un manager |
Le Product Owner, une personne et pas un comité
Le Product Owner est le responsable du produit. Il formule l’objectif, il tient la liste de tout ce qu’il faudrait faire et, surtout, il en fixe l’ordre. Le guide insiste : le Product Owner est une personne, pas un comité. Celui qui veut changer les priorités doit le convaincre, lui. Pour que ce rôle fonctionne, toute l’organisation doit respecter ses décisions.
Les Developers et le Scrum Master
Les Developers sont tous ceux qui réalisent le travail. Le terme vient du monde du logiciel, mais le guide l’emploie pour simplifier, sans exclure personne. Le Scrum Master, lui, répond de la bonne application de Scrum et de l’efficacité de l’équipe. Le guide le décrit comme un leader au service de l’équipe : il forme, il facilite, il aide à lever les obstacles, mais il ne distribue pas les tâches.
Où est passé le chef de projet ?
Aucune de ces 3 responsabilités ne s’appelle chef de projet, et ce n’est pas un oubli. Le rôle classique du chef de projet est réparti : le quoi et le pourquoi vont au Product Owner, le comment va aux Developers, le cadre et l’amélioration continue vont au Scrum Master.
C’est souvent le point le plus difficile à accepter dans une organisation qui découvre Scrum. Nommer Scrum Master l’ancien chef de projet, en lui laissant ses habitudes de pilotage, revient à garder l’ancienne organisation sous un nouveau nom. Cette équipe travaille au rythme d’un cycle bien précis : le Sprint.
Le Sprint, la boucle de base de Scrum
Le Sprint est le cœur de Scrum. C’est un cycle de durée fixe, d’un mois au maximum, pendant lequel l’équipe transforme des idées en un résultat utilisable. Un nouveau sprint commence dès que le précédent se termine, sans pause entre les deux. Le guide résume l’idée en une phrase : chaque sprint peut être considéré comme un projet court.
Le guide ne fixe pas de durée exacte. Deux semaines est un choix courant, mais ce n’est pas une règle. Plus le sprint est court, plus vous apprenez vite, et moins une erreur coûte cher. Pendant le sprint, 4 règles tiennent l’ensemble :
- aucun changement ne doit mettre en danger l’objectif du sprint ;
- la qualité ne baisse jamais ;
- le Product Backlog s’affine au fil de l’eau ;
- le périmètre peut être clarifié, puis renégocié avec le Product Owner, à mesure que l’équipe en apprend davantage.
Si l’objectif du sprint devient obsolète, le sprint peut être annulé, et une seule personne en a le pouvoir : le Product Owner. À l’intérieur du sprint, 4 événements rythment le travail.
Les 4 événements du Sprint
Dans chaque sprint, 4 événements se succèdent toujours dans le même ordre. Chacun a une durée maximale, que le guide appelle une timebox, une boîte de temps. Les durées du tableau valent pour un sprint d’un mois : sur un sprint plus court, les événements sont généralement plus courts. Avec le sprint lui-même, qui les contient, ils forment les 5 événements de Scrum.
| Événement | Durée maximale (sprint d’un mois) | Objectif |
|---|---|---|
| Sprint Planning | 8 heures | Lancer le sprint : pourquoi, quoi et comment |
| Daily Scrum | 15 minutes, chaque jour ouvré | Inspecter la progression vers l’objectif du sprint et adapter le plan |
| Sprint Review | 4 heures | Inspecter le résultat avec les parties prenantes et décider de la suite |
| Sprint Retrospective | 3 heures | Améliorer la façon de travailler de l’équipe |
Le Sprint Planning : 3 questions
Le Sprint Planning lance le sprint et répond à 3 questions. Pourquoi ce sprint est-il important ? L’équipe en tire l’objectif du sprint, une phrase qui dit à quoi il va servir. Que peut-on faire pendant ce sprint ? Les Developers choisissent les éléments du Product Backlog avec le Product Owner. Comment le travail sera-t-il réalisé ? Les Developers découpent souvent chaque élément en tâches d’une journée ou moins.
Le Daily Scrum : 15 minutes, pas un reporting
Le Daily Scrum dure 15 minutes, chaque jour ouvré, à la même heure et au même endroit. Il réunit les Developers, qui inspectent leur progression vers l’objectif du sprint et adaptent le plan de la journée. Ce n’est pas un point de reporting au manager. Depuis 2020, le guide n’impose même plus les 3 questions traditionnelles, « qu’ai-je fait hier, que vais-je faire aujourd’hui, qu’est-ce qui me bloque » : l’équipe choisit la structure qui lui convient.
La Sprint Review : une séance de travail
La Sprint Review arrive en fin de sprint. L’équipe montre ce qu’elle a produit aux parties prenantes, et chacun discute de la suite. Le guide insiste : c’est une séance de travail, pas une simple démonstration. Ce qui s’y dit peut modifier le Product Backlog.
La Sprint Retrospective : améliorer la façon de travailler
La rétrospective clôt le sprint. Cette fois, l’équipe ne regarde pas le produit, mais sa façon de travailler : les personnes, les échanges, les processus, les outils et le niveau de qualité. Elle en tire une ou deux améliorations concrètes, qui peuvent entrer dès le sprint suivant. Ces événements s’appuient sur des supports partagés : les artefacts.
Les 3 artefacts Scrum et leurs engagements
Les artefacts sont les 3 supports partagés de Scrum. Ils rendent le travail visible, pour que tout le monde décide sur la même base. Depuis 2020, chacun est relié à un engagement, une cible qui donne du sens à son contenu.
| Artefact | Ce qu’il contient | Son engagement | Qui en répond |
|---|---|---|---|
| Product Backlog | La liste ordonnée de tout ce qui pourrait améliorer le produit | L’objectif de produit | Le Product Owner |
| Sprint Backlog | L’objectif du sprint, les éléments choisis et le plan d’action | L’objectif du sprint | Les Developers |
| Increment | Un morceau de produit utilisable, qui s’ajoute aux précédents | La Definition of Done | Toute l’équipe |
Le Product Backlog et l’objectif de produit
Le Product Backlog est la seule source de travail de l’équipe. Il n’est jamais terminé : il évolue au fil des découvertes. Son engagement, l’objectif de produit, décrit l’état futur que le produit doit atteindre. L’équipe le poursuit jusqu’à l’atteindre, ou jusqu’à l’abandonner, avant d’en viser un autre.
Le Sprint Backlog et l’objectif du sprint
Le Sprint Backlog est le plan du sprint en cours. Il réunit le pourquoi, avec l’objectif du sprint, le quoi, avec les éléments choisis, et le comment, avec le plan d’action. Il appartient aux Developers, qui le mettent à jour tous les jours.
L’Increment et la Definition of Done
L’Increment est le résultat concret du travail. Son engagement s’appelle la Definition of Done, la définition de fini : la liste des critères de qualité qu’un travail doit remplir pour être considéré comme terminé. À notre sens, c’est la règle la plus utile de Scrum. Un travail qui ne la remplit pas n’est pas un Increment : il ne peut être ni livré, ni même présenté en Sprint Review, et il retourne dans le Product Backlog. Fini à 90 %, cela n’existe pas.
Ces règles paraissent abstraites tant qu’on ne les voit pas fonctionner ensemble. Passons à un cas concret.
Un sprint de 2 semaines, du premier au dernier jour
Voici comment se déroule un sprint de 2 semaines sur un projet de refonte de site. L’exemple est générique, mais chaque étape suit le guide.
| Jour | Ce qui se passe |
|---|---|
| Jour 1 | Sprint Planning : le Product Owner explique que la priorité est la demande de devis en ligne. L’équipe en fait son objectif de sprint et sélectionne 3 éléments : le formulaire, l’e-mail de confirmation et la page de remerciement. |
| Jours 2 à 9 | Un Daily Scrum de 15 minutes chaque matin. |
| Jour 4 | L’envoi des e-mails bloque sur un problème technique. Le Scrum Master aide à lever l’obstacle avec le service informatique. |
| Jour 7 | L’équipe voit qu’elle ne finira pas tout. Elle renégocie le périmètre avec le Product Owner : la page de remerciement personnalisée attendra, l’objectif du sprint ne bouge pas. |
| Jour 10 | Sprint Review avec l’équipe commerciale, qui demande un champ « budget », ajouté au Product Backlog. Puis rétrospective : les tests ont commencé trop tard, l’équipe testera dès le deuxième jour au prochain sprint. |
Le lendemain, le sprint suivant commence avec un nouveau Sprint Planning, et le produit s’améliore à chaque tour. Pour suivre un sprint comme celui-ci, un tableau en colonnes suffit : notre modèle gratuit de Scrum board reprend cette organisation.
Une autre présentation des notions de Scrum, en vidéo :
Quand Scrum n’est pas le bon choix
Scrum ne convient pas à tous les projets, et le reconnaître fait partie du métier. Trois situations s’y prêtent mal.
Un flux continu de demandes. Une équipe de support, une maintenance faite de petits tickets imprévus ou une production répétitive gagnent peu à découper leur travail en sprints. Une approche Kanban, qui gère un flux continu sans cycles fixes, convient souvent mieux : notre comparatif Kanban ou Scrum détaille les critères de choix.
Un projet entièrement connu d’avance. Si le périmètre est fixé par contrat et que les inconnues sont rares, une approche prédictive, comme le cycle en V, reste légitime. Scrum demande de l’énergie pour inspecter et adapter : sur un projet sans inconnue, cette énergie ne rapporte rien.
Une organisation qui ne délègue pas. Si le Product Owner n’a aucun pouvoir de décision, ou si un manager continue d’assigner les tâches, les règles de Scrum ne tiennent plus.
Reste un piège plus sournois : le Scrum à la carte. On garde le daily et les sprints, mais on supprime la rétrospective ou la définition de fini. Le guide le dit dans sa conclusion : on peut appliquer seulement certaines parties de Scrum, mais le résultat ne sera pas du Scrum.
En bref : la méthode Scrum en 5 points
Scrum est-il fait pour votre projet ? Si le besoin se précise en avançant et que vous pouvez livrer quelque chose d’utilisable toutes les 2 à 4 semaines, oui. Si le travail est répétitif, ou entièrement connu d’avance, non.
- Scrum est un cadre de travail léger, pas une méthode détaillée.
- L’équipe compte 3 responsabilités : Product Owner, Developers et Scrum Master, sans chef de projet.
- Le Sprint dure un mois au maximum et contient 4 événements.
- Chaque artefact a son engagement : objectif de produit, objectif du sprint, Definition of Done.
- Un travail qui ne respecte pas la définition de fini n’est pas terminé.
Si vous démarrez, faites 2 choses avant même le premier sprint : écrivez l’objectif de produit en une phrase, puis faites valider une définition de fini par toute l’équipe. Ce sont ces 2 engagements qui donnent un sens à tout le reste.
