What is Scrumban project management?

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. It creates something similar enough to both to be easy to understand and adopt, but different enough to draw people in.

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

Now that we’ve got you hungry for more, it’s time to learn all about what Scrumban is, who it’s for, why people use it, and why you should too.

What is Scrumban?

While most will define Scrumban as a combination of Scrum and Kanban, it might be more accurate to say that Scrumban is simply Kanban with a bit of structure. 

Another way is to see it as a pathway whose starting point is Scrum and the end goal is Kanban.

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

How does Scrum work?

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

Scrum’s defining feature is the Sprint — a period of two to four weeks during which the product team is focused solely on the tasks listed in that particular Sprint’s backlog. Sort of like cramming for an exam. According to the Scrum Guide, no changes can be made to the Sprint that might endanger the original Sprint Goal.

A Sprint begins with a Sprint planning session where the team decides what will go into the Sprint Backlog — a list of high-priority items that are pulled from the Product Backlog and should be completed by the end of the Sprint.

Once the development team starts working on the items from the Sprint backlog, they hold 15- minute Daily Scrum meetings where the team explains what they’re working on and how their work is progressing.

The Sprint ends with a Sprint review — a product-focused meeting where the team explains what they worked on during the Sprint. 

This stage is followed by the Sprint retrospective — a process-focused meeting where the team reflects on the manner in which the work was performed, and suggests ways to improve it.

Scrum doesn’t inherently require a visual aid for organizing work. However, Scrum teams will often use something called an Agile board or a Scrum board — sometimes even called a Kanban board due to its similarity.

A Scrum board typically has three types of columns:

1. To do (contains the Sprint backlog items),
2. In progress (can be divided into several more specific columns as needed), and
3. Done. 

It’s important to keep in mind that 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.

How does Kanban work?

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

Kanban’s main characteristics are that it:

1. Visualizes the work,
2. Limits work-in-progress (WIP),
3. Focuses on flow, and
4. Strives for continuous improvement.

Typically, people recognize Kanban by its visual aspect — the Kanban board.

However, Kanban’s defining feature is actually imposing work-in-progress (WIP) limitations.

As the founder of Scrumban once said: “A task card without a limit is not a kanban in the same way that a photocopy of a dollar bill is not money.”

If we were to compare Kanban to Scrum, it would look something like this:

Scrum	Kanban
– Pulls the highest priority items from the Product backlog, and – Transfers them into a Sprint backlog, limiting the work per Sprint.  – The items from the Sprint backlog are placed in the “to do” column, – Team members are assigned cards, and – The work begins.	– Pulls high-priority items directly from the Product backlog as needed, – Limits the number of cards per column, and – Does away with Sprints, allowing the cards on the board to stay in perpetual motion.

Kanban’s focus on imposing WIP limitations forces team members to work on only one item at a time, eliminating multitasking and sharpening their focus. 

This kind of system is called a “pull” system. As opposed to a “push” system that pushes finished items into the next column — leading to pileups and bottlenecks — in a pull system, a card is allowed to leave one column only when an available slot appears in the next one.

To avoid bottlenecks, Kanban boards often have multiple buffer columns. They function sort of like “parking lots” for the cards that have been finished by one team and are waiting to be picked up by another. 

How does Scrumban work?

When Corey Ladas first introduced Scrumban, he claimed that Scrum was “narrow, prescriptive, and rigid”.

To break away from its limited 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.”

The “vestigial scaffolding” that remains from Scrum includes the following:

1. Iteration reviews and retrospectives,
2. Planning cycles, and
3. Prioritization of backlog items.

Everything else comes from Kanban:

1. WIP limitations,
2. Continuous workflow without timeboxing (no Sprints),
3. Pull system,
4. The flexibility of roles on the team,
5. Buffer columns, and
6. Calculating cycle times as a primary measure of performance.

In addition to the combination of characteristics mentioned above, two other important things make Scrumban unique — trigger planning and swimlanes.

What is trigger planning in Scrumban?

Since there are no Sprints as such in Scrumban — but there are planning cycles — there has to be another way to determine when to hold planning meetings. 

But, before we explain how that’s done, we must first introduce some background info.

Besides limiting the work-in-progress, Scrumban also limits the number of priority items in the iteration backlog (“to do” column). 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 two weeks, or 10 working days, the Iteration backlog limit is 10.

