Kanban vs Scrum : quelles différences et quelle méthode choisir ?

Scrum si vous développez un produit et pouvez vous engager sur un Sprint Goal de 1 à 4 semaines. Kanban si votre travail arrive en flux (support, maintenance, DevOps) ou si les priorités changent en continu. Si vous êtes entre les deux, Scrumban est une excellente hybridation.

Scrum est un framework itératif avec Sprint, rôles (PO, Scrum Master, Developers) et 4 événements. Kanban est un système de flux continu qui n'impose ni rôle ni timebox, mais ajoute des limites de Work In Progress explicites.

Oui. Kanban respecte les valeurs et principes du Manifeste Agile : livraison continue de valeur, feedback, amélioration continue, réponse au changement. Il est officiellement reconnu comme méthode agile.

Oui, c'est le framework agile le plus utilisé au monde. Scrum implémente concrètement les 4 valeurs et 12 principes du Manifeste Agile.

Oui. Scrum.org publie même le Kanban Guide for Scrum Teams. L'hybridation la plus connue s'appelle Scrumban : on garde la structure Scrum (Sprint, rôles, événements) et on ajoute les limites WIP et un flux continu tiré.

Scrumban est une hybridation qui conserve les événements et rôles Scrum tout en ajoutant les limites WIP, le pull system et les métriques de flux (lead time, throughput) issus de Kanban. Il a été formalisé par Corey Ladas en 2011.

Support client, helpdesk, DevOps, SRE, maintenance applicative, opérations IT, gestion d'incidents, TMA — tout contexte où le travail arrive en flux imprévisible et où un Sprint fixe serait contre-productif.

Développement produit, MVP, startup, équipe pluridisciplinaire, contexte où un Sprint Goal peut être partagé, besoin d'un rythme et de rendez-vous réguliers (Review, Retrospective), scaling multi-équipes (LeSS, Nexus).

Un Scrum Board est réinitialisé à chaque Sprint et reflète le Sprint Backlog. Un Kanban Board est persistant, matérialise le flux du travail et impose des limites de WIP par colonne. Le second est plus adapté aux flux continus, le premier aux cadences.

En Jira, un projet Scrum expose un backlog, des Sprints et un burndown. Un projet Kanban expose un board unique persistant, des limites WIP et un cumulative flow diagram. Vous pouvez convertir de l'un à l'autre à tout moment.

Pas au démarrage. Commencez par maîtriser un des deux frameworks (Scrum ou Kanban) avant d'hybrider. Scrumban devient pertinent quand une équipe Scrum atteint sa maturité et souhaite fluidifier le flux à l'intérieur du Sprint.

Une limite Work In Progress (WIP) plafonne le nombre d'items simultanément dans une colonne du Kanban Board. Elle force à terminer avant de commencer et met en évidence les goulets d'étranglement.

Oui, c'est justement son intérêt. Kanban livre en flux continu, dès qu'un item passe en Done. Il n'y a pas de Sprint ni de timebox.

Oui : Product Owner, Scrum Master et Developers forment le Scrum Team. Le Scrum Guide définit précisément leurs accountabilities.

Non, aucun rôle n'est obligatoire. Kanban se pose sur l'organisation existante. Deux rôles optionnels sont proposés : Service Request Manager et Service Delivery Manager.

Scrum, dans la majorité des cas. Une startup a besoin d'un Product Goal clair, d'un Sprint Goal partagé et d'un feedback régulier avec les early adopters. La Sprint Review est un rendez-vous naturel.

Kanban. La TMA reçoit des demandes correctives et évolutives au fil de l'eau. Timeboxer un Sprint est peu adapté aux SLA. Un board Kanban avec classes de service permet de prioriser les urgences.

Kanban. Le support gère des interruptions non planifiables. Les limites WIP et le lead time sont les métriques clés.

Kanban le plus souvent, ou Scrumban. On mélange incidents (flux) et backlog d'amélioration (produit). Un board Kanban avec classes de service (incident, amélioration, dette) fonctionne bien.

Non, la vitesse dépend de l'équipe, pas du framework. Scrum offre une cadence prévisible ; Kanban optimise le flux et réduit le lead time. Un Kanban bien limité en WIP peut être plus rapide qu'un Scrum en surcharge.

Oui sur le changement de priorité (autorisé à tout moment sur les items non tirés). Non sur la cadence : Scrum offre une flexibilité inter-Sprint. À la fin de chaque Sprint, tout peut être réordonné.

Le Scrum Guide dit « d'un mois ou moins ». En pratique, moins d'une semaine devient contre-productif : le coût des événements Scrum (Planning, Review, Retro) devient disproportionné.

