By Rahul Dhakate · PMP & PSM I Certified · 19 May 2026 · learnxyz.in
Scrum and Kanban are the two most widely used Agile frameworks in software development and project management. Both appear on the PMP exam. Both are worth understanding in practice. And they are frequently confused because they share some surface similarities — both use visual boards, both emphasise incremental delivery, both reject the big upfront planning approach of Waterfall.
Contents
Kanban — What It Is and How It Works.
The Kanban Board — How It Works in Practice.
Scrumban — The Natural Hybrid.
Key Metrics: Comparing How Each Framework Measures Performance.
How Kanban and Scrum Are Tested on the PMP Exam..
But their underlying structures, their constraints, and the types of work they suit best are meaningfully different. Understanding those differences clearly will help you answer exam questions correctly and make better framework choices in real projects.
I have worked with Kanban boards across different project contexts. My honest assessment — shared here directly — is that Scrum and Kanban complement each other well. They are hand in glove. Neither is universally superior, but Scrum carries more structural value for most software product development contexts, while Kanban shines in specific situations where Scrum’s sprint cadence is less appropriate.
Scrum — A Quick Recap
Scrum is a framework for developing and sustaining complex products. It is built around fixed-length iterations called sprints — typically one to four weeks — at the end of which the team delivers a potentially releasable product increment.
Scrum’s defining characteristics: three prescribed roles (Product Owner, Scrum Master, Developers), four prescribed ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), three artefacts (Product Backlog, Sprint Backlog, Increment), and the Sprint itself as a container that holds all the work.
Scrum imposes structure. It tells you exactly how the team should be organised, how work should be planned, and how the team should inspect and adapt. This structure is both its strength and its limitation — it works exceptionally well for product development work where requirements evolve iteratively, but it can feel rigid for teams whose work does not fit neatly into sprint-sized batches.
Kanban — What It Is and How It Works
Kanban is a method for managing and improving workflow. Unlike Scrum, it does not prescribe fixed iterations, specific roles, or required ceremonies. Instead, it visualises the flow of work through a system and uses Work In Progress (WIP) limits to manage capacity and identify bottlenecks.
The word Kanban comes from Japanese — it means ‘visual signal’ or ‘card.’ The original Kanban system was developed by Toyota for manufacturing process management. In software and project management, Kanban has been adapted into a powerful workflow visualisation and optimisation tool.
The Core Kanban Principles
- Visualise the workflow — represent every piece of work as a card on a board, with columns representing stages of the workflow
- Limit Work In Progress (WIP) — cap the number of items that can be in progress at any stage simultaneously
- Manage flow — track how work moves through the system and identify where it slows or stops
- Make policies explicit — define clear rules for how work enters, moves through, and exits the workflow
- Implement feedback loops — regular reviews of the workflow to drive improvement
- Improve collaboratively and evolve experimentally — use data from the system to drive incremental improvements
The Kanban Board — How It Works in Practice
I have used Kanban boards across multiple project contexts, including support workflows, maintenance backlogs, and operational task management. The board is the central tool — a visual representation of all work items and their current status.
A typical software project Kanban board might have columns like: Backlog → Ready → In Development → In Review → In Testing → Done. Each work item is a card that moves left to right through these columns as it progresses. WIP limits are set for each active column — for example, ‘In Development’ might be capped at 4 items. No new item can enter ‘In Development’ until one exits.
The WIP limit is the mechanism that prevents the most common project team failure mode: everyone is busy but nothing is finishing. When a column hits its WIP limit, the team must focus on completing existing work before starting something new. This creates a pull system — work is pulled forward by capacity, not pushed in by demand.
The WIP limit concept is the single most powerful idea in Kanban. It forces the team to confront and resolve bottlenecks rather than accumulating more work in progress. A team with unlimited WIP has piles of unfinished work at every stage. A team with enforced WIP limits continuously optimises their flow.
Side-by-Side Comparison
| Factor | Scrum | Kanban |
| Cadence | Fixed sprint length (1–4 weeks) — regular rhythm | Continuous flow — no fixed iterations |
| Prescribed roles | Three required roles: PO, SM, Developers | No prescribed roles — existing team structure continues |
| Prescribed ceremonies | Four required ceremonies every sprint | No required ceremonies — optional regular reviews |
| Work planning | Sprint backlog committed at Sprint Planning | Work pulled from backlog as capacity allows — no sprint commitment |
| Change during work | No changes to Sprint Backlog mid-sprint | New items can enter the backlog at any time |
| WIP limits | Implicit — sprint capacity is the limiter | Explicit — WIP limits set per column on the board |
| Estimation | Story points or hours per sprint | Not required — cycle time used for flow measurement |
| Key metrics | Velocity (story points per sprint), burndown chart | Cycle time, lead time, throughput, cumulative flow diagram |
| Best for | Product development with evolving requirements and regular stakeholder feedback | Ongoing work, support queues, maintenance, operational tasks |
| Team structure | Dedicated cross-functional Scrum team | Can work with existing functional team structures |
When Scrum Works Better
Scrum is the stronger choice when:
- You are building a product iteratively — regular sprint reviews with stakeholders help validate direction and catch requirement changes early
- The team is dedicated to a single product — the sprint structure works best when the team is not context-switching between unrelated workstreams
- Requirements are evolving — the sprint backlog gives the Product Owner a regular opportunity to reprioritise based on new information
- The team benefits from structure and rhythm — the ceremonies create predictable checkpoints that help less experienced Agile teams stay aligned
- Stakeholder engagement is frequent and meaningful — Sprint Reviews are structured moments for feedback that Kanban does not provide by default
From my experience, Scrum carries more structural value for most software product development contexts. The ceremonies — particularly Sprint Planning and Daily Scrum — create the alignment and visibility that distributed teams need. The sprint boundary creates a natural forcing function for prioritisation decisions.
When Kanban Works Better
Kanban is the stronger choice when:
- Work arrives continuously and unpredictably — support tickets, bug fixes, maintenance requests, and operational tasks do not fit neatly into sprint-sized batches
- Work items have highly variable sizes — some items take hours, others take weeks. Fixed sprint lengths create artificial pressure on large items and wasted capacity on small ones
- The team serves multiple stakeholders with different priorities — Kanban’s pull system handles competing demands more naturally than sprint commitment
- Cycle time and throughput matter more than velocity — Kanban’s metrics are better suited to measuring service delivery performance
- The team cannot be dedicated full-time to one product — functional teams with shared responsibilities benefit from Kanban’s flexibility
The practical insight from working with both: Kanban and Scrum genuinely complement each other. Many teams run Scrum for their core product development sprint work while using a Kanban board to manage the support and maintenance work that flows alongside the sprint. The sprint cadence governs new feature development; the Kanban board governs the continuous flow of operational work. This hybrid approach is increasingly common and is recognised in PMI’s framework.
Scrumban — The Natural Hybrid
Scrumban is a hybrid approach that combines elements of both frameworks. It typically uses Scrum’s ceremonies and sprint cadence as a planning and review structure, while applying Kanban’s WIP limits and pull-based flow management to the daily execution of work.
Scrumban is particularly useful for teams transitioning from Scrum to Kanban or vice versa, and for teams whose work mix includes both planned product development and continuous operational support. The PMP exam may reference Scrumban as an example of hybrid Agile practice — it is worth knowing the term and the basic concept.
Key Metrics: Comparing How Each Framework Measures Performance
| Metric | Framework | What It Measures |
| Velocity | Scrum | Story points completed per sprint — used to forecast future sprint capacity |
| Sprint Burndown | Scrum | Remaining work in the current sprint — shows whether the sprint goal is on track |
| Release Burndown | Scrum | Remaining backlog across multiple sprints — forecasts release date |
| Cycle Time | Kanban | Time from work item start to completion — measures delivery speed |
| Lead Time | Kanban | Time from work item request to completion — includes waiting time |
| Throughput | Kanban | Number of items completed per unit time — measures team capacity |
| Cumulative Flow Diagram | Kanban | Visual representation of work items in each stage over time — identifies bottlenecks |
How Kanban and Scrum Are Tested on the PMP Exam
- Framework identification: A scenario describes a team pulling work as capacity allows with no fixed iterations. This is Kanban. A team committing to a two-week sprint with daily standups is Scrum.
- WIP limit questions: What is the purpose of WIP limits in Kanban? To prevent bottlenecks and ensure flow by capping the number of items in progress at any stage.
- Metric questions: A Scrum team’s velocity is declining over three sprints. What does this indicate? The team is completing less work per sprint — investigate whether impediments, scope changes, or team issues are causing the decline.
- Framework selection questions: A team manages an IT help desk with unpredictable incoming tickets. Should they use Scrum or Kanban? Kanban — continuous flow work without fixed iteration requirements suits Kanban better.
- Hybrid questions: A team uses sprint ceremonies for planning but manages daily work on a Kanban board. What is this approach called? Scrumban.
For the PMP exam, the distinction that matters most: Scrum is prescriptive — it tells you exactly how to work. Kanban is descriptive — it gives you principles and lets you apply them to your existing workflow without mandating a specific structure. When a question asks which framework allows a team to start immediately without changing their current structure, the answer is Kanban.
About the Author
Rahul Dhakate is a PMP and PSM I certified project manager and product management leader based in Nagpur, India, with 20 years of experience managing software projects across BFSI, eCommerce, and enterprise software. He has used Kanban boards alongside Scrum practices across multiple project contexts, applying each framework to the type of work it suits best and combining them where the work mix demands both structured sprints and continuous flow management. He writes at LearnXYZ.in to help working professionals understand both the theory and the real-world practice of project management.
Good Reads:
