What is Scrumban?

If you’re interested in Agile project management, chances are you’ve heard of Scrum and Kanban. But, what about Scrumban? 

Scrumban is actually a clever amalgam of Scrum and Kanban — hence the amusing name. 

This relatively new approach to project management combines the hard structure of Scrum with the flexibility and visual nature of Kanban. 

The result is an approach similar enough to both to easily understand and adopt — but different enough to set itself apart from other Agile frameworks.

Like the perfect cookie, Scrumban is, in the words of its ideator, Corey Ladas, “crunchy on the outside, chewy on the inside.”

Now that we’ve got you hungry for more, let’s go through our Scrumban guide to learn:

• What Scrumban is,
• How it compares to Scrum and Kanban,
• How to implement it,
• Who it’s for, and
• Which advantages and disadvantages it comes with.

Let’s begin!

What is the Scrumban methodology?

Most people define the Scrumban framework as a combination of Scrum and Kanban. However, it might be more accurate to say that Scrumban is a lot like Kanban — but with a bit more structure and predictability. 

According to The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, the focus of Scrumban is the application of Kanban systems in a Scrum context. 

In Scrumban project management, the inherent capabilities of Scrum are improved and amplified. Layering the Kanban method alongside Scrum, though, brings some new capabilities and perspectives into the spotlight.

The result is a simple-to-use, flexible, and efficient Agile framework that can be easily implemented at any organizational level. 

Still, it’s important to understand the main characteristics of both Scrum and Kanban first to fully grasp Scrumban.

Scrum vs Kanban vs Scrumban

Scrumban is a bit of a balancing act that aims to reconcile 2 opposing natures – Scrum’s rigid structure and Kanban’s flowy flexibility. 

Understanding Scrumban entails learning more about these 2 frameworks, so here, we will:

• See how Scrum and Kanban work separately,
• Find out how Scrumban combines them, and
• Learn about the key ways Scrumban differs from these 2 frameworks.

How does Scrum work?

Scrum is the most popular lightweight framework for implementing Agile values and principles. 

The framework revolves around 4 different elements:

• Sprint — a period of 2 to 4 weeks during which the Product Team focuses solely on the project tasks listed in that particular Sprint’s Backlog. Scrum restricts the amount of work per Sprint and is limited by the duration of the Sprint. This type of work system is called timeboxing.
• Scrum Team — a cohesive group of professionals that includes the Scrum Master, the Product Owner, and Developers,
• Scrum Artifacts — information nuggets and tools that represent value or work in the Scrum framework and include the Product Backlog, Product Goal, Sprint Backlog, Sprint Goal, Increment, and Definition of Done, and
• Scrum Events — formal events for inspecting and adapting Sprint Artifacts that include Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

According to the Scrum Guide, each of these elements has a specific purpose and plays a valuable role in project realization.

An expert we reached out to, Erin Joanna Thames, an efficiency and start-up consultant and the PMP-certified founder of A Climate of Change LLC, gave us an on-point description of Scrum and what it entails:

Each Sprint typically includes the following steps:

• Sprint planning and the creation of the Sprint Backlog,
• Implementation/Execution (including Daily Scrum meetings and backlog refinement),
• Sprint Review, and
• Sprint Retrospective.

Scrum doesn’t inherently require a visual aid, but the Scrum Team can use a Scrum Board to better organize their work. The simplest type consists of only 3 columns (To do, In progress, and Done), but the team can add as many columns (or rather, categories) as necessary.

Since Scrum is a popular framework, many project management tools even offer a Scrum Board template you can customize to your liking.

How does Kanban work?

Kanban is another method for implementing Agile principles, with a bit of Lean project management thrown into the mix. 

The Agile Practice Guide states that Kanban is the “original start-where-you-are method”. 

This essentially means it is rather easy to incorporate since it doesn’t require a particular setup or changing an organization’s existing processes.

The core properties of Kanban are:

• Visualize the workflow,
• Limit work in progress (WIP),
• Focus and manage the flow,
• Ensure process policies are explicit,
• Implement feedback loops, and
• Improve collaboratively. 

According to Erin Joanna Thames, Kanban seems like a solid choice for Agile project management novices:

Kanban is famous for its visual aspect — the Kanban board. These boards can be physical or digital and usually consist of the following elements:

• Visual signals, 
• Columns,
• WIP limits,
• Commitment point, and
• Delivery point.

Similar to a Scrum board, the most basic Kanban board includes 3 columns:

• To do,
• In progress, and
• Done.

How does Scrumban combine Scrum and Kanban? 

In Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas mentions how a large part of the Scrum community has overcommitted to a “narrow, prescriptive, and rigid” process. 

This is something that Jeff Sutherland, one of the creators of Scrum, would also call “Type A Scrum”, as mentioned in his paper on the future of Scrum.

To break away from Scrum’s restrictive nature, Ladas suggests it’s possible to “incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding.”

According to a paper on the integration of Scrumban in software engineering, Scrumban combines:

• Scrum’s agility of empiricism — Scrum theory is partially based on empiricism and the idea of learning from experience and reaching decisions based on observations, and
• Kanban’s transparent workflow management system — the use of Kanban boards in workflow management software enables a higher degree of visualization (and thus, transparency) in the project team.

Generally speaking, some of the Scrum elements Scrumban may include are:

1. Regular iteration planning cycles that consider work complexity,
2. Iteration reviews and retrospectives, 
3. On-demand prioritization,
4. Definition of “Ready”, and
5. The use of the “Ready” queue for further organization.

The Kanban principles and ideas we can use in Scrumban include:

1. WIP limits,
2. Visual representation of a continuous project workflow without timeboxing,
3. Pull system,
4. Just-in-time analysis and planning to accommodate shorter lead times, 
5. Project team role flexibility, 
6. Buffer columns, 
7. Kanban metrics (cycle and lead time, throughput, and Service Level Expectation), 
8. Explicit process policies (internal guidelines), and
9. Continuous improvement philosophy (Kaizen).

Which elements can you include in Scrumban?

In his book What is Scrumban?, Andrew Stellman highlights that there isn’t a precise guide to Scrumban or a certified authority that prescribes which elements give a framework the Scrumban name. 

So, since there’s no Scrumban manifesto of sorts, there may be some variations across teams trying to combine Scrum and Kanban. Each team may come up with their own blend that works for their needs and projects.  

Erin Joanna Thames also believes the key to combining PM methodologies lies in the project team itself: 

How does Scrumban differ from Scrum and Kanban? 

Scrumban may be a nice blend of Scrum and Kanban, but that doesn’t mean it’s just a copy of some of their best features. 

Arguably the main difference between Scrum and Scrumban is that the former relies heavily on Sprints — while the latter may or may not use them. 

As mentioned in an empirical study on the formation of Scrumban based on Scrum and Kanban practices, Scrumban teams can decide for themselves which practices to adopt. 

In general, Scrumban teams can do Sprints if they want. However, most of the time, they stick to short (often 2-week-long) iterations. Tasks in Scrumban can be long-running and span several iterations too.

More relaxed iterations are also Erin Joanna Thames’s favorite aspect of Scrumban:

Scrumban usually nixes story points too, which help Scrum teams decide what they’ll work on in an upcoming Sprint. Instead, Scrumban teams decide what tasks to do next based on priority.

As for Kanban, one of the major ways it differs from Scrumban is the project board. 

A Kanban board often has just 3 columns (To do, In progress, and Done). Because Scrumban also includes some Scrum features, such as the Definition of Ready, a Scrumban board is usually more extensive. The board can consist of various other columns that break down the project workflow further. 

Scrum vs Kanban vs Scrumban comparison 

Here’s a detailed comparison chart of these 3 methods to help you learn more about their similarities and differences.

