The two most widely used agile frameworks in the workplace: roles, events and artifacts on the Scrum side; flow, board and work-in-progress (WIP) limits on the Kanban side. Essential ground for any product or technical team working in sprints or continuous flow, and one of the most searched-for topics in the Project Management & Agile cluster, right alongside the Product Owner role.
Scrum and Kanban are the two most widely deployed agile frameworks in the workplace, but their respective vocabularies are easy to mix up: sprint, backlog, daily scrum, retrospective on the Scrum side; column, WIP limit, lead time, cycle time on the Kanban side. Confusing these two frameworks in a meeting can quickly undermine your credibility, especially in front of a team that practices one or the other day to day.
The difficulty isn't just the number of terms, it's how close they are semantically: a Kanban board and a Scrum board look visually similar but rest on different logics — continuous flow versus fixed-length iterations. Flashcards with spaced repetition are well suited to this kind of fine-grained distinction, which doesn't stick well from simply reading an article or a piece of documentation once.
Each card forces active recall: retrieving the exact definition of a Scrum event or a Kanban metric, rather than settling for approximate recognition. The FSRS algorithm reschedules each card right before you'd forget it, which meaningfully reduces the time needed to reach lasting mastery of this dense vocabulary.
This category is one of the most in-demand in the cluster: Scrum and Kanban show up in most job postings related to product or technical delivery, whether for a developer, Scrum Master, project manager, or Product Owner role.
A common pitfall is learning both frameworks in parallel from the start, which encourages mixing up close terms (for example confusing the Scrum Master role with a Kanban 'flow manager' role, which doesn't formally exist in Kanban). This category is structured to consolidate Scrum first, then Kanban, before comparing the two — a sequence that limits that risk of mixing them up.
Beyond vocabulary, understanding both frameworks also helps you choose the right tool for the context: Scrum works well for products whose scope can be broken down into regular increments, while Kanban suits more continuous workflows like support or maintenance, where fixed iterations make less sense.
Five subtopics cover Scrum roles, events and artifacts, along with Kanban flow and work-in-progress limits.
The responsibilities of each Scrum role and how they interact throughout a sprint, in particular the distinction between Scrum Master and manager, or between development team and external stakeholders.
Sprint planning, daily scrum, sprint review, retrospective — purpose, duration, frequency and participants of each event in the Scrum cycle, and what each one is meant to produce as a concrete outcome.
Product backlog, sprint backlog, increment — what each artifact represents, who keeps it updated, and how it evolves over the course of a sprint until delivery, along with the transparency each artifact is meant to provide.
Columns, cards, pull-based flow — the visual and operational principles that structure a Kanban board, and how a task moves from one column to the next as work progresses.
Why and how to limit the number of tasks in progress at the same time, and the flow metrics that go with it (lead time, cycle time, throughput) used to measure and improve the performance of a Kanban flow.
A progression that clearly separates the two frameworks before comparing them, rather than mixing them up from the start — the same sequencing that helps avoid confusion in the explanation above.
Roles, then events form a logical pair: every Scrum event involves specific roles, with a defined purpose and duration.
Once roles and events are in place, artifacts (backlogs, increment) make full sense: they're produced and updated during those events.
Kanban flow and WIP are easier to grasp once compared directly to the Scrum mechanics you already know — fixed iterations vs. continuous flow, prescribed roles vs. no formal roles.
Once both vocabularies are acquired separately, practice explaining out loud the difference between a Scrum term and its Kanban equivalent (or lack thereof) — this reformulation exercise strengthens long-term retention.
Many learners blur Scrum and Kanban together on the surface before memorizing both vocabularies separately — don't skip the step of consolidating each one individually before comparing.
The recommended path consolidates Scrum first (roles, events, artifacts), then moves to Kanban. This avoids mixing up two close vocabularies from the start and makes it easier to compare the two approaches afterward.
Scrum organizes work into fixed-length iterations (sprints) with defined roles and events. Kanban relies on continuous flow with no imposed iteration, regulated by work-in-progress (WIP) limits rather than a fixed calendar.
No, these are different roles. The Scrum Master facilitates the Scrum process and removes obstacles for the team, without hierarchical authority over it. A project manager typically carries broader responsibility for timeline, budget and scope.
Yes, this combination exists and is sometimes called Scrumban in certain contexts — it borrows elements from both approaches. This category covers the two frameworks separately, to properly lay the groundwork for each before considering a combination.
It's the maximum number of tasks allowed at the same time in a column on the Kanban board. It forces the team to finish work in progress before starting new tasks, which reduces multitasking and improves average completion time.
No. This category covers the vocabulary and practical concepts of Scrum and Kanban as used in the workplace. For exam-oriented preparation, the dedicated Project Certifications category is more appropriate — it likewise contains no official exam questions.
Yes, this category exists in both English and French, with the same 5-subtopic breakdown in each language.
The Product Owner is indeed a Scrum role and is mentioned in the Scrum roles subtopic. Their responsibilities (backlog management, prioritization, user stories) are covered in more depth in the dedicated Product Owner category, to avoid duplicating content between the two.
Two natural next steps: Product Owner if you're heading toward the role that manages the product backlog, or PMO and Governance if you're more interested in coordinating multiple teams.
No, unlike Scrum, Kanban doesn't define formal roles like the Scrum Master or Product Owner. That's an important structural difference between the two frameworks: Kanban focuses on the flow of work rather than on prescribed roles.
Because both frameworks address a similar problem — organizing delivery work — with visually similar tools (a board with columns or swimlanes). The underlying logic differs enough, though, that mixing up the terms in front of a practicing team is a fast way to lose credibility.
There's no universal answer — it depends on the nature of the work. Teams building a product in regular increments often start with Scrum for its built-in cadence and ceremonies; teams handling a continuous stream of unpredictable requests, like support or ops, often find Kanban's flow-based approach a more natural fit.
Access the decks in the Scrum and Kanban category, free and premium.
See the decks