Scrumban is like Scrum and Kanban an Agile project methodology.

In short Scrum is focused on building “self-organizing teams” and Kanban helps you to implement a “smooth flow of work”.

With Scrumban, the combination of Scrum and Kanban, teams can keep their focus on projects or product development and at the same time be flexible in their handling of interim work.

So, you can say that Scrumban is the best of both. Where in some cases Kanban is too flexible/unorganized (which is very good for helpdesk tickets e.g. or Scrum is too much focused on project management/estimations/meetings, Scrumban will offer the best solution for your team. A lot of teams start with Scrumban and can evolve into using Scrum at the end.

Key Features of Scrumban


Iterations are kept short. A recommendation is not to have iterations exceeding two weeks.

No early binding

We don’t assign work/task to team members upfront.

Pull instead of push

Tasks are not assigned to the team members. Each team member alone decides which task from  To-Do he or she takes.

Use WIP limits

To reduces multitasking, improve lead time and to have an accurate overview we add Work-In-Progress limits. For example: not more than 5 items can be in the status “In progress”. These are enablers for the Kanban pull system. The limits are used in the WIP and To-Do columns

Continuous Flow

Work keeps coming in and leaving the system.


Use a “ready” column to organize (between Backlog and Doing). You can add numbers to the tasks to prioritize if needed.

Feature Freeze

This is used when a deadline of a project is approaching.

Stop estimating

We don’t do any planning poker anymore for providing an estimation. During the planning meetings, you can use t-shirt sizes for estimations because we still need the discussion and decomposition.

Trigger planning

The planning is based on demand and it only occurs when the planning trigger goes off.

Bucket size planning

Bucket size planning allows a team to do long-term planning. Before items go on the Scrumban board, they have to go to three buckets:

  • 1-year bucket: long-termed ideas/goals
  • 6-month bucket: define main requirements
  • 3-month bucket: define tasks that can be completed


The basic board contains three columns:

  1. To-Do: after the planning meeting, tasks are added here
  2. Doing: when a team member is working on a task
  3. Done: when a task is finished

Extra columns can be added when it’s useful (is mostly decided with the team)

  • Designing
  • Developing
  • Reviewing
  • Testing


Sprint planning

This is called Replenishment meeting. The part where we break a story into tasks, isn’t necessary anymore.

Daily Scrum

Still the same as with Scrum but more focusing on the workflow.

Sprint Review

This is called Product demo. We still need to have fast feedback from our customers. It’s better to review the product sooner than later. You may use a cadence that works with the team and the customer – weekly, completely on demand, ….


We still need continuous improvement, so yes. How often is entirely up to the team.


Saving time

There is no need to do estimating or sprint planning. The team only plans when it’s needed.

High quality

The time saved allowed you to focus on the quality control.


Fact and decisions just when they are needed.

Large projects

It’s easier to handle large projects with the bucket size planning.

Less stress

By using the pull principle and the visualization of the workflow, team members have less stress.

Continuous improvement (-> Kaizen)

Kaizen stands for good changes (kai=change / zen=good) or continuous improvement. It’s about small incremental improvements which will leads to consistency, better workflow, high quality team members, ….

Here’re some quotes:

“Everyone, every day, everywhere!”

“We can always improve Kaizen starts with you”

How to implement Scrumban

This is my personal experience/advice. I always start very basic, with a blank page. I did this also in the past with Scrum and Kanban. What I like with agile project methodologies is that they guide you to a great process/flow for your team.

The first step is to visualize the work / process. In the beginning I like to use a physical board over a digital one. It’s maybe old-school for most of us but in my experience, it works the best in the beginning. The focus of the team is on the board and not each monitor of a team member. People have to stand up and go to the board to change something.

After that, I let the team decide how we can improve by looking at the failures, reoccurring problems, …. Everything we add to our process/flow is discussed with the team. Every team is different that’s why I always start basic and let the team do the rest.

I hope this article was useful and helpful. And I hope for some it can be used as a reference.

Written by Werner Kellens