Scrum VS Kanban

When to use scrum and when to use kanban
Scrum vs Kanban

Scrum and kanban are both agile practices/frameworks. They have evolved over the years to address specific challenges around organizing work. 

Many teams and organizations have often leveraged a combination of practices from both scrum and kanban, sometimes to work to their advantage, sometimes not so much. So, the questions often arise: what is scrum and kanban and when should we use one or the other? Can scrum and kanban be used interchangeably for any and every project? Or are there complementary practices in both that can be leveraged as a combination?

 Related Article: The Key Values and Principles of the Agile Manifesto

First of all, if we combine practices from scrum and kanban but do not apply the entire framework, we are neither doing scrum nor kanban. We are doing something, but it is neither of the two. We may also reap some benefits of the practices, but not what we will get from the complete implementation of scrum or kanban.

Having said that, let's compare scrum vs kanban against various attributes to understand the types of projects in which each may be used. The table on the next page summarizes the attributes of both scrum and kanban and highlights the types of projects in which they may be used based on that attribute.







Work cycle

Iterations. Scrum has sprints within which the team follows the plan-do-check-act (PCDA) cycle.

Complex, iterative work, like new product or feature development, may be better done with scrum.

Continuous flow. In a kanban work cycle, as soon as one thing finishes, the team takes another thing up.

Kanban is better for continuous flow work like support and services.


WIP - Work In Progress

WIP limits are set by the scrum team for every sprint, and new work is picked up only after all the work is completed.

If teams need a sense of accomplishment/completion/closure, use scrum.

WIP limit is ongoing. As soon as some work finishes, pickup new work.

If teams keep working on one thing after another, use kanban.


Inspect-Adapt (Empiricism)

Every sprint is an opportunity to inspect and adapt. Work cycles through multiple sprints for improvisation, if needed.

If the work continuously evolves and needs improvisation, use scrum.

No specific mechanism to inspect and adapt. Work flows in one direction.

If the work is a one-time effort, and doesn't require inspection and adaptation, use kanban.


Transparency (Empiricism)

Artifacts in scrum include the product backlog, sprint backlog, an increment. Respectively provide requirements, implementation, and deliverables transparency.

If requirements need to be tracked separately from tracking the work in progress, use scrum.

No specific artifacts for transparency. Kanban board provides some transparency. Many teams use product backlog (from scrum) in combination with kanban boards.

If only implementation needs to be tracked, use kanban.



Specific events for planning the sprint and the day — sprint planning and daily scrum.

Use scrum if disciplined planning at regular intervals is required.

No provision for planning the work. Teams adopt their own cadence and approach to planning.

User kanban planning can be intermittent or on an as-needed basis.



Accountabilities in scrum develop responsibility focus e.g. product owner for business, developers for domain, and scrum master for impediments.

If teams need individuals focused on these responsibilities, use scrum.

There are no accountabilities like product owner, developers, etc. in kanban. It assumes a group of individuals working on tasks.

If the team is simply a group of individuals with some expertise, use kanban.



Scrum has active stakeholder and customer involvement — at least once a sprint during a sprint review event.

If the work is innovative, creative, or new and requires stakeholder and customer feedback/engagement, use scrum.

Kanban does not provide a way to engage stakeholders or customers. Many teams adopt a once-a-month “sprint review” approach.

If the work is mostly daily routine and does not require frequent stakeholder engagement use kanban.


Related Article: Collaboration Between Teams Using Different Process Models


About the Author


Scrum Alliance Certified Scrum Trainer® Punita Dave has been working with scrum and other agile practices for almost 20 years and has successfully transformed more than 100 large, mid-size, and small companies and has trained more than 6000 people. She has pushed the boundaries of agile and scrum beyond software: hardware, data centers, finance, marketing, medical, food, and real estate industries. She remains passionate about changing the way organizations, businesses, and people work.


Stay Connected

Get the latest resources from Scrum Alliance delivered straight to your inbox