There’s no explicit Scrumban guide like there is for Scrum. And, you’d be hard-pressed to find its creator and not mistake him for a casual nobody.
If you decide to search for Scrumban on Google, the top suggestion asks “Is Scrumban real?”
This Scrumban guide helps you figure out what about this mysterious framework is real and what’s not.
We’ve also put together some Scrumban recipes for your team so you can get a flavor of which ingredients work for you.
Table of Contents:
👻 Pssst: If you’re not sure on the differences between Scrum and Kanban, check out this piece first: Scrum vs Kanban: 5 Differences Between Sprints and Flow.
Scrumban is an agile team and project management approach. It blends the structure of Scrum but keeps Kanban’s emphasis on workflow optimization.
Scrumban often combines Scrum’s sprints with Kanban’s practices. In doing so, teams create a continuous flow of work items with a blend of Scrum events and roles added in.
But the lack of clear and authoritative Scrumban guidance makes implementing it difficult.
For many teams, Scrumban emerges organically from their working practises. They pick some elements of Scrum, add a few from Kanban, and end up with Scrumban.
Often, teams practising Scrumban won’t even realise it because they don’t know their hybrid approach has a name. The lack of an authoritative Scrumban guide makes it hard to compare your practices to a “rule-book” and say: “Yes, we are doing Scrumban”.
Here are some of the main Scrumban stumbling blocks teams run into:
✋ Our take on Scrumban: It’s okay to mix and match whatever parts of Scrum and Kanban you like as long as it is helping your team achieve their goals.
Scrumban suits any team that needs more flexibility than Scrum offers and wants to focus on improving the flow of work.
For that reason, it’s often – but not exclusively – favoured by disciplines other than software development.
An Agile HR, Agile sales or Agile marketing team might not have a strict “Sprint Goal” as Scrum would suggest. This is due to the come-and-go nature of tasks (for example, answering support queries).
So they may prefer a hybrid approach like Scrumban that allows them to manage a flow of tasks that may not happen once per sprint or that can’t be planned ahead of time.
Here’s what the data says about Scrumban usage:
Scrumban offers teams a chance to save time on meetings, escape Scrum’s constraints or Kanban’s infinite flow, and catch issues before they turn into disasters.
It offers the best of both worlds by letting you cherry-pick what you want from the two frameworks.
Here are some of the main benefits of choosing Scrumban:
🍕 Scrumban is like a half-and-half pizza: It doesn’t matter what you call it or even that you know what it’s called as long as the taste works for you.
Here are some common situations when trying out Scrumban might be a good idea for your team:
Most Scrum teams likely already use some form of Scrumban. Many Scrum teams use a Kanban board, and plenty of Kanban teams have added retrospectives or cycles.
Scrumban’s mysterious nature means you’re practically free to pick whatever ingredients you want from Scrum and Kanban. All that matters is that your half-and-half combo works for your team and stakeholders. Don’t let any agile police officer tell you otherwise! 👮♀️
Here are some of the most commonly used Scrum and Kanban elements adopted in Scrumban:
Kanban and most Scrum teams already use a board with columns and cards representing work items to visualize their work process.
Scrumban teams certainly use such a board, calling it either a Scrum board, Sprint board, or simply a Kanban board. It’s one of the few elements that all teams use, no matter your particular flavor of Scrumban.
Most Scrumban teams have a more extended board with various headings mapping out all steps in a process as Kanban teams do. When Scrum teams use one, they only have one column for each workflow phase, like Design, Development, and Testing.
For Scrumban teams, a board might list a goal for the current work cycle at the top to create focus for the team and help them decide which tasks to prioritize.
A pull mechanism means that when one task leaves a column of the task board (for example, building), a team member can pull it into the next one (for example, reviewing).
This practice helps improve the flow of work by quickly exposing bottlenecks.
With Kanban’s pull system, you don’t assign individuals specific tasks. Instead, one or more team members are responsible for a particular part of the workflow represented by a column on the board.
Scrumban teams may adopt this approach by pulling in the highest-priority item from the preceding phase’s Done or Ready column when they have the capacity and such an item is ready to be worked on.
There are different ways to prioritize work items in Scrumban:
WIP measures the number of work items in progress, either in your entire process or in a specific column of your Kanban board.
Limiting the number of things the team works on creates focus and forces prioritization decisions from whoever is pulling in or pushing tasks to the team.
Limiting WIP works because multitasking doesn’t. Having to switch between many different projects and tasks slows people down and causes mistakes. Even a mathematical formula called “Little’s Law” will tell you the same. In his book Applying Scrum with Kanban, Andy Hiles explains Little’s Law as follows:
“Little’s Law reveals that in general, for a given process with a given throughput, the more things that you work on at any given time (on average), the longer it is going to take to finish those things (on average).”
A WIP limit is essentially a one in, one out policy: A new work item can only enter the process or a column when there’s space for it.
Pro tip: A helpful starting point is to limit the number of items in a column to the number of people available to take on such work. Say you have two designers, then the Design column on your board should have a WIP limit of two.
There are three other metrics besides WIP that Scrumban teams often track:
Most Scrumban teams that switch to these metrics drop Scrum’s story point estimation, velocity, and the Sprint Burndown Chart.
Scrumban teams may find that WIP, cycle time, throughput, and SLEs take less effort to track and explain to stakeholders. At the same time, they give more accurate and actionable insights.
Scrumban allows you to keep whichever Scrum events work for you and drop the rest.
If you retain Sprints as part of your Scrumban process, you may choose to hold meetings according to the same schedule. But if you do away with Sprints you might be able to simply hold meetings when your new flow-supporting metrics tell you the time is right for them.
The Sprint cycle essentially triggers your Sprint Planning like clockwork in Scrum. In a more Kanban-influenced application of Scrumban, you only need to plan when the backlog – or a specific Ready or Done column – falls below a certain number of items.
Corey best describes why such a trigger is effective and preferred in his book on Scrumban:
“The ideal work planning process should always provide the development team with [the] best thing to work on next, no more and no less… Scrum-style timeboxed planning usually provides a much bigger backlog than what is strictly necessary to pick the next work item, and as such, is unnecessary inventory and therefore unnecessary waste.”
Many Scrumban teams still keep a Daily Standup, use it to focus on the current task board in a macro sense – looking at exceptions and issues with work items and WIP limits – compared to Scrum, where the focus is on individuals and their specific impediments.
This handy chart adapted from Andy Hiles’ book, Applying Scrum with Kanban, shows which flow metrics in this article he recommends discussing in which Scrum event.
Scrumban doesn’t require you to mandate specific roles as Scrum does. But if assigning roles seems helpful for creating structure and clarity about responsibilities within your team, then you can do that with Scrumban.
Which roles you’ll need depends on how close to which side of the Scrum-Kanban spectrum you move with your particular flavor of Scrumban. If you plan to keep most of the Scrum events and artifacts, then it’s helpful to keep all or most of Scrum’s roles or accountabilities.
Kanban doesn’t prescribe any particular accountabilities like Scrum does, but many Kanban teams do create functions similar to Scrum’s:
No Scrum or Kanban roles are mandatory in Scrumban, but you can mix and match to suit your team’s working preferences or jobs.
Assuming you keep the Scrum Master role, Agile Coach Donald “Mark” Haynes suggests changing the role from:
“focusing on removing impediments to also managing the work-flow. They need to monitor inefficiencies in inventory as it flows through the work queue.”
On development teams, some Scrumban teams assign roles according to the Kanban board columns, which creates accountability for each column.
For example, you might have a dedicated person who carries out testing and is accountable for the testing column in your Kanban board. With Scrumban you can also allow the team to decide among themselves and collaborate across columns. The choice is yours.
Implementing an agile framework is a daunting task. That’s why we’ve collected some expert guidance on how to get started with Scrumban whether you’re a new team, or transitioning from Kanban or Scrum.
Remember, with Scrumban you can pick and choose as you like. It might be that your Scrum practise organically evolves into a Scrumban practice over time, or vice versa.
Scrumban’s creator suggests that companies organized in departments like marketing, engineering, and analytics often find it easier to start with Kanban because it requires fewer changes to existing structures.
However, if your organization already builds teams around projects and products, he recommends starting with Scrum.
Synthesizing the advice and experience of other Agile Coaches and Scrum Masters, the rule of thumb is:
When in doubt, start with Scrum because it provides the most guidance and structure while not being too overbearing.
Scrum is relatively simple to understand and get started on – at least with the basics.
Whichever approach you begin with, we recommend you practise it for several months at least. That lets you figure out which elements of your framework are working for you and which aren’t. That gives you foundations from which to investigate and experiment with elements from the other framework.
Here are five steps to get started transitioning from Scrum to Scrumban:
