Scrumban Guide: How to Blend Sprints with Flow
Scrumban is the most popular hybrid Agile framework. It blends Kanban and Scrum into one coherent approach. But look into Scrumban and it’s tricky to figure out how to get started.
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.
What is Scrumban?
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.
To mix and match or not?
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:
- 🤔 Many people know a lot about Scrum but not much about Kanban besides its recognizable board with columns representing the work process. Many Scrum teams also call their sprint board a “Kanban board”.
- 👨💻 Scrumban’s creator, Corey Ladas, doesn’t see the method as a half-Scrum half-Kanban hybrid, but more as a taster to help Scrum teams transition to Kanban.
- 📜 There’s no official Scrumban guide. Besides Corey’s 2011 book – Scrumban: Essays on Kanban Systems for Lean Software Development – there’s no official guide or community around the methodology.
- 😳 Guidance on Scrumban is muddled. The information on Scrumban from other sources mostly contradicts Corey’s original premise. Many sources simply suggest you mix and match elements of Scrum and Kanban as you like.
✋ 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.
Who uses Scrumban?
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:
- In a 2021 study, Agile Sherpas found that 53% of Agile marketing teams use a hybrid methodology that borrows from more than one framework and 8% explicitly used Scrumban.
- In 2020, the State of Agile HR report showed that 80% of Agile HR teams use some parts of Scrum, and 55% use some parts of Kanban, indicating that there must be a cross-over between the two frameworks.
- Many software and product teams also use it, with 9% of Agile teams claiming to use Scrumban in 2021.
Why choose Scrumban over Scrum or Kanban
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:
- ✅ You can customize it to your needs. You create flexibility and save time by picking the Scrum roles and events that bring value to your team and stakeholders.
- ♻️ Kanban metrics like WIP and cycle time help you streamline your process and reduce the frequency of the events you keep. Kanban metrics also help catch problems as they happen instead of waiting for a review or retrospective event. For example, when your team pulls in – or gets assigned – too much work, this shows immediately through broken Work In Progress numbers.
- 📆 Hold meetings only when you need them. Scrum Sprints always have a fixed duration dictated by time, usually two weeks. In contrast, with Scrumban, you can be more flexible about when those meetings take place. For example, you may decide that a planning meeting only needs to be called if the number of work items in your Sprint Backlog or Ready column drops below a certain threshold.
- 👤 Scrumban gives teams more flexibility with their roles. In Scrum, teams are meant to be self-managing and include all the roles needed on a team to reach the product goal. For teams working in other disciplines, such as growth for example, incorporating marketers, designers, and sales-people, it can be more difficult to identify a single product goal everyone is pushing towards.
- 📋 Scrumban allows teams to customize how much structure they want their work cycles to have. It gives the team a chance to find a happy medium between continuous flow and sprinting. A continuous workflow with no clear start or end can feel monotonous to Kanban teams, but building in regular retrospectives, for example, can help.
When to use Scrumban with your team?
🍕 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:
- 🥅 Stakeholder requirements and customer priorities change more frequently than your sprint intervals can keep up with. Scrumban gives teams more flexibility to adapt to changing priorities at any time.
- 🏃 Your team gets more work assigned than it finishes, or other bottlenecks cause work to pile up somewhere in your process. With Scrumban, teams may pay more attention to Kanban metrics such as WIP or cycle time that identify problems more quickly.
- 🐛 You need to block all other sprint work for testing toward the end of sprints. Or you need to make a heroic effort to achieve the promised sprint goal. While this might be evidence that you’re taking on too much each sprint, Scrumban can help if you add WIP limits to your Scrum practice.
- 💎 You’re not getting much value from your sprint goals or certain Scrum events, like planning, daily standups, or your retrospectives. Scrumban can help teams save time by eliminating Scrum events that don’t serve their goals.
- 🌀 Your team prefers focusing on and working in Kanban’s flow, but your stakeholders like the regular cadence of Scrum. Scrum offers regular planning, review, or releases on a macro level and Kanban can help the team organize on a task level. Scrumban lets teams combine the best of both frameworks.
- 🧱 Scrumban can give Kanban workflows a bit more structure that reduces monotony. Kanban teams that lack a long-term direction or find themselves in a perpetual flow will need some recurring moments to rest and reflect.
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.
Which Scrum and Kanban elements can you use in Scrumban?
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 boards that visualize the work process
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.
Pull mechanisms for tasks
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:
- Team members decide, guided by the work cycle’s current goal.
- A Product Owner or similar role takes on this responsibility.
- The team prioritize during Sprint Planning or a similar event.
- Ageing items go first, ensuring nothing gets stuck, which safeguards flow in your system.
Work In Progress (WIP) limits
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.
Metrics that support flow
There are three other metrics besides WIP that Scrumban teams often track:
- ♻️ Cycle time is usually expressed in days. It measures how long it takes a work item to flow from “started working on it” to “done” – essentially how long it’s counted as WIP in your system.
- ➡️ Throughput is the number of work items a team has completed within a specific period of time, like a day, week, sprint, or month.
- 🎢 Service Level Expectation (SLE) takes the team’s historical average cycle time. It uses that data to give a probabilistic forecast for when future work might be completed.
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:
- 👤 A Service Delivery Manager, for example, who’s in charge of improving workflow efficiency is akin to the Scrum Master.
- 👤 A Service Request Manager in charge of customer satisfaction is similar to a Product Owner in Scrum.
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.
How to implement Scrumban
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.
When you’re new to agile
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.
Transitioning from Scrum to Scrumban
Here are five steps to get started transitioning from Scrum to Scrumban:
- 🗺️ Map out your work process on a board and add all your current work items in their corresponding columns (if you haven’t done so already).
- 📈 Add WIP limits so that each person equals one WIP item (for example, if you have one person working on testing, your limit for that column is 1). Make monitoring and addressing WIP bottlenecks an essential part of your daily standups and retrospectives.
- 🟨 Refine your Kanban board by adding additional columns that match the steps in your work process. You may also want to add Done or Ready columns to help create a pull mechanism.
- 📜 Create policies for each column, outlining when an item can move from one column to the next and what you do with ones that violate such criteria.
- 🗑️ Start experimenting with dropping events and processes that no longer deliver value for your team or stakeholders. At the same time, start experimenting with ingredients from Kanban to see which increase flow and value for your team.
Transitioning from Kanban to Scrumban
While the route from Kanban to Scrum is less common, there are three Scrum elements some Kanban teams like to add to their Scrumban practice:
- 🌀 Adding work cycles that are either time or trigger-based creates beginnings and endings, or at least rest points, for planning or reflecting between execution. Usually, a meeting that’s similar to Sprint Planning, a Sprint Review, or a Retrospective demarcates such cycles.
- 🎯 Setting a goal for a certain period or cycle creates clarity and focus for the team around which work items to prioritize. It can also give purpose day-to-day by providing a more significant or longer-term objective you’re working toward.
- ♻️ Holding retrospective meetings whenever the team feels an issue or challenge needs further reflection and investigation. Running regular retrospectives helps put some more structure around Kanban-leaning work styles. It also complements Kanban’s focus on process improvement.
What’s not to like about Scrumban?
Whether you believe Scrumban most resembles a half-and-half pizza or something else entirely, one conclusion is indisputable: Scrumban is Agile.
Unlike Scrum, which has hard edges, Scrumban lets you pick what works best for your team and customers.
Its lack of an official foundational guide ensures there’s no dogma or holy text for zealots to point to. And its flexible approach to roles and events helps it adapt to many existing team and organizational structures.
Yet, if you’re still unsure whether to give Scrumban a try, consider this last reassurance. Scrumban doesn’t burn the bridge back to your existing Scrum or Kanban practice. Returning is always possible and never hard.