It’s Not Scrum Vs. Kanban; It’s Scrum And Kanban

Scrum and Kanban have a lot in common — far more similarities than differences. Scrum is more structured and disciplined than Kanban. Kanban is more adaptive and flexible than Scrum. But the major difference that I see is simply that Scrum relies on time boxes, Kanban relies on workflow control.

Scrum Time Boxes

A time box is a fixed time period. Scrum often uses 2-4 week time boxes though shorter and longer periods are also in use. One of the major tenets of Scrum is that the time box cannot be violated. At the outset, backlog items are selected such that they can be completed within the time box. Anything that is not completed moves to the next time box or may even return to the backlog.

Time boxes establish a cadence. The team and the user community become accustomed to regular software deliveries at the end of each time box. Face it, we are all creatures of habit. We like events to occur on a regular schedule.

Kanban Workflow Control

Kanban controls workflow by limiting work-in-progress (WIP). The general idea is that stories are either waiting in the backlog (inventory), being developed (in-progress), or completed. Having too much work-in-progress leads to waste, confusion and bottlenecks.

Limiting WIP provides some flexibility. It is easier to change the workflow, add new stories or re-prioritize them using Kanban than it is with Scrum. Thus, Kanban may work better in environments that are in flux — hard to predict.


The challenge with time-boxes is that while they sound good on paper, maintaining a regular rhythm in software development is not easy. Interruptions, unforeseen problems, new requests, emergencies, etc. are all lurking nearby just waiting to disrupt the time box.

The challenge with limiting WIP is the constant attention needed to maintain control. For example, if code development gets too far ahead of system test, adjustments need to be made to restore balance. Also, the team may feel like they never get a break as the work items just keep coming.

Which is best? I like Kanban although I have to admit that we can never get away from hard deadlines — customer demos, trade shows, industry events, financial reporting, etc. Kanban doesn’t do well with these kinds of time-boxed efforts. Maybe we need Scrumban — borrowing the best elements of each.

We could employ a lengthy time box, say 8-12 weeks, and use Kanban within the time box switching to Scrum near the end in order to synchronize the final deliverables. Our ultimate goal is to satisfy the needs of the business. Don’t ever forget that.

If you want to read more about the similarities and differences between Scrum and Kanban, take a look at the PDF download called “Kanban and Scrum – Making the most of both“. Your thoughts?

Updated: March 23, 2011 — 10:06 pm


  1. Management want to have running code every two weeks. For them they Kanban does n’t provide enough commit on delivery.

  2. One of the projects that i am working with has frequent interruptions by way of production issues tgat the team has to work on. I am finding that in these cases we will have to break the strict timebox of scrum. We will have to deliver faster and not wait for sprint end. Kanban seems to have tge answer. Seriously looking at scrumban for a solution

Comments are closed.