Méthode Scrum : définition, rôles, événements et exemple de sprint

Introduction

Scrum aide les équipes produit, logiciel, marketing ou opérationnelles à avancer par cycles courts, à inspecter régulièrement leur travail et à adapter leurs priorités dans une démarche de gestion de projet. Ce guide explique ce qu’est Scrum et comment le distinguer d’Agile et de Kanban, puis détaille ses responsabilités, ses artefacts et ses événements. Il propose enfin un exemple de premier sprint et les erreurs fréquentes à éviter.

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

Scrum n’est pas une simple méthode de gestion de projet : c’est un framework léger, défini par le Scrum Guide 2020 de Ken Schwaber et Jeff Sutherland comme un cadre qui aide les personnes, les équipes et les entreprises à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. Le guide précise aussi que Scrum est volontairement incomplet : il ne décrit que les éléments nécessaires pour faire fonctionner l’empirisme (approche pragmatique de gestion de projet qui consiste à prendre des décisions sur la base d’observations factuelles et de faits mesurables), sans imposer toutes les pratiques de travail. Concrètement, Scrum organise le travail autour de cinq événements, de trois artefacts et de trois responsabilités : product owner, Scrum Master et développeurs. Cette structure minimale permet de créer un langage commun, tout en laissant chaque équipe choisir ses pratiques complémentaires : estimation, documentation, outils de suivi ou règles de collaboration. Selon le « 17th State of Agile Report de Digital.ai », 63 % des équipes agiles utilisent Scrum comme framework d’équipe.

Le mot scrum vient du rugby et signifie « mêlée ». Hirotaka Takeuchi et Ikujiro Nonaka l’emploient en 1986 dans « The New New Product Development Game », publié dans la « Harvard Business Review », pour décrire des équipes capables d’avancer collectivement dans l’incertitude. Ken Schwaber et Jeff Sutherland présentent ensuite Scrum en 1995 à la conférence OOPSLA. Le « Scrum Guide Expansion Pack », publié en juin 2025, complète le guide 2020 sans le remplacer.

Scrum, Agile ou Kanban : quelle différence ?

Agile désigne un ensemble de valeurs et de principes formalisés par le Manifeste Agile en 2001. Scrum est l’un des frameworks qui permettent de mettre ces principes en pratique avec des responsabilités, des événements et des artefacts définis. Pour approfondir ces notions, consultez notre article sur la méthode Agile et notre guide de la méthode Kanban.

Quels sont les 3 piliers et les 5 valeurs de Scrum ?

Scrum repose sur l’empirisme : l’équipe prend ses décisions à partir de ce qu’elle observe réellement. Ses trois piliers sont :

• Transparence : le travail, les objectifs et les problèmes doivent être visibles et compris.
• Inspection : l’équipe examine régulièrement le produit, le processus et les écarts.
• Adaptation : lorsque l’inspection révèle un écart, l’équipe ajuste rapidement son plan.

Ces piliers fonctionnent avec cinq valeurs : engagement, focus, ouverture, respect et courage. Sans elles, les événements deviennent mécaniques et Scrum se réduit à une suite de réunions.

Product owner, Scrum Master, développeurs : les 3 responsabilités de la Scrum team

Le « Scrum Guide 2020 » parle de responsabilités plutôt que de rôles. La Scrum team est une seule équipe, sans sous-équipe ni hiérarchie interne, généralement composée de dix personnes ou moins.

Les 3 artefacts Scrum et leurs engagements

Les artefacts Scrum rendent le travail visible. Chaque artefact est lié à un engagement qui permet de mesurer la progression et d’aligner la Scrum team. Sans ces engagements, les listes de tâches deviennent faciles à remplir mais difficiles à interpréter : l’équipe peut produire beaucoup d’activités sans savoir si elle se rapproche vraiment de l’objectif.

Comment se déroule un sprint ? Les 5 événements Scrum et leur durée

Product backlog → sprint planning → sprint avec Daily Scrum → sprint review → rétrospective → sprint suivant

Les événements Scrum, parfois appelés cérémonies, créent une régularité et servent à inspecter et à adapter les artefacts. Comme le rappelle le « Scrum Guide », ne pas organiser un événement revient à perdre une occasion « d’inspecter et de s’adapter ». Leur objectif n’est pas d’ajouter des réunions, mais de remplacer les échanges dispersés par des moments courts, utiles et orientés vers la décision.

Lorsque les sprints sont plus courts, la durée des événements l’est généralement aussi. Pour un sprint de deux semaines, diviser ces durées par deux est un repère fréquent, mais pas une règle officielle.

Exemple concret : votre premier sprint de 2 semaines

Imaginons une Scrum Team de sept personnes : un product owner, un Scrum Master et cinq développeurs. L’équipe peut être logicielle, produit ou marketing ; Scrum n’est pas réservé au développement informatique. Son objectif de sprint est le suivant : « permettre aux prospects de réserver une démo depuis la page Tarifs ».

Exemple de définition de terminé :

• contenu relu par un pair ;
• parcours testé sur ordinateur et mobile ;
• documentation mise à jour ;
• validation du product owner.

Lors de la sprint review, l’équipe commerciale teste le parcours et constate que le formulaire demande trop d’informations : le product owner place « réduire le formulaire à trois champs » en haut du product backlog. Lors de la rétrospective, l’équipe observe que le blocage sur l’agenda a coûté deux jours et décide d’identifier les dépendances externes dès le prochain sprint planning.

Pour une équipe distribuée, le Daily peut aussi être préparé dans un canal de collaboration réservé à l’équipe, sans remplacer l’échange en direct lorsqu’un obstacle exige une discussion. Voici un modèle court, centré sur l’objectif de sprint plutôt que sur un compte rendu individuel :

• Avancement vers l’objectif : formulaire de réservation terminé et relu.
• Prochaine étape : connecter le formulaire à l’agenda commercial.
• Obstacle éventuel : accès à l’agenda en attente de validation.

5 erreurs fréquentes qui font échouer Scrum

Scrum échoue rarement à cause de ses événements eux-mêmes. Les difficultés viennent plutôt d’un usage superficiel : on garde les réunions et les intitulés, mais sans transparence réelle, sans adaptation ou sans autonomie de l’équipe.

Questions fréquentes