Qu'est-ce que Scrum ?
Scrum est un framework agile de gestion de projet dans lequel une équipe livre un produit par itérations courtes appelées sprints, généralement de deux semaines. À la fin de chaque sprint, l'équipe produit un incrément utilisable. Scrum repose sur trois rôles, quatre événements et trois artefacts, mais laisse l'équipe libre de ses choix techniques.
Le mot vient du rugby, où le « scrum » désigne la mêlée : un groupe soudé qui avance ensemble vers un but. C'est l'image que la méthode revendique. Plutôt que de tout planifier au départ et de livrer à la fin, Scrum découpe le projet en petits cycles et fait avancer une équipe pluridisciplinaire sprint après sprint, en s'ajustant à chaque fois.
Il faut retenir un point de vocabulaire : Scrum n'est pas une méthode figée mais un framework, c'est-à-dire un cadre léger. Il dit qui fait quoi et à quel rythme, mais pas comment coder, tester ou concevoir. C'est ce qui explique son succès : il s'adapte à des contextes très différents. Scrum est aujourd'hui le cadre agile le plus répandu dans le développement logiciel, et il est l'une des déclinaisons concrètes de la méthode agile.
Les trois rôles de Scrum
Scrum définit trois rôles : le product owner, qui porte la vision du produit et priorise le travail ; le scrum master, qui fait vivre la méthode et lève les obstacles ; et l'équipe de développement, qui conçoit et construit l'incrément. Ensemble, ces trois rôles forment l'équipe Scrum, sans hiérarchie interne.
Une nuance importante : dans Scrum, personne ne « commande » au sens classique. Il n'y a pas de chef de projet qui distribue les tâches. La responsabilité est répartie entre trois rôles complémentaires.
Le product owner
Le product owner (propriétaire du produit) est le porteur de la valeur. C'est lui qui sait ce que le produit doit accomplir et pour qui. Il alimente et priorise le product backlog, tranche les arbitrages et décide de ce qui compte le plus. Il représente les intérêts des utilisateurs et de l'entreprise. S'il fait ce travail à moitié, l'équipe construit vite, mais pas forcément la bonne chose.
Le scrum master
Le scrum master est le gardien de la méthode et le facilitateur de l'équipe. Il organise les événements, aide l'équipe à mieux travailler ensemble et surtout lève les obstacles qui la ralentissent, qu'il s'agisse d'un accès manquant, d'une décision qui traîne ou d'interruptions extérieures. Il ne dirige pas : il sert l'équipe et la protège pour qu'elle reste concentrée sur son sprint.
L'équipe de développement
L'équipe de développement regroupe les personnes qui construisent le produit : développeurs, mais aussi designers, testeurs ou tout profil nécessaire. Elle est pluridisciplinaire et auto-organisée : elle décide elle-même comment atteindre l'objectif du sprint. Petite par nature, généralement de trois à neuf personnes, elle est responsable collectivement de la qualité de l'incrément livré.
Les événements Scrum
Scrum s'articule autour de quatre événements cadencés : le sprint, qui contient tous les autres ; la mêlée quotidienne, un point court chaque jour ; la revue de sprint, où l'équipe présente l'incrément ; et la rétrospective, où elle améliore sa façon de travailler. Ces rituels donnent au projet son rythme régulier.
Ces événements ne sont pas de la bureaucratie. Chacun répond à une question précise : que fait-on ce sprint, où en est-on aujourd'hui, qu'a-t-on produit, comment progresser.
- Le sprint : l'itération elle-même, d'une à quatre semaines, à durée fixe. Il commence par une planification, la sprint planning, où l'équipe choisit ce qu'elle s'engage à livrer et se donne un objectif de sprint clair.
- La mêlée quotidienne (daily) : un point de quinze minutes, chaque jour, debout de préférence. L'équipe s'y synchronise : ce qui avance, ce qui bloque, ce qui est prévu ensuite. Ce n'est pas un rapport au chef, c'est une coordination entre pairs.
- La revue de sprint : à la fin du sprint, l'équipe montre l'incrément aux parties prenantes et recueille leurs retours. C'est le moment de la confrontation au réel, où l'on ajuste la suite en fonction de ce qui a été vu.
- La rétrospective : juste après la revue, l'équipe examine sa propre façon de travailler et décide d'une ou deux améliorations concrètes pour le sprint suivant. C'est le moteur d'amélioration continue de Scrum, et le rituel que l'on sacrifie le plus souvent à tort.
Les artefacts de Scrum
Scrum s'appuie sur trois artefacts, c'est-à-dire trois documents ou livrables qui rendent le travail visible : le product backlog, la liste priorisée de tout ce qui reste à faire ; le sprint backlog, ce que l'équipe s'engage à faire pendant le sprint en cours ; et l'incrément, la version fonctionnelle du produit livrée à la fin du sprint.
Un artefact, dans Scrum, sert à donner de la transparence. Il permet à tout le monde de voir où en est le travail et ce qui reste à accomplir, sans avoir à demander.
| Artefact | Ce qu'il contient | Qui en est responsable |
|---|---|---|
| Product backlog | La liste priorisée de tout ce que le produit devra faire, qui évolue en continu. | Le product owner |
| Sprint backlog | La part du backlog que l'équipe s'engage à traiter durant le sprint en cours. | L'équipe de développement |
| Incrément | La version du produit, réellement utilisable, livrée à la fin du sprint. | L'équipe de développement |
Le product backlog n'est jamais figé : il s'affine à mesure que l'on apprend. Le sprint backlog se remplit au moment de la planification. L'incrément, lui, doit répondre à une exigence claire, la « définition de terminé » (definition of done), qui fixe ce que signifie vraiment « fini » pour éviter le faux achèvement.
Comment se déroule un sprint, de bout en bout
Un sprint se déroule en quatre temps : la planification, où l'équipe choisit ce qu'elle va livrer ; le développement quotidien, rythmé par la mêlée ; la revue, où elle présente l'incrément ; et la rétrospective, où elle améliore sa méthode. Le sprint suivant repart aussitôt, sur ce qui a été appris.
Concrètement, voici le fil d'un sprint de deux semaines tel que je le vois tourner sur le terrain.
- Planification. L'équipe et le product owner examinent le haut du product backlog, choisissent ce qui entre dans le sprint et formulent un objectif de sprint. Ce qui est retenu devient le sprint backlog.
- Exécution. Pendant deux semaines, l'équipe construit. Chaque matin, la mêlée quotidienne synchronise tout le monde et fait remonter les blocages. Le scrum master s'occupe de les lever.
- Revue. En fin de sprint, l'équipe présente l'incrément aux parties prenantes. Les retours nourrissent la suite du backlog. C'est ici que se joue l'adaptation.
- Rétrospective. L'équipe fait le point sur sa manière de travailler et choisit une amélioration à tester au sprint suivant.
Au fil des sprints, l'équipe mesure sa vélocité, c'est-à-dire la quantité de travail qu'elle achève en moyenne par sprint. Cette donnée l'aide à s'engager sur un volume réaliste, sans se surcharger. C'est un repère interne de planification, pas une note de performance à comparer entre équipes.
Scrum, Kanban ou autre : lequel choisir ?
Scrum convient quand le travail se planifie par lots et se livre par itérations, comme le développement d'un produit. Kanban convient mieux au flux continu, quand les demandes arrivent en permanence, comme la maintenance ou le support. Le choix dépend de la nature du travail, pas d'une préférence de principe, et beaucoup d'équipes combinent les deux.
Kanban est l'autre grand cadre agile. Là où Scrum cadence le travail en sprints avec des rôles définis, Kanban se concentre sur la visualisation du flux et la limitation du travail en cours, sans itérations imposées. Ni l'un ni l'autre n'est « meilleur » : ils répondent à des rythmes de travail différents. Un projet neuf avec une feuille de route se prête bien à Scrum ; une équipe qui absorbe un flot continu de tickets se sentira à l'étroit dans des sprints et sera plus à l'aise en Kanban. Le vrai sujet n'est pas le cadre, mais l'intention agile qui le sous-tend, comme je l'explique dans ma comparaison entre agile et cycle en V.
Scrum et ses limites en pratique
Scrum donne d'excellents résultats quand l'équipe a un vrai product owner disponible, une direction qui accepte l'incertitude et la discipline de tenir ses rituels. Il échoue quand on l'applique comme un rituel vide : des sprints sans objectif clair, un backlog mal tenu ou une rétrospective sacrifiée transforment le cadre en théâtre.
Ce que j'observe le plus souvent, c'est un Scrum « de façade ». On garde les rituels et le vocabulaire, mais on a perdu l'intention. Quelques symptômes reviennent sans cesse :
- Un product owner absent ou sans pouvoir de décision, qui ne peut pas prioriser vraiment. L'équipe avance à vide.
- Des sprints qu'on rallonge pour « finir », ce qui casse le rythme et la mesure de la vélocité.
- Une rétrospective expédiée ou supprimée, donc aucune amélioration réelle d'un sprint à l'autre.
- Une direction qui exige un planning figé à douze mois tout en réclamant de l'agilité. Les deux ne tiennent pas ensemble.
Scrum n'est pas une baguette magique, et surtout pas une religion. C'est un cadre qui rend service quand on comprend pourquoi chaque pièce existe. Sur mes projets, je pilote en Scrum quand le contexte s'y prête, en gardant ce qui a du sens et en assumant d'adapter le reste. La vraie compétence n'est pas de réciter le cadre, mais de savoir quand s'en écarter.
Comment je pilote une équipe en Scrum, sans en faire une religion.
J'ai vu trop d'équipes appliquer Scrum à la lettre en oubliant le but. Je fais l'inverse : je garde ce qui fait avancer, le rythme court, la transparence du backlog, l'amélioration à chaque sprint, et j'allège ce qui devient un rituel creux. Ancien développeur, je comprends la réalité de l'équipe ; pilote de projet, je parle le langage de la direction. C'est ce pont qui évite le Scrum de façade et fait que les sprints produisent vraiment de la valeur.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des projets et des refontes en agile pour des grands comptes et des PME (TF1, SFR, Orange, SNCF), en faisant le lien entre les équipes techniques et la direction. Découvrir son approche.
À lire ensuite
La gestion de projet digital
Le guide de référence : méthodes, rôles, pilotage et réussite d'un projet.
MéthodeLa méthode agile expliquée
L'état d'esprit et les valeurs dont Scrum est l'une des déclinaisons.
ComparatifAgile ou cycle en V
Deux approches opposées de la gestion de projet, et comment trancher.
GlossaireMOA, MOE, AMOA
Qui fait quoi dans un projet digital, et comment ces rôles se répartissent.