Criteria	Scrum	Kanban	Scrumban
Rules	Strict	Flexible	Moderate
Teams	Cross-functional teams	Cross-functional or specialized	Cross-functional or specialized
Team roles	Specified and strict roles (Scrum Master, Product Owner, and Developers)	Service Delivery Manager and Service Request Manager (but usually no specific work roles or titles)	Undefined (teams can also keep their Scrum roles)
Iterations	Timeboxed Sprints lasting a month or less	Continuous flow	Continuous flow with short (usually 2-week-long) iterations
Ease of adoption	Somewhat challenging transition due to the rules and specific structure	Easy transition from more structured methods	Moderate depending on the level of knowledge of both Scrum and Kanban
Scope limits	The amount of work is limited to a particular Sprint	WIP task limits	WIP and To-Do task limits
Task estimation	Task estimation happens before each Sprint	No need for task estimation	No need for task estimation
Task prioritization	Tasks are prioritized before each Sprint	Daily prioritization based on the pull principle and just-in-time planning	Task prioritization usually happens during planning
Task size	Limited to what can be achieved during a Sprint	Any size	Any size
Assigning tasks	Tasks are assigned to specific team members during Backlog Refinement or Sprint Planning	Pull system (team members choose what they want to work on)	Pull system (team members choose what they want to work on)
Task timespan	Limited to the Sprint’s duration	No timespan limits	No timespan limits
Key performance metrics	Sprint burndown charts, team velocity	Throughput, cumulative flow diagram, lead and cycle time	Average lead and cycle time
Meetings and other ceremonies and events	Sprint Planning meetings, Daily Scrum, Sprint Review, and Sprint Retrospective	Does not require meetings	Daily meetings and occasional Kaizen events are encouraged, other meetings are optional and usually held on an ad-hoc basis
Adding new tasks or making changes during an iteration	Forbidden	Allowed when appropriate	Allowed when appropriate
Planning methods	Sprint planning	Release and demand planning	Bucket-size planning, on-demand/trigger planning

How to implement Scrumban?

As mentioned, there are hardly any rules or best practices to follow when implementing Scrumban. The process largely depends on the parts of Scrum and Kanban you decide to use — so the steps may look slightly different for every team.

Generally speaking, Scrumban has 4 project phases:

• Initiation,
• Planning,
• Execution, and
• Delivery and feedback. 

We’ve come up with 5 key steps you should strive to follow when implementing Scrumban:

1. Flesh out the project and the Product Backlog, 
2. Plan the Iteration Backlog,
3. Build the Scrumban board,
4. Set up WIP limits and the planning trigger, and
5. Continuously pull items and refine your workflow.

Let’s go through each in more detail.

Step #1: Flesh out the project and the Product Backlog

First things first — you start the whole Scrumban process by assessing and fleshing out the project at hand. 

You get input for the project from key project stakeholders, the executive team, users and customers. The main idea here is to find out what the project should achieve and gather all the information you can get about the project requirements.

Essentially, this is when you:

• Map out the project, 
• Nail down the fundamentals, and 
• Gather user stories. 

Once you have that, start building the Product Backlog. This is an extensive list of items that need to be completed to create the final product. Even in its basic form, the items in the Product Backlog are prioritized in some way.

You also get to build your project team now. As mentioned, predefining roles isn’t a requirement, though you can keep Scrum roles if you’re switching from Scrum to Scrumban.

While you’re here, decide on the Scrumban elements you want to use. For instance, daily meetings are greatly encouraged, but you can decide on the format.

In Scrum daily meetings, you focus on the people and what they’ve been doing. A Kanban-style daily meeting, however, might be more appropriate in Scrumban. Such a meeting focuses on the tasks and usually takes only about 15 minutes.

You can also schedule Kaizen events to discuss work process improvement and resolving issues. This type of event is optional (like most Agile meetings in Scrumban), but it can be a great learning opportunity for the team.

Retrospective meetings are also mostly optional, but again beneficial — you can hold them every 2 weeks or so, or at the end of the iteration. 

Since there aren’t any strict rules in Scrumban, you can have impromptu retrospectives too whenever necessary.

Step #2: Plan the iteration workflow

The next step involves figuring out:

• The iteration interval, and 
• What goes in the Iteration Backlog.

In Scrum, you work with the Product Backlog and Sprint Backlog. In Scrumban, the equivalent to the Sprint Backlog is called an Iteration Backlog.

The Iteration Backlog is a list of top-priority items pulled from the Product Backlog that the team is set to complete during an iteration interval. Most often, it takes the form of the “To do” column on the Scrumban board.

Similar to a Sprint in Scrum (minus the rigid structure), an iteration interval determines how long a team will work on a single set of items from the Iteration Backlog. The length of iterations in Scrumban depends on the industry and type of project — but they are usually kept short and rarely last longer than 2 weeks.

At this point, you can make an iteration schedule and hold a planning meeting for the upcoming iteration. Usually, it’s not necessary to plan the tasks for each iteration. Instead, tasks can be added to the Iteration Backlog based on priority.

The items in the Iteration Backlog are themselves prioritized, and each task thus listed should be performed in the order of priority. Besides limiting work in progress, Scrumban also limits the number of priority items in the Iteration Backlog.

The Iteration Backlog limit is determined by dividing the number of days in the iteration interval by the average cycle time.