The 10 items that are selected for the “to do” column are the 10 top-priority items from the product backlog. 

Now let’s get back to trigger planning.

Since the “to do” column is now limited to 10 items, what happens when those items are all completed?

Answer: There is a pause in the workflow. 

But, a pause in the workflow is not allowed to happen. 

To avoid this scenario, the team puts another limit on the “to do” column that Ladas calls the “order point”.

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. In order words, it triggers a planning session.

The goal of trigger planning is to make both the iteration limit and the order point as low as possible, pushing toward a more Lean structure.

What are swimlanes in Scrumban?

Swimlanes in Scrumban are horizontal lanes used to group tasks together based on common characteristics such as the following: 

• The department they’re assigned to, 
• Levels of task priority, 
• Phases of the work process,
• The people responsible for the tasks, etc. 

The number, purpose, and naming of the swimlanes, depend entirely on how the team decides to organize their work.

On a physical Kanban board, swimlanes can be represented as simple horizontal lines. Combined with typical columns on a Kanban board, they create a grid that makes it easier to visualize the lifecycle 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.

Useful terms for Scrumban users

Each project management methodology and framework has its own list of terms and phrases you must learn to properly navigate the project within its boundaries.

Below is an extensive list of terms used in Scrumban, together with their definitions in the context of this framework, as opposed to similar terms in Scrum or Kanban.

Product backlog

A product backlog is an extensive list of all the items that need to be completed to create the final product.

Not to be confused with Scrum backlog or iteration backlog. 

Even in its basic form, the items in the Product Backlog are prioritized in some way. 

Bucket size planning

We mentioned before that, even in its basic form, the product backlog is prioritized in a certain way. This is where bucket size planning comes in. 

Bucket size planning is a manner of long-term planning in Scrumban.

It can be visualized as three buckets. Usually, they’re called a:

1. 1-year bucket,
2. 6-month bucket, and
3. 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 and divided into manageable tasks that can eventually be transferred to the board as items in the iteration backlog.

Iteration backlog

An iteration backlog is a list of top-priority items pulled from the product backlog that the team is set to complete during one iteration interval. 

The items in the Iteration Backlog are themselves prioritized, and each task thus listed should be performed in their order of priority.

The iteration backlog, otherwise known as a “to do” column, is usually the first column on the board.

“Ready” column

Although the Iteration Backlog is already a prioritized list of items, Kanban and Scrumban boards often have another column, often called “Ready”.

This column contains several items from the iteration backlog that must be finished first. 

In cases where a “Ready” column exists, the team disregards the iteration backlog and always prioritizes working on the items from the “Ready” column.

Work-in-progress (WIP)

The work-in-progress is a section of the board that contains all the cards that are currently being worked on.

Ideally, this section contains multiple columns, each corresponding to one step in the given task. 

The work-in-progress section should be exhaustive and make it easy for the team to follow the progress of each individual card and spot pending issues.

The work-in-progress section contains multiple buffer columns and work-in-progress (WIP) limits for each column that regulate the movement of cards on the board.

WIP limit

A WIP limit is a distinctive characteristic of both Kanban and Scrumban.

It represents a limit to the number of cards that each of the work-in-progress columns can contain.

This limitation forces each member of the team to work on only one item at a time and finish it before moving on to the next one.

Buffer column

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.

Team

A team is a group of people working together toward a common goal.

In Scrumban, just as in Kanban, there is no limit to the number of people in a team. 

Scrumban teams are flexible and don’t require any rearrangement after the adoption of Scrumban. 

Scrumban teams are largely self-managing. There are no predetermined roles or pre-assigned tasks. Each team member chooses the items they will work on next.

Iteration interval

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 two weeks.

Trigger planning

Trigger planning is the type of planning that’s not scheduled in advance but held as needed.

When the number of cards in the “to do” column falls under a predetermined threshold in Scrumban, it acts as a trigger for the next planning session.

The pull

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 five people are allowed in the store and five people are already inside, the next person that wants to enter can do so only when one of the people inside leaves the store.

This system is made possible by: 

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

Feature freeze

Feature freeze is an emergency 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.

Triage

