“Should we switch from Scrum to Kanban?”
We get this question all the time from struggling teams. Usually after a few rough sprints where commitments weren’t met, interruptions kept piling up, or the team just felt boxed in by the sprint structure.
The problem with framing it as Scrum *versus* Kanban is it misses what makes each approach valuable. It’s like asking whether you should use a calendar or a to-do list. Yes, you should. You probably need both, just for different things.
Today we’re not going to give you a “how to implement Scrum” guide or walk through setting up a Kanban system. Instead, we’ll help you think about what each approach does well so you can use the right tool—or combination of tools—for your situation.
What’s the difference?
First off, let’s get clear on the core different between the two approaches.
The single biggest difference between Scrum and Kanban is this: In Scrum, you limit how much work you need to focus on at once using a time box. That’s the sprint, a 1-4 week cycle where you plan and focus and then reflect on what you did and do it over again. In Kanban, by contrast, there are no time boxes. You focus your work using work in progress (WIP) limits. You may decide your team is only going to actively work on, say, two or three things at a time.
There are a bunch of other nuances, like:
- What meetings you might have
- What you call things
- The states that work goes through
- The policies around work
But it mostly comes down to time boxes or WIP limits as your main tool for focus.
What does Scrum do at its best?
When a team is using Scrum well, it’s a nice container for collaboration and continuous improvement on small, valuable work items. We talk about this more in our “Why Scrum Works When It Works” episode, and we have a ton of advice about how to achieve this on our Scrum Done Right landing page.
What does Kanban do at its best?
When a team is using Kanban well, it gives them visibility into how work flows through their system so they can make it flow better. The focus on making work flow smoothly is very valuable because most organizations have tons and tons of unfinished work hanging around for various reasons.
When to use each one
We like Scrum as the starting point if you’re doing plannable work like software development. Time boxes just fit nicely with how humans naturally function—we naturally plan and reflect in years, quarters, months, weeks, and days. It’s how our bodies and minds work.
We like Kanban for work that is not so plannable, like operations and support kinds of work.
We’ve seen examples of product development teams using Kanban to good effect. And we’ve seen examples of operational teams using something like Scrum to structure ongoing work. But generally as a starting point, if you’re doing plannable work start with Scrum, if you’re doing emergent and responsive work start with Kanban.
How to get the best of both
The reality on most successful teams is actually a combination of Scrum and Kanban. Let’s look at a few ways to do that well.
Scrum-like events in your Kanban system
The four Scrum events do a minimal set of jobs most teams need:
- Sprint Planning — What should we focus on next?
- Daily Scrum — How should we work together today to get the most important work done?
- Sprint Review — Are we going in the right direction and making progress like we expected?
- Sprint Retrospective — What should we experiment with to become more effective at our work?
Many Kanban teams benefit from analogous events. Since there’s no sprint, they don’t have to all happen on the same cadence. You might examine and refine your input queue of planned work every week. You might demo and reflect on the results every two weeks. You could have a retrospective once a month.
(In our experience, teams who leave Scrum for Kanban because of “too many meetings” but who take continuous improvement seriously inevitably end up with variations on the four Scrum events, usually with different names.)
Kanban around Scrum with the PO Board
Our PO Board backlog model is a Kanban system for the backlog. Work flows from ideas on the left to completed work in production on the right. We limit WIP in the backlog at different levels of detail so backlog refinement emerges the right information just-in-time. Learn more in our PO Board episode.
Kanban within Scrum with the expedite lane
In Scrum, there’s just one of what Kanban would call a “class of service,” a type of work item that gets a certain policy applied to it. Namely, plan something in Sprint Planning, and you can expect it to be done by the Sprint Review. Need something mid-sprint? Put it on the backlog for the next sprint.
But if a Scrum team does both new development and production support, they can find themselves with genuine emergencies that can’t wait until the next sprint. Kanban to the rescue! Adding another class of service provides a structured way to handle emergencies without breaking what makes Scrum work. Learn more in our episode about it.
Kanban within Scrum with WIP limits
Many Scrum teams fall into the trap of working on a bunch of different things in parallel. Some even structure their work so that they don’t have to collaborate on the same work items. This undermines a lot of the benefits of Scrum.
One way to work towards making a change there is to borrow the WIP limit idea from Kanban. You can agree to only work on 2-3 items at once, even if it feels slower, and that gets people to collaborate more effectively.
This also helps avoid the “develop a bunch of stuff and throw it over the wall to the testers” issue inside Scrum. With a WIP limit, you can’t start developing more things until the current ones get tested. I’ve seen teams move towards practice like Behavior-Driven Development from this positive pressure. They realized piling up work for testing wasn’t actually helping them get more done, so they adopted BDD to move much of the testing effort to the front and make it more collaborative.
One pitfall to avoid
Finally, it’s worth mentioning a common pitfall we’ve seen when it comes to Scrum and Kanban. Teams struggling to deliver say, “Scrum doesn’t work for us. Let’s switch to Kanban.” And then the “Kanban” they switch to has no WIP limits, no cycle time tracking, no experiments to improve flow.
If the constraints in Scrum are making it apparent that you’re not delivering, don’t just remove the constraints—identify and remove the root causes for the delivery issues. Adding elements of Kanban within or around Scrum can actually help. For example, a tight WIP limit will make it very visible where work gets stuck in a sprint.
Reset your team with the best of Scrum and Kanban
Our calendar is just about full for 2025, but we have room in Q1 for teams who want to start the new year with a Humanizing Work Team Reset event. We can help your team identify what’s limiting their effectiveness and support you as you craft and run experiments using the best of Scrum and Kanban.
Schedule a free consultation to discuss your situation and see if Humanizing Work is right for you.
Last updated