As a simple example, if there are 10 cards in progress, and it takes 10 days on average to complete them all, the average cycle time is 1 day. If we take that the length of the interval is 2 weeks, or 10 working days, the Iteration Backlog limit is 10.

Step #3: Build the Scrumban board

Next up, it’s time to visualize the workload in a Scrumban board.

The first column in the board should be the “To do” column or “Backlog”. After that, you can add a “Ready” column. 

In Kanban and Scrumban boards, the “Ready” column contains several items from the Iteration Backlog that must be finished first. In that case, the team disregards the Iteration Backlog and always prioritizes working on the items from the “Ready” column.

The “Ready” column can be followed by an extensive Work-in-Progress section.

The WIP section of the board contains all the cards that are currently being worked on. Ideally, this section comprises multiple columns, each corresponding to a step in the given task. It should be exhaustive and make it easy for the team to follow the progress of each individual card and spot pending issues.

A Scrumban board can also contain multiple buffer columns that regulate the movement of cards on the board.

A buffer column is any column on the board that doesn’t add value to the project. None of the cards parked in buffer columns have a team member assigned to them. 

Since each column has a certain WIP limit, to start working on another card, a team member has to make room in the active column. 

They can do so by moving the card that they have completed into a mini “Done” pile, where it will wait until it’s picked up by another team.

Step #4: Set WIP limits and the planning trigger

Once you have populated the backlog and set up the Scrumban board, the next step is to set WIP limits and the planning trigger.

WIP limits are a distinctive characteristic of both Kanban and Scrumban. They are fixed constraints that prevent the team from pulling new work before finishing previously started tasks. 

The purpose of WIP limits is to increase the team’s focus by ensuring they concentrate on and complete a smaller set of tasks. In practice, this essentially means setting a limit for the number of cards that each of the WIP columns can contain.

We’ve already mentioned that you can limit the number of items found in the Iteration Backlog. Another limit you could introduce is the order point. 

Scrumban is known for relying on trigger planning — a type of planning that’s not scheduled in advance but held as needed.

The framework may lack real Sprints, but it still has planning cycles. To determine when to hold planning meetings, Corey Ladas introduced the concept of the “order point”.

The order point is a limit that triggers a planning session. Once the number of items in the “To do” column drops below the order point, it triggers an alarm that notifies the responsible parties that it’s time to add more items to the list.

Step #5: Continuously pull items and refine workflow

Throughout the Scrumban process, the team continually pulls items from the Iteration Backlog. To further refine their workflow, the team also keeps track of Scrumban metrics for future projects, such as:

• Cycle time — how many days a work item is kept “in progress”,
• Throughput — how many work items the team has finished in a set period, and
• Service Level Expectation — the historical cycle time of the Scrumban team.

Each iteration usually ends with a client review and release, during which you gather feedback and possibly even new requirements for the rest of the project. After that, the team goes back to the Product Backlog to continue working on the project.

Controlling the project scope is essential throughout the iteration, so as it comes to a close, you can implement feature freeze and triage.

Feature freeze is a reaction to a fast-approaching project deadline. Once a feature freeze is declared, no additional features can be added to the product. The team must continue working only on the features that have already been scheduled.

The project manager can also implement triage. If the team realizes that they won’t manage to develop all the scheduled features by the deadline, a triage process is performed to prioritize the scheduled features. The features deemed to be of higher priority will be developed, while the rest will be dropped.

The final step in this stage — albeit optional — is to hold a retrospective meeting. This kind of meeting would especially benefit new Scrumban teams that are still getting used to the framework. 

It gives them a chance to reflect on their processes and seek ways to improve them. At the very least, it provides a nice closure for each iteration.

Who is Scrumban for?

We’ve gone over the differences between Scrum and Kanban and how they combine to create Scrumban as a middle ground. Yet you might still be wondering when to use Scrumban — and whether it’s the right approach for your team.

If that’s the case, we have the answer.

In general, Scrumban is a great solution for teams looking for:

• More structure in Kanban project management, or
• More flexibility in Scrum project management.

A common belief is that Scrumban emerged as a helpful framework for teams transitioning from Scrum to Kanban. 

But as Andrew Stellman mentions in his book, that makes little sense because the 2 methods don’t have the same goal. Scrum deals with project management and successful product delivery, whereas Kanban is all about continuous process improvement.

Still, you can use Scrumban when:

