What is Scrumban & How To Implement It? [+Templates]
Everything you need to know about this flexible-yet-structured project management methodology.
When it comes to running effective projects, having a solid framework that you follow can help reduce the challenges that come up during the project. Not totally, of course. But methodologies can help make sure that you’re as close to being on track, on time, and on target as possible.
Because of this, there are no shortages of approaches you can take to project management. Agile frameworks like scrum and kanban have been around for a while and help teams organize themselves into productive units. As great as they are, however, not everybody loves them. They have limitations and they don’t always allow development teams to reach their full potential.
For those who like aspects of both scrum and kanban, but not everything, there’s a hybrid of scrum and kanban called scrumban.
What is scrumban?
Scrumban is a hybrid agile methodology that combines the traditional visual workflow (the board-based system) of
. This combination gives you a system that is flexible, but also structured, so your teams have the room they need to adapt to changing demands from various stakeholders.
Teams can also use scrumban as a way to ease the transition to a full kanban methodology from scrum. Since it uses both approaches and allows teams to get used to the idea of kanban without being dumped into it without having to suddenly start thinking visually about your workflow like you would with a full kanban approach.
How is scrumban different from kanban and scrum?
Scrumban is a hybrid methodology of both kanban and scrum. Unlike scrum, scrumban doesn’t require regular planning sessions (these are done on-demand, rather than having daily standups), and teams are allowed more independence, as scrum masters don’t exist within the team structure, per se. Iterations (or sprints) are also shorter. You’re typically limited to one to two-week iterations, rather than pushing upwards of a month in some cases.
Similar to the kanban system, you gain a board that helps you better visualize the work that needs to be done, but unlike the kanban board, there are more columns at play to help you look at work and planning that needs to be done in the future.
Scrumban workflow overview
Like most methodologies, scrumban helps you define the flow of work for any given project. Scrumban teams are able to work in a more self-directed way than they would with other agile methodologies, but the goal is the same - to keep pushing forward with work items and completing projects without overloading your teams.
Similar to the scrum methodology, scrumban breaks down teamwork into iterations. Unlike scrum, these iterations are shorter, typically limited to less than three weeks. Tasks aren’t assigned during these iterations, but team members are able to pull tasks from the list of things that need to be done in the scrumban board. These shorter iterations encourage continuous improvement and help you keep your team focus on the core tasks that need to be completed, rather than getting bogged down by everything.
Limiting work-in-progress (WIP)
Similar to kanban, work in progress is limited during iterations. This helps you do focused bursts of work based on tasks that are critical to your project and, since the backlog isn’t constantly being replenished as work is completed, you’re also giving your team time to breathe in between iterations.
The limits don’t just apply to the backlog, though. Since scrumban uses an extended board, there can be work that needs to be done in the future included. Again, for the sake of focus, Teams can get ahead of work if the backlog is empty, but there aren’t so many tasks that they’re tempted to work on multiple tasks at once.
Scrumban uses an on-demand system when it comes to planning. With scrum, you typically end up holding meetings on a regular basis (like once a week) to plan out what the next sprint section of a spring is going to look like and to assign more tasks. With scrumban, though, planning only happens when the backlog has been cleared and there’s a need to add more tasks. It saves a lot of time and removes the pressure of a weekly planning session from your team, especially during those times when they’re particularly busy, as these planning meetings can create a kind of bottleneck.
With scrumban, planning is often done using a bucket method that helps define and plan future work for the team. These buckets are designed to look at current work, tasks that are 3 months out, 6 months out, and 12 months out. This helps teams plan out projects and goals in the long term, rather than exclusively focusing on what needs to be done right now. Typically what happens is that the 12-month bucket is for ideas that loosely follow the overall plans for your company, product, or team. It’s a good place to brainstorm new product ideas. Each bucket is slightly more specific and concrete in terms of the ideas and tasks they contain.
Like most things in scrumban, there are WIP limits in place to keep teams from getting lost in planning.
The extended scrumban board and WIP limits make prioritizing work that needs to be done much easier. Work is typically prioritized during the iteration planning sessions and placed into either the to-do list or the backlog. This way, teams know exactly what tasks need to be completed and the rough order they need to be completed in.
Scrumban board creation
Scrumban uses a task board similar to the kanban method, although it’s extended to include future work and a backlog. The point of the scrumban board is to allow you and your team to see what needs to be done, what’s being worked on, and what’s already complete, along with providing a glimpse of what’s coming up in the future.
The boards can be easily created using your favorite task management platform (we’ve got one here) and can be customized to match the specific workflow of your team.
Team roles assignment
Team roles aren’t as important in scrumban as they are in other methodologies. For example, there isn’t a defined scrum master, nor are product owners typically involved. The teams themselves tend to keep the same roles that they would have had before scrumban was implemented, but it’s not necessary. If anything, each team member should have a very specific role, as work is self-directed and people can select the tasks they want to work on. Specific roles help keep people working in their zone of genius.
Lead time & cycle time
In scrumban, lead and cycle time are used as metrics. The original idea came from kaban and the metric measures how much time it takes the team to complete each task. Lead time measures this from when a task has been added to the backlog, while cycle time measures the period from when a team member pulled the task into work-in-progress. If they are calculated correctly and if the tasks are similarly scoped, lead and cycle time can be used for project estimations.
What are the advantages scrumban?
Scrumban is a good way to get the best of both worlds, so to speak, by combining critical aspects of both scrum and kanban.
Easier management of ongoing projects
Scrumban helps you save time largely because you’re not going into a planning mode every couple of weeks. Planning is done only when necessary, basically only when the backlog is done. This gives you and your team the time they need to focus on doing the work, rather than having to set aside time to talk about the work you’re doing after every sprint.
It’s also an easy-to-adopt methodology because it doesn’t involve the same complexity that comes with scrum (which is a big reason scrumban is often recommended as a way to transition to scrum). When you add to that the fact that it gives teams a way to be more self-sufficient (since there is no scrum master), you end up with a process that is self-directed, flexible, and ideal for tackling bigger projects.
The expanded board used in scrumban gives teams and team leaders a pretty clear view of what work needs to be done during any given iteration. Not only that, but it provides a look at what might be coming up, thanks to the buckets planning for future work.
For team leaders, it gives them a strong understanding of how well the team is working together, if there are any bottlenecks in the process, and whether more team members are needed.
For teams, it helps them get a sense of just how much work needs to be done and what kind of work is coming up. Along with helping plan out their workweeks (or months), it gives them a way to see when a good time for personal time might be.
Scrumban helps empower teams by removing a lot of the managerial interactions. What this means is that rather than having work assigned to them on a regular basis, team members are able to select the tasks they want to work on, giving them better control over the kind of work they’re doing, which ultimately leads to greater satisfaction.
Not only that, but because there are fewer meetings (no weekly scrum meetings), people don’t feel bogged down by conversations that they don’t feel they need to be present for. The on-demand planning sessions mean that conversations about work only happen when they’re necessary.
Better quality of results
WIP limits really help your team focus on core tasks directly related to the projects. The lack of a continuously updated backlog means that team members aren’t tempted to take on more than they can handle or to juggle multiple tasks at a time. And, if they do try to, there aren’t as many tasks they can choose from.
This really helps you keep multitasking to a low, which ultimately produces better work. Not only that, but as we’ve mentioned, since the work is self-directed, people are focusing on the tasks they want to be working on, rather than whatever was assigned to them.
What are the principles of scrumban?
As you’d probably expect by now, scrumban uses a mix of principles borrowed from kanban and scrum. It’s designed to give you a best of both worlds approach that isn’t as rigid or complicated as scrum can be.
Scrumban gives you more control over organizational management because it provides a way to focus on core tasks that need to be worked on today (or this week), as well as a way to look to the future of your business and develop new ideas. The planning buckets and WIP limitations help you hone in on the critical tasks and push forward with projects, rather than getting lost in the weeds.
Clearly stated policies
Like any methodology, scrumban gives you a clear path to follow when working on projects. Having well-defined policies like this helps people understand their role in each project, what type of work they should be focusing on, and exactly what needs to be done.
Having a limited backlog and on-demanding planning sessions to fill that backlogs gives you and your team a way to prioritize the work that stands to benefit the company most. For example, you’ll be able to put an emphasis on tasks related to new features for products (if you’re doing software development) and help you also focus on the direction you want the company (or product) to take long-term.
Scrumban puts a lot more emphasis on the team itself, rather than relying on a scrum master to help direct things. Team members get to select the tasks they want to work on and they’re given more freedom to choose the kinds of tasks they prefer to work on. It might seem like a small thing, but having a team-centric approach often results in better work and fewer issues.
Simplification, standardization & specialization
Scrumban, like most methodologies, gives you a way to create a workflow that is easy to follow, easy to reproduce, and helps you find the exact people you need for the various tasks and projects you work on. Ultimately, it gives you a way to streamline the way you work, increasing efficiency and productivity within your teams.
4 scrumban templates to level up your project management
Here are four Coda docs that you can adapt for scrumban methodology today:
doc captures everything that a PM needs, from a kanban tracker to user testing to documentation. Even if you’re not a PM, I highly recommend copying this doc just for the structures — after all, we all need trackers for something.
A better way to launch your products
Smooth out your product development and feature launches with this
Perhaps the best thing about scrumban is how easy it can be to get started. It lacks the complexity of a true scrum and requires fewer people because you’re not relying on scrum masters to help drive progress. You can pretty much get scrumban going in three fairly straightforward steps.
Build your scrumban board. Building out your scrumban board is a good first step because it allows you to define how you're going to be working. Typically, as we’ve mentioned, it’s broken down into to-do, in-progress, and done, with columns dedicated to work that can be done in the future. The great thing about scrumban is that it lets you customize all phases of your workflow. You want to capture the idea of a backlog, what’s being worked on, and what’s done, but exactly what that looks like depends on how you and your team work best.
Set your limits. Scrumban works because you’re not overloading your team with an endless to-do list of tasks. Instead, you’re working from a list that gets shorter, helping you feel accomplished and (more importantly) reducing the amount of work your team is doing at once (and limiting multitasking).
Fill your backlog (and get to work). Once you’ve decided on the work-in-progress limits, it’s time to build out your backlog. You can start this off by having a meeting with your team about the work that needs to be done or you can fill it out with the tasks that you know are pending. It’s not a bad idea to start with a planning session since it can help you and your team prioritize the work that you’ve currently got on your plate.
When should you use scrumban?
Scrumban can really be implemented any time you want within your organization. That’s the beauty of working with a project management methodology that is flexible and easy to implement. There are, however, times when it makes sense to get started with scrumban.
You’re moving to or away from scrum
We’ve touched on this one before, but scrumban is an excellent framework to use when you want to take your team to the scrum methodology, but you don’t want to overwhelm them with a sudden shift to a fairly complex approach. Scrumban helps you ease the transition by slowly introducing aspects of scrum as a way to get your team used to working that way.
Similarly, if you’re looking to move away from scrum, scrumban can be an excellent alternative. You get to keep certain aspects of scrum, but you don’t have the full and complex system and you gain additional flexibility.
Scrumban is a great way to manage maintenance tasks for on-going projects. Because you’re able to schedule work out in the future, you can use scrumban to plan out tasks that need to be dealt with in the future. So if you know that you’re going to require a database update every few months, you can schedule it with scrumban.
You want more flexibility
Not everyone loves rigid frameworks. They can feel limiting and it’s easy to end up with a sense of being stuck on a certain task for too long. Scrumban helps you break away from that by giving your team more control over not only the tasks they’re taking on, but the way you’re working. Rather than being in a sprint for a few weeks, you select the tasks you want to work on based on what’s available. You’re not racing to complete the task within a certain time, either, you’re free to take a more relaxed approach to working through each task.
What are the characteristics of scrumban?
As mentioned, scrumban takes characteristics from both scrum and kanban to create a hybrid methodology. Because of this, the characteristics that define scrumban are often similar to both approaches, but with an approach that is unique to scrumban.
Typically, with kanban, you have three boards - to do, work in progress, and done. Scrumban takes these core boards and expands on them to give you and your team a broader look at what work needs to be done. How this breaks down, depends on how your team works. But, as an example, if you have a workflow that requires approval at a few different stages of the process, you can add in columns for approval.
You can also add in boards that look at long-term pieces of work that need to be done for projects by adding columns that look 3, 6, or 12 months ahead.
Backlog and work in progress limits
Scrumban places limits on both backlogs and works in progress as a way to help teams focus more on doing good work, rather than just getting all the things done. Rather than using a continuously updated backlog of tasks that need to be worked on, you get a pool of tasks that need to be completed. Once the backlog has been completed, more tasks are added and team members get to work on those. The goal is to provide a pool of tasks that don’t overwhelm your team. When you only add to the backlog after it’s been cleared, you can at least have a moment to enjoy the accomplishment before more tasks are added.
Along with that, teams can place limits on certain categories of work, like columns that include work for 6 months out. Your team can work on these tasks, but by placing a limit on how many can be done at once, you’re keeping them more focused on current needs. This also reduces multitasking and all the pitfalls that come with it.
When you’re working with an extended scrumban board, you can create better prioritization of your tasks. Rather than just have everything labeled as either needs to be done, in progress, or done, you can push less important tasks out to a future date. This is where those columns for 3, 6, or 12 months out can help. If you’re in the middle of a large project and you know that 6 months from now, you’re going to need to deal with task X, you can drop it into the 6 months column. It’ll still be there as something you need to work on, but your team knows it’s not a priority at the moment and will focus on other things.
Because scrumban is more self-directed than the other methodologies, being able to remove non-essential tasks from the to-do list keeps everyone on the same page.
Rather than regularly scheduled planning sessions, planning is only done when there is a need. This is fueled by the limits to work in progress and the backlog. In fact, the backlog being empty tends to trigger these planning sessions. Once the current backlog is empty, teams meet to discuss the next round of tasks that need to be completed.
While kanban itself has a certain amount of flexibility built-in, scrum can be a pretty rigid methodology that doesn’t allow you to shift gears easily if you need to. Scrumban gives you a way to bring that flexibility to your projects, while still keeping aspects of scrum that you like. Scrumban doesn’t rely on specific sprints, so you’re not locked into working on a single task or series of tasks for weeks at a time. Your team can work on the tasks that they’re best suited for, as long as they’re in the backlog.
What is a scrumban board?
A scrumban board is a way that teams are able to visualize the workflow using a kanban-style board. Tasks are moved through the workflow starting from the to-do column, moving through in progress, and ending up in the done pile at the end. The card system gives you and your team a quick way to see what’s being worked on, what’s done, and what still needs to be done at a glance without having to talk to each member of the team individually.
These boards let you set limits on the work being done because there is a limit on the number of tasks that can be in the backlog. Unlike kanban where the backlog is constantly updated, with scrumban new tasks are only added to the board when the backlog has been cleared.
Scrumban also lets you take tasks and place them in a queue of work to be done with columns on the board that are set for the future. We’ve been saying 3, 6, and 12 months out, but you can use whatever’s best for your team to help you manage the workload. Similar to the back, the scrumban board has limits placed on it, so you can't just load up your future selves with work.
What is the difference between scrumban and kanban?
On the surface, kanban and scrumban are very similar. They both use kanban boards to help you and your team visualize the work that needs to be done and team members can select the tasks they want to work on based on what’s listed in the “to do” column (rather than being assigned work by a project manager). However, the similarities end there.
Unlike kanban, scrumban uses more planning, although planning happens on-demand, as well as a more involved board that helps teams not just look at what needs to be done. It can also look to the future to plan out the next 3, 6, or 12 months, depending on what kind of long-term planning has been done. This added visualization allows teams to see what work has to be considered in the future.
But, there are limits placed on any work that falls into the expanded cards to help reduce the amount of multitasking that goes on and to help keep the team on the same page.
How is scrumban different from scrum?
The biggest difference between scrumban and scrum is that scrumban gives you a way to visualize your workflow using a card-based system. With scrumban, you’re still using a system that prioritizes the backlog and planning, but the way that you’re working through these is different. One of the more noticeable differences is that there isn't a scrum master managing scrum teams.
For example, with scrum, you’re focused more on getting as much done as possible within a sprint. With scrumban, however, you’re putting limits on work in progress (also called WIP limits) to focus more on clearing out your backlog and avoiding multitasking. Scrumban also includes planning and analysis phases, but planning is only done when needed and analysis happens before the work has been completed, not after as it would be in a traditional scrum setting.
A few of the 25,000+ teams that 🏃♀️ on Coda.
Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This page is a doc published on Coda.