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
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.
This is used when a deadline of a project is approaching.
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.
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:
- To-Do: after the planning meeting, tasks are added here
- Doing: when a team member is working on a task
- Done: when a task is finished
Extra columns can be added when it’s useful (is mostly decided with the team)
This is called Replenishment meeting. The part where we break a story into tasks, isn’t necessary anymore.
Still the same as with Scrum but more focusing on the workflow.
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.
There is no need to do estimating or sprint planning. The team only plans when it’s needed.
The time saved allowed you to focus on the quality control.
Fact and decisions just when they are needed.
It’s easier to handle large projects with the bucket size planning.
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