Mon article en bref
Le Scrumban est une méthode hybride qui conserve les rôles et les rituels de Scrum tout en adoptant les mécanismes de flux de Kanban : tableau visuel, limites de travail en cours et planification déclenchée par le besoin plutôt que par le calendrier.
Voici les points essentiels à retenir :
- Définition : la structure d’équipe de Scrum + le pilotage par le flux de Kanban.
- Mécanisme central : la limite WIP, qui plafonne le nombre de tâches simultanées par colonne.
- Planification : à la demande, quand le tableau se vide, et non tous les quinze jours.
- Statut : ce n’est pas un framework officiel — aucun guide de référence, aucune définition normative.
- Pour qui : les équipes que le sprint contraint sans bénéfice, ou celles dont la charge est imprévisible (run, support, maintenance).
- Le risque : servir de prétexte à abandonner ce qui gênait dans Scrum sans rien adopter de Kanban.
Le Scrumban est une méthode de gestion de projet agile qui combine l’ossature de Scrum — une équipe stable, des rôles définis, des rituels réguliers — avec les mécanismes de pilotage du flux issus de Kanban : un tableau visuel, des limites de travail en cours et un réapprovisionnement déclenché par la consommation plutôt que par un calendrier.
Cet article ne revient pas sur ce qui distingue Scrum de Kanban : ce comparatif est traité en détail dans l’article Scrum et Kanban : quelles différences. On s’intéresse ici au Scrumban pour lui-même : ce qu’il change concrètement dans le quotidien d’une équipe, et les situations où il constitue un vrai progrès plutôt qu’un renoncement déguisé.
Sommaire
Qu’est-ce que le Scrumban ? Définition
Le Scrumban n’est pas un troisième framework venu s’ajouter aux deux autres, mais une composition. L’équipe garde ce qui structure Scrum — un collectif stable, un Product Owner, des rendez-vous réguliers — et remplace le moteur d’exécution par celui de Kanban : on ne s’engage plus sur un lot de travail pour deux semaines, on tire la tâche suivante quand une place se libère.
| Ce que le Scrumban garde de Scrum | Ce qu’il emprunte à Kanban |
|---|---|
| Une équipe stable et pluridisciplinaire | Le tableau visuel du flux |
| Les rôles (Product Owner, facilitateur) | Les limites de travail en cours (WIP) |
| La rétrospective et l’amélioration continue | Le réapprovisionnement à la demande |
| La revue avec les parties prenantes | Les métriques de flux (délai, débit) |
| Un backlog priorisé | L’abandon de l’engagement de sprint |
Une précision de statut, souvent passée sous silence : le Scrumban n’est pas un framework officiel. Le Guide Scrum ne le mentionne pas une seule fois, et le Kanban Guide non plus. Il n’existe donc ni définition normative, ni certification de référence — ce qui explique que deux équipes « en Scrumban » puissent travailler très différemment.
Personne ne peut vous dire que vous « faites mal » du Scrumban : il n’existe aucun texte pour en juger.
Comment fonctionne le Scrumban concrètement ?
Le mécanisme qui fait tout le travail est la limite WIP, pour work in progress : le nombre maximal de tâches autorisées simultanément dans une colonne du tableau. Une colonne « En développement » plafonnée à trois interdit d’en ouvrir une quatrième — il faut d’abord en terminer une.
Cette contrainte paraît bureaucratique et produit l’effet le plus visible de la méthode. Elle rend les blocages impossibles à ignorer : quand la colonne est pleine et que rien n’avance, l’équipe ne peut plus compenser en démarrant autre chose. Elle doit régler le problème. C’est inconfortable, et c’est précisément l’intérêt.
- Le tableau reflète le vrai processus — les colonnes correspondent aux étapes réelles de l’équipe, revue comprise, pas à un modèle générique.
- Chaque colonne porte une limite — souvent calée sur l’effectif au départ, puis ajustée en rétrospective.
- Le travail se tire, il ne se pousse pas — on prend une tâche quand on a la capacité, personne ne l’assigne d’avance.
- On mesure le flux — délai de traversée et débit remplacent la vélocité comme indicateur de prévision.
Conséquence sur l’estimation : beaucoup d’équipes en Scrumban abandonnent les story points. Dès lors qu’on ne s’engage plus sur un contenu de sprint, l’estimation détaillée perd son usage principal ; le découpage en éléments de taille comparable suffit à rendre le flux prévisible.
En vidéo : une introduction au ScrumBan (chaîne de Laurent Morisseau).
La planification à la demande
Deuxième changement de fond : la planification cesse d’être un rendez-vous périodique pour devenir un événement déclenché. L’équipe fixe un seuil — par exemple « quand il reste moins de cinq éléments prêts dans la colonne d’attente » — et c’est le franchissement de ce seuil qui provoque la session de réapprovisionnement.
Le raisonnement est celui du réassort en magasin : on ne recommande pas parce que c’est lundi, mais parce que le rayon se vide. L’équipe ne prépare que ce qu’elle va consommer, ce qui réduit d’autant le travail d’affinage sur des éléments qui auraient changé de priorité avant d’être pris.
Le backlog produit et sa priorisation restent indispensables — c’est lui qui alimente la colonne d’attente. En revanche, l’enchaînement revue puis rétrospective en fin d’itération se découple : la rétrospective reste calendaire, la revue peut suivre les livraisons réelles.
💡 Astuce — gardez la rétrospective à date fixe même en abandonnant les sprints. C’est le seul rituel qui n’a pas d’équivalent dans le flux : sans lui, l’amélioration continue disparaît sans que personne ne le remarque.
Quand adopter le Scrumban — et quand s’en abstenir
Le Scrumban se justifie quand le sprint contraint sans rien apporter. Trois situations reviennent régulièrement :
- La charge est imprévisible — équipes de run, de support ou de maintenance, dont la moitié du travail arrive en cours de route. S’engager sur un périmètre à deux semaines n’a pas de sens.
- Les demandes sont hétérogènes — des tâches de quelques heures côtoient des chantiers de plusieurs semaines. Le flux absorbe cette variété que le sprint tolère mal.
- Le sprint devient une formalité — l’équipe replanifie systématiquement en cours de route, et le rituel ne sert plus qu’à constater l’écart.
À l’inverse, trois cas où il vaut mieux s’abstenir :
- Une équipe jeune en agilité — le cadre serré du sprint sert à prendre des habitudes. La souplesse du flux suppose une discipline qui ne s’improvise pas.
- Un problème qui est ailleurs — priorités instables, dette technique, rôles Scrum mal tenus : changer de méthode ne réglera rien de tout cela.
- Un besoin fort de dates — si l’organisation attend des engagements calendaires, l’abandon du sprint déplace la difficulté sans la résoudre, et prive l’équipe du rituel où ces engagements se négociaient.
⚠️ Le piège principal — le Scrumban sert souvent de porte de sortie honorable : on abandonne les sprints, les estimations et l’engagement, sans jamais poser de limite WIP ni mesurer le flux. Résultat, on a perdu la structure de Scrum sans gagner la discipline de Kanban. Si vous ne posez qu’une chose, posez les limites WIP.
Ce que j’observe sur le terrain, c’est que la bascule réussit quand elle est décidée en rétrospective par l’équipe, avec un problème précis à régler et une limite WIP écrite au tableau dès le premier jour. Quand elle est imposée d’en haut comme un gain d’efficacité, elle produit surtout un tableau Kanban et aucune des propriétés qui vont avec.
FAQ — Tout savoir sur le Scrumban
Le Scrumban, c’est quoi exactement ?
Une méthode hybride qui conserve l’organisation d’équipe de Scrum — rôles, équipe stable, rétrospective — et adopte les mécanismes de flux de Kanban : tableau visuel, limites de travail en cours et planification déclenchée par un seuil plutôt que par le calendrier.
Garde-t-on les sprints en Scrumban ?
Pas nécessairement. Certaines équipes conservent une cadence fixe pour la synchronisation et n’ajoutent que les limites WIP ; d’autres abandonnent complètement l’engagement de sprint au profit d’un flux continu. Les deux configurations sont couramment appelées Scrumban.
Qu’est-ce qu’une limite WIP et comment la fixer ?
C’est le nombre maximal de tâches autorisées en même temps dans une colonne. Une pratique courante consiste à partir de l’effectif de l’équipe, puis à ajuster en rétrospective : si la colonne est toujours pleine, la limite est trop haute ou une étape en aval bloque.
Le Scrumban est-il un framework officiel ?
Non. Ni le Guide Scrum ni le Kanban Guide ne le mentionnent, et il n’existe aucun texte de référence qui en fixe la définition. C’est une pratique de terrain, ce qui explique les écarts importants entre deux équipes qui s’en réclament.
Faut-il encore estimer en Scrumban ?
Beaucoup d’équipes arrêtent l’estimation détaillée : sans engagement de sprint, elle perd son usage principal. Un découpage en éléments de taille comparable suffit généralement, la prévision reposant alors sur le délai de traversée et le débit observés.
Pour quelles équipes le Scrumban est-il adapté ?
Principalement les équipes à charge imprévisible — run, support, maintenance — et celles dont les demandes sont très hétérogènes en taille. Il est en revanche déconseillé aux équipes qui débutent en agilité, pour lesquelles le cadre du sprint reste structurant.