• The project team needs more flexibility and freedom in how it works (e.g., when choosing tasks), 
• It’s necessary to ruthlessly prioritize and limit work in progress to ensure focus and actual task completion, and
• There’s a need to maintain ongoing projects, i.e., those without a definitive date of completion.

How popular is Scrumban?

The 16th State of Agile Report by Digital.ai shows Scrum and Kanban are as popular as ever, with 87% of Agile teams using Scrum while 56% are leveraging Kanban.

Unsurprisingly, their benefits — and faults — have given Scrumban a chance to stand out too. The survey marked its growth in popularity at 27%.

Interestingly enough, Scrumban focuses more on improving the workflow rather than achieving a set project goal, so it’s often used by disciplines like HR, sales, and marketing. 

In fact, according to the 2022 Annual State of Marketing Report by AgileSherpas, a whopping 61% of marketing departments follow a hybrid project management methodology or Scrumban.

Here’s how a marketing department could use task management software like Plaky to create a Scrumban social media calendar board:

If you’re still unsure whether you should use it, the following list of Scrumban’s pros and cons might help you make up your mind.

Scrumban advantages  

Scrumban inevitably becomes a more appealing option when just using Scrum or Kanban isn’t working out. Some of the key benefits we want to focus on here, though, are that Scrumban:

• Allows for effortless implementation, 
• Saves time,
• Makes it easy to spot bottlenecks, 
• Enables long-term planning, 
• Facilitates greater focus to bring better-quality results,
• Handles large projects with ease, and
• Keeps everyone in the loop.   

Advantage #1: Scrumban allows for effortless implementation

Scrumban inherited a large portion of its identity from Kanban. Thus, it should be no surprise that it’s equally easy to adopt.

Much like Kanban, Scrumban doesn’t have many hard and fast rules, allowing for an easier implementation. 

You can also implement it gradually. This would allow your team to get up to speed with the Scrumban way of work on their own without much pressure.

The expert we talked to, Erin Joanna Thames, described how she uses Scrumban when working with clients:

She shared with us a real-world example of what this process looks like:

Scrumban is also rather easy to implement because it doesn’t require any change in existing roles within the project team. Scrumban forgoes Scrum’s idea of predetermined roles, and it doesn’t pre-assign the tasks. 

Instead, Scrumban teams are largely flexible and self-managing — they pull tasks from the Iteration Backlog on their own and work autonomously toward the end goal.

Advantage #2: Scrumban saves time

Due to its tendency to strive toward Lean, Scrumban allows for work and planning to be done in a minimalistic fashion — only when necessary and for no longer than necessary. 

In the grand scheme of things, setting an order point for trigger planning essentially allows Scrumban teams to shave off a lot of time from planning sessions, estimations, and resolving bottlenecks. Apart from saving time, this also encourages better results and efficiency since the team then has more time to focus properly on the actual tasks. 

Advantage #3: Scrumban makes it easy to spot bottlenecks

Bottlenecks are a major issue if left unattended, as they can easily slow down or prevent progress throughout the project. Luckily, the visual aspect of Scrumban allows teams to spot any potential or ongoing problems on the board in time and immediately take action. 

Not all issues can be resolved that easily — just because you’re using Scrumban doesn’t mean extensive roadblocks won’t ever jeopardize the project. 

Proper risk management would still help immensely to ensure project success. This aspect of Scrumban, though, certainly saves a lot of time in identifying issues and allows more time for effective troubleshooting. 

Advantage #4: Scrumban enables long-term planning 

Though Scrumban nurtures on-demand planning, it’s also partial to enabling long-term planning. 

When using this framework, teams can rely on bucket-size planning to further classify the Product Backlog according to priority. 

This technique entails visualizing 3 buckets of time. Usually, they’re called a:

• 1-year bucket,
• 6-month bucket, and
• 3-month bucket.

The 1-year bucket contains long-term goals. They sit in the 1-year bucket until the team thinks it’s time to start fleshing them out.

They are then moved to the 6-month bucket where the goals are defined in more detail. 

Once it’s almost time to start working on them, these goals are transferred to the 3-month bucket. There, they are further divided into manageable tasks that can eventually be transferred to the board as items in the Iteration Backlog. 

Advantage #5: Scrumban facilitates greater focus to bring better-quality results

Scrumban’s WIP limits force each team member to work on one item at a time and finish it before moving on to the next one. However, the benefit of this is even greater if we consider how bad multitasking often is.

