Scrum ou Kanban : les différences, et lequel convient à une petite équipe

Par Andrei Finogeev, fondateur de Weft ·

Scrum planifie le travail en sprints fixes d’un mois au plus, avec trois responsabilités (Product Owner, Scrum Master, Developers) et quatre événements dans chaque sprint. Kanban n’a ni sprints ni rôles imposés : le travail circule en continu sur un tableau, et l’équipe limite explicitement la quantité de travail en cours. Choisissez Scrum quand une équipe de plusieurs personnes a besoin d’un rythme de livraison fixe et d’un objectif stable par cycle ; choisissez Kanban quand le travail arrive de façon imprévisible et que les priorités changent chaque jour. Le Scrumban se situe entre les deux : le flux du Kanban, avec des sprints seulement là où ils aident.

Scrum, Kanban, Scrumban : le mémo

Scrum tel que défini par le Guide Scrum 2020, Kanban tel que défini par le Guide Kanban (v2025.5). Le Scrumban n’a pas de guide officiel ; la colonne décrit la façon dont il est généralement pratiqué.

ScrumKanbanScrumban
CadenceSprints fixes d’un mois au plus, enchaînésFlux continu, sans itérationsFlux continu ; sprints facultatifs, en général d’une ou deux semaines
RôlesProduct Owner, Scrum Master, DevelopersAucun imposéAucun imposé ; souvent, une personne porte les priorités
RéunionsSprint Planning, Daily Scrum (15 min), Sprint Review, Sprint RetrospectiveAucune imposéeSeulement ce que l’équipe juge utile, en général une planification et une revue
Ce qui limite le travailCe sur quoi l’équipe s’engage pour le sprintUne limite explicite du travail en coursUne limite du travail en cours, plus l’objectif de sprint s’il y en a un
Changer le périmètre en cours de cycleL’objectif de sprint reste fixe ; le Sprint Backlog peut être affinéÀ tout moment : l’élément suivant est tiré dès qu’il y a de la placeÀ tout moment ; l’objectif de sprint est une cible, pas un verrou
Mesures principalesProgression vers l’objectif de sprint et l’objectif de produitTravail en cours, débit, âge des éléments, temps de cycleEn général les mesures de flux du Kanban
TableauFacultatif ; remis à zéro à chaque sprintLe cœur de la méthode ; permanentPermanent ; un sprint en est une tranche
Idéal pourLes équipes produit d’une dizaine de personnes au plus qui avancent vers un objectifLe support, l’exploitation et tous ceux dont le travail arrive sans être planifiéLes petites équipes et les fondateurs solo qui veulent du flux et un objectif à court terme

Ce qu’est Scrum

Scrum a été présenté pour la première fois par Ken Schwaber et Jeff Sutherland à la conférence OOPSLA en 1995 ; les règles actuelles sont celles du Guide Scrum 2020. Une Scrum Team compte en général dix personnes ou moins et travaille en sprints : des événements de durée fixe d’un mois au plus, qui commencent dès la fin du précédent.

Chaque sprint comporte quatre événements. Le Sprint Planning (huit heures au plus pour un sprint d’un mois) fixe l’objectif de sprint et choisit le travail. Le Daily Scrum est un point de 15 minutes pour les Developers. La Sprint Review (quatre heures au plus) présente le résultat aux parties prenantes, et la Sprint Retrospective (trois heures au plus) examine la façon dont l’équipe a travaillé.

Scrum a trois artefacts, chacun avec un engagement : le Product Backlog (l’objectif de produit), le Sprint Backlog (l’objectif de sprint) et l’Incrément (la Definition of Done).

Ce qu’est Kanban

Le Guide Kanban définit Kanban comme « une stratégie pour optimiser le flux de valeur à travers un processus ». Il vient du système de cartes que Toyota utilisait pour signaler quand produire davantage, et a été adapté au travail intellectuel dans les années 2000.

Il repose sur trois pratiques : définir et visualiser le workflow, gérer activement les éléments qui s’y trouvent, et l’améliorer. La seule règle stricte : les personnes du système contrôlent explicitement combien d’éléments sont en cours entre le début et la fin — c’est la limite du travail en cours (WIP, work in progress).

Kanban n’impose ni rôles, ni sprints, ni réunions. Il suit quatre mesures de flux : le travail en cours, le débit, l’âge des éléments et le temps de cycle.

Avantages et inconvénients

