Les deux frameworks agiles les plus utilisés en entreprise : rôles, événements et artefacts côté Scrum ; flux, tableau et limites de travail en cours (WIP) côté Kanban. Une base indispensable pour toute équipe produit ou technique organisée en sprints ou en flux continu, et l'un des sujets les plus recherchés du cluster Gestion de projet & Agile.
Scrum et Kanban sont les deux frameworks agiles les plus déployés en entreprise, mais leur vocabulaire respectif se confond facilement : sprint, backlog, daily scrum, rétrospective côté Scrum ; colonne, limite de WIP, lead time, cycle time côté Kanban. Une confusion entre ces deux référentiels en réunion peut rapidement décrédibiliser une prise de parole, surtout face à une équipe qui pratique l'un ou l'autre au quotidien.
La difficulté ne vient pas seulement du nombre de termes, mais de leur proximité sémantique : un board Kanban et un board Scrum se ressemblent visuellement, mais reposent sur des logiques différentes (flux continu contre itérations de durée fixe). Les flashcards avec répétition espacée sont bien adaptées à ce type de distinctions fines, qui se mémorisent mal par simple lecture d'un article ou d'une documentation.
Chaque carte impose un rappel actif : retrouver la définition exacte d'un événement Scrum ou d'une métrique Kanban, plutôt que de se contenter d'une reconnaissance approximative en la relisant. L'algorithme FSRS replanifie chaque carte juste avant l'oubli, ce qui réduit sensiblement le temps nécessaire pour atteindre une maîtrise durable de ce vocabulaire dense.
Cette catégorie est l'une des plus demandées du cluster : Scrum et Kanban sont mentionnés dans la majorité des offres d'emploi liées à la delivery produit ou technique, que ce soit pour un poste de développeur, de Scrum Master, de chef de projet ou de Product Owner.
Un piège fréquent consiste à apprendre les deux frameworks en parallèle dès le départ, ce qui favorise les confusions entre termes proches (par exemple confondre le rôle de Scrum Master avec celui de responsable de flux Kanban, qui n'existe pas formellement dans Kanban). La catégorie est structurée pour consolider d'abord Scrum, puis Kanban, avant de comparer les deux — une séquence qui limite ce risque de mélange.
Au-delà du vocabulaire, comprendre ces deux frameworks aide aussi à choisir le bon outil selon le contexte : Scrum convainc pour des produits où le périmètre peut être découpé en incréments réguliers, Kanban pour des flux de travail plus continus comme le support ou la maintenance, où des itérations fixes ont moins de sens.
Cinq sous-thèmes couvrent les rôles, événements et artefacts Scrum, ainsi que le flux et les limites de travail en cours Kanban.
Les responsabilités de chaque rôle Scrum et la façon dont ils interagissent tout au long d'un sprint, en particulier la distinction entre Scrum Master et manager, ou entre équipe de développement et parties prenantes externes.
Sprint planning, daily scrum, sprint review, rétrospective — objectif, durée, fréquence et participants de chaque événement du cycle Scrum, et ce que chacun doit produire comme résultat concret.
Product backlog, sprint backlog, incrément — ce que chaque artefact représente, qui le maintient à jour, et comment il évolue au fil d'un sprint jusqu'à la livraison.
Colonnes, cartes, flux tiré (pull) — les principes visuels et opérationnels qui structurent un tableau Kanban, et comment une tâche progresse d'une colonne à l'autre.
Pourquoi et comment limiter le nombre de tâches en cours simultanément, et les métriques de flux associées (lead time, cycle time, débit) qui permettent de mesurer et d'améliorer la performance d'un flux Kanban.
Une progression qui distingue clairement les deux frameworks avant de les comparer, plutôt que de les mélanger dès le départ.
Rôles, puis événements Scrum forment un couple logique : chaque événement mobilise des rôles précis, avec un objectif et une durée définis.
Une fois rôles et événements acquis, les artefacts (backlogs, incrément) prennent tout leur sens : ils sont produits et mis à jour lors de ces événements.
Flux et WIP Kanban se comprennent d'autant mieux qu'on les compare directement aux mécanismes Scrum déjà acquis — itérations fixes contre flux continu, rôles prescrits contre absence de rôles formels.
Une fois les deux vocabulaires acquis séparément, entraînez-vous à expliquer à voix haute la différence entre un terme Scrum et son équivalent (ou son absence d'équivalent) côté Kanban — cet exercice de reformulation renforce la mémorisation à long terme.
Beaucoup d'apprenants confondent Scrum et Kanban en surface avant d'avoir mémorisé les deux vocabulaires séparément : ne sautez pas l'étape de consolidation individuelle avant de comparer.
Le parcours recommandé consolide d'abord Scrum (rôles, événements, artefacts), puis bascule vers Kanban. Cela évite de mélanger deux vocabulaires proches dès le départ et facilite ensuite la comparaison entre les deux approches.
Scrum organise le travail en itérations de durée fixe (sprints) avec des rôles et événements définis. Kanban repose sur un flux continu sans itération imposée, régulé par des limites de travail en cours (WIP) plutôt que par un calendrier fixe.
Non, ce sont des rôles différents. Le Scrum Master facilite le processus Scrum et retire les obstacles pour l'équipe, sans autorité hiérarchique sur elle. Un chef de projet a généralement une responsabilité plus large sur les délais, le budget et le périmètre.
Oui, cette combinaison existe et est parfois appelée Scrumban dans certains contextes — elle emprunte des éléments aux deux approches. Cette catégorie couvre les deux frameworks séparément pour bien poser les bases de chacun avant d'envisager une combinaison.
C'est le nombre maximal de tâches autorisées simultanément dans une colonne du tableau Kanban. Elle force l'équipe à terminer les tâches en cours avant d'en démarrer de nouvelles, ce qui réduit le multitâche et améliore le temps de traitement moyen.
Non. Cette catégorie couvre le vocabulaire et les concepts pratiques de Scrum et Kanban tels qu'utilisés en entreprise. Pour une préparation orientée certification, la catégorie dédiée Certifications gestion de projet est plus appropriée — elle ne contient elle non plus aucune question officielle d'examen.
Oui, cette catégorie existe en français et en anglais, avec le même découpage en 5 sous-thèmes dans les deux langues.
Deux suites naturelles : Product Owner si vous vous orientez vers le rôle qui gère le backlog produit, ou PMO et gouvernance si votre intérêt porte davantage sur la coordination de plusieurs équipes.
Le Product Owner est bien un rôle Scrum et il est mentionné dans le sous-thème Rôles Scrum. Sa mission (gestion du backlog, priorisation, user stories) est cependant traitée en détail dans la catégorie dédiée Product Owner, pour éviter de dupliquer le contenu entre les deux catégories.
Non, contrairement à Scrum, Kanban ne définit pas de rôles formels comme le Scrum Master ou le Product Owner. C'est une différence structurelle importante entre les deux frameworks : Kanban se concentre sur le flux de travail plutôt que sur des rôles prescrits.
Parce que les deux frameworks répondent à un problème similaire — organiser le travail de delivery — avec des outils visuellement proches (un tableau avec des colonnes ou des couloirs). La logique sous-jacente diffère pourtant suffisamment pour que confondre les termes devant une équipe qui pratique l'un des deux fasse rapidement perdre en crédibilité.
Accédez aux decks de la catégorie Scrum et Kanban dans le catalogue, gratuits et premium.
Voir les decks