The idea behind WIP limits is to prevent juggling multiple tasks at a time. Instead, it encourages the team to focus on each task and give it as much attention as it deserves — without any distractions.

Because of trigger planning, the backlog doesn’t get updated as often, forcing team members to work on fewer tasks with more focus. Thanks to WIP limits, multitasking is kept to a minimum too, as team members cannot hoard tasks. 

Given the detrimental effects of task switching — e.g., reduced accuracy and speed — a lack of multitasking actually contributes to greater focus and better-quality results in Scrumban.

A key part of all this is the pull system. The pull system allows cards to move into the next column only when there’s an available spot in that column.

Queues in front of stores during the pandemic might be an adequate analogy for this. If only 5 people are allowed in the store and 5 people are already inside, the next person that wants to enter can do so only when someone leaves the store.

This system is made possible by:

• The WIP limits, and 
• The flexible nature of Scrumban teams, which allows team members to choose the cards they will work on as the need arises.

Advantage #6: Scrumban handles large projects with ease

The visual nature of Scrumban and its iterative approach to project management allow Scrumban teams to manage gargantuan projects with relative ease and in a much more organized fashion. 

Moreover, Scrumban can accommodate a large number of team members, and a Scrumban board can have as many columns and cards as necessary. 

Scrumban borrows another feature from Kanban to enhance the workflow further, especially in larger projects and teams — swimlanes.

Swimlanes are horizontal lines that separate the board into sections to classify work items into different groups. So, you can have separate swimlanes for:

• Different departments, teams, and clients,
• Types of services,
• Urgent tasks,
• Repetitive tasks,
• Project steps or phases, etc.

Swimlanes help enhance workload management and organization. Essentially, they provide a much better insight into the tasks based on certain criteria.

Combined with typical columns on a Kanban board, they create a grid that makes it easier to visualize the life cycle of tasks and track their progress.

Swimlanes are especially useful in large teams where the sheer number of tasks can get overwhelming. In these cases, swimlanes help:

• Make sense of the board, 
• Find the exact card you’re looking for, and 
• Spot issues fast.

Advantage #7: Scrumban keeps everyone in the loop

Having a clean visual representation of the team’s progress is paramount for successful project management since it fosters transparency and helps keep everyone on the same page.

This is especially important when managing remote teams.

The use of Scrumban in remote teams was tested in an empirical study on Scrumban’s impact on geographically distributed software development. The aim of the study was to learn how Scrumban would influence the performance of 2 software development teams from Italy and Finland. 

The researchers claimed that “geographically distributed teams with poorly planned coordination often end up with unmatched deadlines, costs overrun, and even canceled projects”. 

However, they found that using Scrumban helped alleviate some of the major challenges of remote teams, such as:

• Team synchronization,
• Culture, 
• Communication, and 
• Leveraging resources.

They further listed a more frequent use of synchronous communication and functional knowledge-sharing infrastructure as crucial in coordinating remote teams.

To achieve this, you need sophisticated project management tools like Plaky, which allow for fast correspondence and quick and safe file-sharing capabilities.

Scrumban disadvantages

Scrumban seems to have taken the best of both worlds and created a superb combo by merging Agile and Lean into an effective framework.

But, as nothing in this world is perfect, neither is Scrumban. Some of its most prominent disadvantages are that it:

• Can get out of control,
• Makes it difficult to determine individual efforts, and
• Reduces the project manager’s role.

Disadvantage #1: Scrumban can get out of control

Since it’s a relatively new approach to project management defined as a hybrid between Scrum and Kanban, people can sometimes see it as open to interpretation.

Scrumban is not a rigid framework by any means. Like Kanban, it doesn’t have a predefined set of best practices to follow.

However, Scrumban doesn’t entail picking and choosing arbitrary elements of Scrum and Kanban and mushing them together, let alone inventing new ones. 

As Andrew Stellman puts it, “for a Scrumban implementation to have integrity, it must preserve the empirical process control of Scrum while at the same time implementing a Kanban pull system.”

The general lack of understanding of Scrumban can lead to confused teams following something they think is Scrumban, but is actually a slightly modified version of Scrum. Worse, it may even be something that doesn’t fit any of the 3 frameworks mentioned above.

Disadvantage #2: Scrumban makes it difficult to determine individual efforts

Scrumban gives each team member more independence by letting them choose the exact tasks they want to work on. However, the team’s autonomy can lead to lots of confusion when determining each individual’s efforts. 