Pas officiellement. Kanban propose un rôle optionnel de Service Request Manager qui joue un rôle proche : priorisation de la file d'entrée avec les stakeholders.

Oui, publié par Kanban University (Anderson) et un Kanban Guide for Scrum Teams publié par Scrum.org en collaboration avec la communauté Kanban.

Aucune n'est imposée, mais des cadences sont recommandées : replenishment meeting (alimenter la file Ready), delivery planning meeting, service delivery review, opérations review, risk review.

Un système où une étape aval tire le travail d'une étape amont dès qu'elle a de la capacité, plutôt que d'être poussée. C'est le cœur de Kanban et de Lean.

Le lead time est le temps écoulé entre la création d'un item (arrivée dans le backlog) et sa livraison en production. C'est la métrique client par excellence en Kanban.

Le cycle time mesure le temps entre le démarrage effectif d'un item (passage en In Progress) et sa fin (passage en Done). Il exclut l'attente en backlog.

Le throughput est le nombre d'items terminés par unité de temps (jour, semaine, mois). Il permet de faire des prévisions probabilistes.

Un graphique empilé qui affiche le nombre d'items dans chaque colonne du board dans le temps. Il révèle immédiatement les goulets d'étranglement et l'accumulation de WIP.

Pas au sens Scrum. Kanban a une file d'entrée (Ready) alimentée à intervalles réguliers. Elle est ordonnée mais n'est pas un « Product Backlog » au sens du Scrum Guide.

Non — c'est alors un simple tableau visuel, pas du Kanban. Les limites WIP sont l'un des cœurs de la méthode.

Non. Kanban n'impose pas ce rôle. Un Service Delivery Manager joue un rôle voisin mais moins prescriptif.

Aucune taille imposée. Kanban fonctionne aussi bien pour 2 personnes que pour 20. Scrum recommande 10 personnes ou moins pour le Scrum Team.

Oui, mais ce n'est pas obligatoire. De nombreuses équipes Kanban abandonnent les estimations au profit du throughput et de prévisions probabilistes (analyse Monte-Carlo).

Non — le Scrum Guide n'impose aucun outil. De nombreuses équipes Scrum utilisent un Kanban Board pour visualiser leur Sprint Backlog.

Non, Kanban s'adapte à toutes les tailles. C'est même l'un des rares systèmes qui passe à l'échelle sans framework de scaling additionnel.

PSM I pour valider votre maîtrise de Scrum. PSK (Professional Scrum with Kanban) pour valider votre capacité à intégrer Kanban dans un contexte Scrum. Les deux sont proposées par Scrum.org.

Non, le Scrum Guide 2020 ne mentionne pas Kanban. Mais Scrum.org publie un Kanban Guide for Scrum Teams qui explique comment les combiner.

Pas officiellement. Kanban recommande une Service Delivery Review et une Operations Review qui jouent un rôle similaire d'amélioration continue.

Oui, structurellement. Kanban propose des « classes de service » (expédite, fixed date, standard, intangible) qui permettent de gérer les urgences sans casser le système.

Mal, par design. Le Sprint est censé protéger l'équipe des interruptions. Si les interruptions sont fréquentes et non planifiables, Scrum n'est pas le bon choix.

Oui, sans problème. De nombreuses équipes basculent vers Kanban quand la nature de leur travail change (ex : passage d'un projet à de la maintenance).

Oui, mais l'inverse est plus coûteux : Scrum introduit des rôles, événements et engagements qui nécessitent formation et culture.

Oui, la plupart des équipes Kanban utilisent des outils numériques (Jira, Trello, Linear, Azure DevOps). Le pilotage par métriques (lead time, throughput) fonctionne parfaitement en remote.

Jira (Software), Azure DevOps, Linear, ClickUp, Trello, GitHub Projects supportent tous des projets Scrum avec backlog, Sprints, burndown.

Trello (le pionnier), Jira (mode Kanban), Linear, Azure DevOps, GitHub Projects, ClickUp, Monday. Choisissez celui qui gère nativement les limites WIP et le CFD.

Scrum, très majoritairement. Kanban n'est pas dans le Scrum Guide. Il peut apparaître de manière allusive (empirisme, transparence, limites de WIP), mais aucune question spécifique n'est posée.

Non, la rentabilité dépend du contexte. Kanban peut sembler moins coûteux (pas de rôles imposés), mais Scrum offre plus de prévisibilité et de valeur produit livrée.

Pas nécessairement à l'échelle de l'entreprise. Différentes équipes peuvent utiliser différents frameworks selon leur contexte. Une même personne peut aussi être formée aux deux.

Sur scrum.org, dans la section Resources > Kanban. Il est gratuit, disponible en anglais et dans plusieurs langues.