If the team realizes that they won’t manage to develop all of the features that had been scheduled by the end of the deadline, a triage process is performed to prioritize the scheduled features. The features deemed to be of higher priority will be developed, the rest will be dropped.

Who is Scrumban for?

Now that you know the main differences between Scrum and Kanban and how the two frameworks combine to create Scrumban as a middle ground, you might be wondering whether it’s the right approach for you and your team.

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

Scrumban is a great solution for teams that are looking to introduce a smidge of structure to their Kanban project management, or for teams looking for a slow transition from Scrum to Kanban.

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

Scrumban disadvantages

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

But, as nothing in this world is perfect, neither is Scrumban. So, here are some of the more prominent disadvantages of Scrumban.

Scrumban can get out of control

Since it’s a relatively new approach to project management that’s 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, and, 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.

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 — or even something that doesn’t fit any of the three frameworks mentioned above.

It can be difficult to determine individual efforts

In a system where cards are flying across the board and dozens of team members are working on them at any one time, it’s nearly impossible to keep track of who is doing what.

The lack of daily standup meetings and pre-assigned cards makes keeping track of the progress of individual members even more difficult.

Traditional boards can be difficult to manage

Although many old-school Scrum Masters and Agile Coaches prefer having a physical board in the office that everyone can see and modify, this kind of organizational system is far from optimal.

A simple mistake or oversight can cause a lot of issues. Some of the issues may include:

• Forgetting to move the card into a different column, 
• Not noticing when someone has moved their card into another column, and
• Even something as silly as a post-it note falling to the ground and getting lost.

A much more organized way of visually managing a Scrumban board is by using a project management software with the option for a Kanban view, such as Plaky.

Project management software allows you to follow the cards that are important to you or unfollow those that aren’t. It automatically lets you know when any changes are made to the cards relevant to you and offers a clean layout where cards cannot be lost or forgotten. 

Not to mention that digital cards offer much more room for providing details related to the item than a simple post-it note.

Scrumban advantages

Now that we have the drawbacks of Scrumban out of the way, let’s talk about all the good stuff this framework has to offer — i.e. the advantages of Scrumban.

Saves time

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

This approach allows Scrumban teams to shave off a lot of time from planning sessions, estimations, and resolving bottlenecks.

Easy to spot bottlenecks

Speaking of bottlenecks, the visual aspect of Scrumban allows teams to easily spot any potential or ongoing problems on the board and immediately take action. 

While not all issues can be resolved that easily, this certainly saves a lot of time in identifying them and allows more time for effective troubleshooting.

Easy to implement

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

Like Kanban, Scrumban 

• doesn’t require any change in existing roles within the project team, 
• doesn’t have many hard and fast rules that need to be followed, and 
• can be implemented gradually.

Great for handling large projects

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. 

This might prove more challenging than it sounds in analog environments where space is scarce.

However, project management tools such as Plaky allow for unlimited users and unlimited projects that can be easily managed from anywhere in the world.

Keeps everyone in the loop

Having a clean visual representation of the progress the team is making is paramount in successful project management. It fosters transparency and helps keep everyone on the same page.

This is especially important when managing remote teams.

The application of Scrumban in remote teams was tested in a 2016 empirical research. The aim of the study was to learn how Scrumban would influence the performance of two 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”, but 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.

Needless to say, this requires sophisticated project management tools that allow for fast correspondence and quick and safe file-sharing capabilities.

Conclusion: Scrumban combines the best of Scrum and Kanban

As the middle ground between the two most popular Agile project management approaches, Scrumban manages to combine the rigid scaffolding of Scrum with the flexibility of Kanban to create its own unique path. 

Scrumban is a good fit for anyone looking to transition from Scrum to Kanban or introduce a bit of structure into their Kanban practice.

Thanks to its Kanban roots, Scrumban is easy to adopt and implement in any environment, be it in-office or remote, and quickly gets under the skin of anyone who tries it.  

References

• Banijamali, A. et al. (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, 567-577. doi: 10.5220/0005686405670577    
• Ladas, C. (2008). Scrumban and other essays on Kanban systems for Lean software development. Modus Cooperandi Press. 
• Scrum.org. (2020). The Scrum Guide. Retrieved April 5, 2022, from https://scrumguides.org/scrum-guide.html#sprint-retrospective