Scrum

  • Un rythme fixe : tout le monde sait quand le prochain résultat est attendu
  • Un objectif clair par sprint empêche l’équipe de dériver
  • Des moments prévus pour inspecter le produit et le processus
  • Quatre événements par sprint coûtent un vrai temps à une équipe de deux ou trois personnes
  • Le travail urgent attend le sprint suivant ou casse le plan
  • Il faut quelqu’un pour chaque responsabilité, ce qu’un fondateur seul ne peut pas répartir

Kanban

  • Démarre sur le tableau que vous avez déjà ; rien à mettre en place sauf une limite WIP
  • Du nouveau travail peut être tiré à tout moment
  • Les mesures de flux montrent où le travail se bloque
  • Pas d’échéance ni d’objectif intégrés, donc le travail au long cours peut dériver
  • Sans limite WIP, ce n’est qu’une liste de tâches en colonnes
  • La planification à l’avance est entièrement laissée à l’équipe

Lequel choisir

Une équipe produit de cinq à dix personnes avec une feuille de route stable
Scrum. Les événements sont rentables quand plusieurs personnes doivent s’accorder sur un objectif toutes les deux ou trois semaines.
Le support, l’exploitation, ou une équipe qui vit des demandes entrantes
Kanban. Le travail arrive quand il arrive ; une limite WIP et une colonne Done claire comptent plus qu’un plan de sprint.
Un fondateur solo ou une équipe de deux à cinq personnes
Scrumban. Gardez un tableau continu avec une limite WIP, et utilisez un sprint d’une ou deux semaines comme objectif à court terme, sans l’ensemble des événements Scrum.

Le Scrumban : le juste milieu

Corey Ladas a décrit le Scrumban comme un moyen pour les équipes Scrum d’évoluer vers un flux tiré. En pratique, c’est un tableau Kanban avec des limites WIP qui n’est jamais remis à zéro, plus des sprints servant de time-boxes facultatives qui regroupent une partie du travail. Notre guide complet détaille les règles et la mise en place du tableau : Qu’est-ce que le Scrumban ?

Quand des agents IA font une partie du travail

Si ChatGPT, Claude, Cursor ou Codex prennent des tâches pour vous, les événements Scrum n’ont plus personne pour y assister : un agent ne vient pas au stand-up. Ce qui compte encore, c’est ce qu’apporte le Kanban : un tableau qui montre ce qui est en cours, une limite WIP pour ne pas lancer dix tâches à la fois, et une règle claire pour savoir quand une carte est terminée.

Le goulot d’étranglement se déplace aussi. Les agents finissent vite, et l’étape lente devient votre revue de ce qu’ils ont fait. Limiter la quantité de travail terminé qui peut vous attendre, c’est une limite WIP sur la colonne humaine.

Weft est un tableau Scrumban conçu pour cela : des colonnes, des sprints facultatifs, une limite sur la quantité de travail terminé qui peut attendre votre revue, et une IA qui prend une tâche avant de commencer, rend compte de l’avancement et s’arrête pour vous demander quand vous seul pouvez décider.

Questions

Scrum et Kanban, c’est la même chose ?

Non. Ce sont deux approches agiles et toutes deux utilisent souvent un tableau, mais Scrum planifie le travail en sprints fixes avec des rôles et des événements définis, alors que Kanban fonctionne en flux continu, sans rôles imposés et avec une limite explicite du travail en cours.

Fait-on des sprints en Kanban ?

Pas en Kanban à proprement parler : le Guide Kanban n’impose aucune itération. Les équipes qui ajoutent des sprints à un tableau Kanban font en général du Scrumban.

Comment fonctionne un sprint Scrum ?

Un sprint est une période fixe d’un mois au plus. Il commence par le Sprint Planning, qui fixe l’objectif de sprint ; les Developers se réunissent pour un Daily Scrum de 15 minutes ; il se termine par une Sprint Review du résultat et une Sprint Retrospective sur le processus, et le sprint suivant commence aussitôt.

Qui a inventé le Scrumban ?

Le terme est attribué à Corey Ladas, qui a décrit le Scrumban dans des essais et un livre de 2009 comme un moyen pour les équipes Scrum d’évoluer vers un flux tiré à la manière du Kanban.

Scrum, est-ce la même chose qu’Agile ?

Non. Agile désigne les valeurs et principes du Manifeste Agile de 2001 ; Scrum et Kanban sont deux façons concrètes de travailler qui les suivent.

Un développeur solo peut-il utiliser Scrum ?

Pas tel qu’il est écrit : Scrum suppose une équipe avec trois responsabilités distinctes. Un développeur solo garde en général ce qui l’aide, un backlog et un court objectif de sprint, et gère le tableau en Kanban — ce qui est du Scrumban.

Sources

Consulté le 11 novembre 2026.