Scrumban : définition, fonctionnement et différences avec Scrum et Kanban

Scrumban est un framework hybride qui combine la structure de Scrum (rôles, refinement, retrospective) avec le flux tiré et les WIP limits de Kanban. Il conserve la discipline itérative de Scrum tout en supprimant les Sprints à durée fixe pour aller vers une livraison continue.

Scrum est un framework itératif basé sur des Sprints à durée fixe (1 à 4 semaines) avec un Sprint Goal engageant. Scrumban supprime le Sprint Backlog figé et le remplace par un flux continu limité par des WIP limits : les items entrent au fil de l'eau, pas par lot.

Kanban n'impose aucun rôle, aucune cérémonie, aucune structure. Scrumban ajoute au flux Kanban une partie des pratiques Scrum : refinement, retrospective, rôles de Product Owner et Scrum Master, ce qui donne un cadre plus fort qu'un simple tableau Kanban.

Non. C'est même l'une des différences majeures avec Scrum : Scrumban abandonne le Sprint à durée fixe au profit d'un flux continu. Certaines équipes conservent une cadence hebdomadaire pour la retrospective et le planning, mais sans engagement de scope figé.

Oui, c'est courant. Le Product Owner reste le seul décisionnaire sur la priorisation du backlog. En Scrumban, il « alimente » la colonne Ready selon un seuil de réapprovisionnement plutôt qu'un Sprint Backlog complet.

Oui, dans la majorité des implémentations. Son rôle évolue : moins de facilitation d'événements Scrum stricts, plus de coaching sur le flux, le lead time, les WIP limits, la résolution des goulots d'étranglement.

Work In Progress limit : nombre maximum d'items autorisés simultanément dans une colonne. Elle force l'équipe à finir avant de démarrer, réduit le multitâche et rend visibles les goulots d'étranglement.

Jira, Azure DevOps, GitHub Projects, Trello, Notion, Linear, ClickUp — tous supportent des tableaux avec colonnes personnalisées et WIP limits. Jira propose un mode « Kanban » que l'on peut enrichir avec les événements Scrum pour obtenir un Scrumban complet.

Oui, via un tableau Kanban Jira sur lequel vous ajoutez des colonnes intermédiaires (Ready, Review), des WIP limits par colonne et vous planifiez manuellement les événements Scrum (refinement, retrospective).

Quand la nature du travail devient imprévisible (support, incidents, maintenance), quand le Sprint Goal n'a plus de sens, ou quand l'équipe ne peut plus s'engager sur un scope stable pour 2 semaines. La migration se fait par étapes, sans big-bang.

Lead time (temps entrée→sortie), Cycle time (démarrage effectif→fin), Throughput (items terminés par période), CFD (Cumulative Flow Diagram), taux de blocage par colonne, respect des WIP limits.

Oui. Scrumban respecte les 4 valeurs et 12 principes du Manifeste Agile : livraison fréquente, adaptation au changement, individus, collaboration. Il est même plus « lean » que Scrum sur la limitation du gaspillage grâce aux WIP limits.

Non. L'examen PSM I porte exclusivement sur le Scrum Guide. Mais connaître Scrumban aide à mieux comprendre les limites de Scrum et à répondre correctement aux questions sur les hybridations et l'auto-management.

Oui. C'est même l'un de ses cas d'usage historiques : équipes support, run, DevOps, cybersécurité, où les tickets arrivent en continu sans possibilité de planifier un Sprint Backlog stable.

Les tailles usuelles vont de 3 à 10 personnes, comme en Scrum. Au-delà, il faut envisager un split ou une organisation par flux de valeur.

Oui. SAFe intègre des équipes « Kanban Team » qui sont de fait des équipes Scrumban. La coordination inter-équipes utilise des events synchronisés (PI Planning) plutôt que des Sprints identiques.

Oui, comme en Scrum. La Definition of Done reste indispensable pour garantir la qualité de chaque item passé en « Done », d'autant plus que la livraison est continue.

Facultatif. Beaucoup d'équipes Scrumban abandonnent les Story Points au profit de la mesure du cycle time et du throughput, qui donnent des prévisions plus fiables sur du flux continu.

Continue : chaque item est livré dès qu'il atteint la colonne Done et passe la Definition of Done. Il n'y a pas d'attente d'une fin de Sprint pour livrer.

Non. Scrumban est une alternative pertinente pour les contextes de flux (support, maintenance, DevOps, exploitation SaaS). Pour le développement produit avec un Product Goal fort et un besoin d'engagement itératif, Scrum reste supérieur.

Le plus souvent : Product Owner (priorisation), Developers (auto-managés), et Scrum Master (coaching flux et amélioration continue). Aucun de ces rôles n'est obligatoire — c'est l'équipe qui adapte.

Le livre « Kanban and Scrum – making the most of both » de Henrik Kniberg et Mattias Skarin (téléchargeable gratuitement chez InfoQ) reste la meilleure introduction. Complétez avec le Scrum Guide et les principes Kanban de David J. Anderson.