In a Scrumban system, cards are flying across the board and dozens of team members are working on them at any given time. This makes it nearly impossible to keep track of who is doing what — and evaluate their efforts.

Besides that, meetings are scarce, and pre-assigning cards is a no-go. In the long term, this makes keeping track of the progress of individual members even more difficult.

Disadvantage #3: Scrumban reduces the project manager’s role

Finally, note that Scrumban doesn’t put much emphasis on project managers, their project management skills, or their ability to control their teams.

Scrumban doesn’t prescribe any specific roles, so there isn’t an exact hierarchy to keep track of in such a system. What’s more, each team member can choose the tasks they feel like doing and that they specialize in.

This kind of autonomy doesn’t go well with a control-obsessed project manager. A project manager who wants to use Scrumban has to accept the fact that their influence on the team will be diminished.

Granted, the project manager has control over long-term project management plans. However, once the tasks become available to be worked on, their role is drastically reduced — they don’t have to be hands-on at all.  

Conclusion: Scrumban combines the best of Scrum and Kanban

Some of the most appealing features of Scrumban include a lack of rigid rules and a team hierarchy. The framework essentially gives the project team more freedom to do great work and choose the tasks according to their specialization. 

At its core, Scrumban is the middle ground between 2 rather popular Agile project management approaches. However, since there are no prescribed practices or exact methods for combining Scrum and Kanban — each team’s version is likely to be unique in its own way.

📖 You find Scrumban useful, but would like to expand your knowledge on project management? Check out our Project Management Glossary of Terms to get familiar with project management terminology.

References

• Reddy, A. (2016). The Scrumban Revolution: Getting the Most Out of Agile, Scrum, and Lean Kanban. Addison-Wesley. https://www.goodreads.com/en/book/show/25953144
• The Complete Guide to Timeboxing. Clockify. (2017, September 1). Retrieved May 3, 2023 from https://clockify.me/timeboxing
• The 2020 Scrum Guide™. Scrum Guides. (n.d.). Retrieved May 3, 2023, from https://scrumguides.org/scrum-guide.html
• Crail, C. (2022, October 19). What Is A Scrum Board? Should You Make One?. Forbes. Retrieved May 3, 2023 from https://www.forbes.com/advisor/business/what-is-a-scrum-board/
• Project Management Institute. (2017). Agile Practice Guide. https://www.goodreads.com/book/show/34525224-agile-practice-guide
• Ladas, C. (2008). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. https://www.goodreads.com/book/show/6117571-scrumban
• Sutherland, J. (n.d.). Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. Retrieved May 10, 2023 from https://www.scruminc.com/wp-content/uploads/2014/05/Parallel-Pipelining-of-Sprints-in-Complex-Projects.pdf
• Bhavsar, K., Shah, V., & Gopalan, S. (2020). Scrumban: An Agile Integration of Scrum and Kanban in Software Engineering. International Journal of Innovative Technology and Exploring Engineering, 9(4), 1626–1634. https://doi.org/10.35940/ijitee.d1566.029420
• Stellman, A. (2019). What is Scrumban? O’Reilly Media, Inc. https://www.goodreads.com/book/show/60496765-what-is-scrumban
• Alqudah, M., & Razali, R. (2018). An Empirical Study of Scrumban Formation based on the Selection of Scrum and Kanban Practices . International Journal on Advanced Science, Engineering and Information Technology, 8(6), 2315–2322. https://doi.org/10.18517/ijaseit.8.6.6566
• 16th State of Agile Report. Digital.ai. (n.d.). Retrieved May 3, 2023 from https://info.digital.ai/rs/981-LQX-968/images/AR-SA-2022-16th-Annual-State-Of-Agile-Report.pdf
• Annual State of Agile Marketing Report 2022. Agile Business Consortium. (n.d.). Retrieved May 3, 2023 from https://www.agilebusiness.org/resource/blog-annual-state-of-agile-marketing-report-2022.html
• Madore, K. P., &Wagner, A. D. (2019, April 1). Multicosts of Multitasking. National Center for Biotechnology Information. Retrieved May 3, 2023 from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7075496/
• Banijamali, A., Dawadi, R., Ahmad, M. O., Similä, J., Oivo, M., & Liukkunen, K. (2016). An Empirical Study on the Impact of Scrumban on Geographically Distributed Software Development . Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development. https://doi.org/10.5220/0005686405670577