What is Scrumban?

Scrumban is a hybrid Agile framework that combines Scrum and Kanban. It was originally designed as a transition step from Scrum to Kanban but has since been used as a standalone framework.

An all-inclusive overview of the Framework, Practices & Tools

While most Agile practitioners are familiar with Scrum and Kanban, fewer are versed in the mix of the two – Scrumban. An in-between framework that aims to bring the best of both worlds together. Which parts of both approaches does it take? And how can they work together? You will find all of this and more information below. 

Curious to learn more about Scrumban boards? Here are 5 examples to get you started!

Beginning of Scrumban

There is no talking about the history of Scrumban before mentioning how Scrum and Kanban became associated with Agile. Both Scrumban parent frameworks were introduced into managing software development teams for effectiveness and the creation of value. 

Jeff Sutherland and Ken Schwaber first introduced the Scrum process in 1995 as a way to run small effective teams. In 2001 the Agile Manifesto was released, defining the 4 values and 12 principles all Agile applications should follow. And the number of teams using Scrum as their main Agile approach started to grow.  

Then, in 2004 David J. Anderson suggested applying Kanban practices to software development projects. The approach has already proven to be valuable in manufacturing and the same practices were now being applied to delivering software. Kanban offered a visual task board to control the process, identify bottlenecks and provide a constant flow of work. 

Teams that previously used Scrum, became more and more interested in Kanban, as it offered a less constrained process and more flexibility. And this is where the first talks of the Scrumban process first happened. It was proposed that teams transitioning from Scrum to Kanban will need an in-between method. To accommodate this need, Scrumban was created.  

Scrumban was meant to be a stepping stone between the two practices, but it soon became clear that it is good enough to be a separate Agile framework. It offered a sweet middle spot between Scrum and Kanban and thus stayed as another option for Agile practitioners. Keep reading to learn more or grab your copy of the ultimate Scrumban guide.

What is Scrumban?

Scrumban is a methodology that combines the iteration-based structure of Scrum with a focus on the work in progress of Kanban. To understand how Scrumban methodology works, you should first get to know at least a little bit about its origins – Scrum and Kanban. Both these frameworks are similar in some ways, but at the same time very different. 

Scrum is an Agile framework that runs projects in 1-4-week iterations called Sprints. Teams plan, deliver, and review work in these increments while performing strictly scheduled meetings to ensure continuous improvement. 

Kanban on the other hand is not much of a framework, but more of an approach to deliver just what is needed, focusing on a limited amount of work at all times. The team plans and reviews work based on demand and does not go by any specific roles or meetings.  

A great medium

So how do these two work together? Scrumban methodology uses the iteration and meeting structure of Scrum and visualizes work on the Kanban board. Keeping both the order and the flexibility of the two frameworks.  

Scrum, Kanban, and Scrumban were first introduced as better ways to deliver software. However, since then these frameworks proved to not only be applicable, but beneficial in many other fields where there is a need for a structured, yet clear process. 

How do Scrumban Projects Run? 

While it is easy to say understand a mixture of the two most popular Agile approaches on paper, implementing it practically can be quite challenging. To make sure everything is crystal clear, let’s overview the roles, tools, and practices that Scrumban projects use. This way understand all the elements it is composed of. 

The Roles

If you are coming to Scrumban from Scrum, there may be an expectation for certain roles. However, this is where the Kanban approach to professional teams takes over. While the team can choose to keep their previous Scrum roles, there is no requirement for a Product Owner or a Scrum Master. 

Instead, the Scrumban team should be a set of professionals capable of pulling tasks from the backlog and completing them on their own. In fact, if you have a working team structure, there is no need to change it. Simply reinforce the roles you have and make sure the team can work autonomously towards the end goal. 

The Tools

To organize and monitor the process the Scrumban methodology uses certain tools – a Scrumban board with WIP limits, task cards, and lead cycle time. All of these are created to help visualize and control the process so that it delivers the most value. 

Scrumban Board 

First, let’s figure out what is Scrumban board. Borrowing from Kanban, the main goal of this board is to visualize the whole process of tasks. Flowing from left to right, each task’s lifecycle is monitored as it goes from initial planning to being finished.  

Each Scrumban board is composed out of 3 main sections that the team can modify according to their needs. 

Backlog

First, Backlog holds all the planned tasks, that are prioritized according to importance. This can be a single column or a block of several columns that are used to divide and prioritize tasks. Team members pull tasks from this section as there is availability in the WIP. 

Work in Progress

Second, the Progress section visualizes how tasks move through the process steps. This is usually the largest section composed out of as many columns as needed to visualize the full process. The goal of the team here is not to have a simple board, but to have a board that represents the full lifecycle of each task. Making it easy to track progress. The progress section is controlled by a WIP limit, making sure the team only works on one task per person. 

Done

Third, the Done section holds all the finished project tasks. Allowing easy access to information throughout the project and visualizing the amount of work done. You can see this in a Scrumban board example from Teamhood above.

Scrumban WIP Limits 

To ensure a steady flow of work, Scrumban also uses WIP to limit the number of tasks the team can pull into the progress columns. This number differs from team to team, but a good rule of thumb is to allow one task per team member. 

Restricting work items in this way ensures each task is finished before a new one is taken on. This gives the team an opportunity to easily spot and solve issues immediately. It also guarantees a constant flow of work and gives a better chance for project estimations.  Learn more about WIP limits.

Scrumban Tasks 

Scrumban methodology does not provide a specific format for tasks, however, it works better if all the tasks are of a similar size. Since the framework measures lead and cycle time, having similarly sized tasks allows for better usage of these metrics. 

This way the team can calculate velocity and estimate how much time it will take to develop new features and complete the project. 

Scrumban metrics Lead & Cycle Time 

The last tool Scrumban framework uses is Lead and Cycle time. Borrowing the metrics from Kanban, it measures how much time on average it takes the team members to complete each task. Lead time calculates this from when a task is added to the backlog. Cycle time measures this period from when a team member pulls a task into the progress section. 

If a team is using similarly sized tasks, these metrics are quite useful for estimation. A sudden growth in lead and cycle times can also mean issues or bottlenecks that must be solved. Giving real-time insight into the project. 

Here is more on lead and cycle time. 

The Practices

As you are now familiar with the roles and tools, let’s see what running a Scrumban project looks like. The framework organizes work in 1-4-week planned iterations that are synced with reviews and retrospectives. However, there are no daily meetings, and planning is always done on demand. 

Scrumban Iterations and Scrumban Meetings

While the rule is 1-4 weeks, most Scrumban teams keep their iterations short (under 2 weeks). This allows for a quicker reaction time and lesser issues coming up. Similar to Scrum, once an iteration has begun it has to be carried out to completion. However, the team does not have to plan tasks for each iteration and simply pull tasks from the Backlog based on priority. Scrumban iterations also include Scrumban ceremonies, which you will find listed below.

There are three events that can happen during each iteration. One of them only occurs as the planning trigger goes off and thus may not happen for a few iterations in a row. 

Scrumban Planning 

Scrumban uses planning on demand. This means there is a planning trigger that monitors how many tasks there are left in the backlog. Once the number of tasks falls below a certain number, the planning meeting is held and new tasks are added to the backlog. 

There are several strategies the team can follow during the planning meetings. Knowing team velocity (how many tasks are finished during an iteration) and how often the requirements change, they can set the planning trigger to go off after every iteration or less often. This is up to the team to determine what works best for their process. Leaving the possibility to plan frequently or less often. 

Learn more details about Scrumban planning practices from the ultimate guide.

Scrumban Iteration Review 

As the daily meetings are optional in Scrumban methodology, the next event that happens in each iteration is the Review. Once the iteration is over, the Scrumban team presents the finished work to the clients. The goal here is to test out the result and gather comments to improve results in the next cycle. 

Similar to Scrum, there is no need for the whole team to participate. Only one or a few representatives are sent. It is also common for a project manager to be part of this Scrumban meeting to help communicate and set future goals. 

Scrumban Iteration Retrospective 

Lastly, before a new cycle, the whole team sits down in a Retrospective. Just like in Scrum, this Scrumban meeting is there to facilitate team communication and process improvement. Team members bring up and discuss process issues that were prominent during the iteration. Ideally, the retrospective should end with at least one actionable item for the next iteration. 

Usually, a template for retrospectives is used. There are two most common Scrumban retrospectives templates: STAR and Agile classic. STAR template suggests that team members discuss the following topics:

1 – What should we start doing?

2 – What should we stop doing?

3 – What should we Do more of?

4 – What should we Do less of?

5 What should we continue doing?

Classical Agile retrospective template is simpler and offers to discuss only three topics instead:

1 – What went well during the last iteration?

2 What could have been better during the last iteration?

3 – What actions should we take to improve in the next iteration?

If done on a recurring basis, that results in gradually improving the project process. 

Long term planning 

One big addition Scrumban users can enjoy compared to Scrum and Kanban is the ability to plan long-term. Instead of only focusing on the current situation, this framework gives a way for the users to create a vision and goals. The practice is called – Bucket size planning. 

The idea here is simple – the team creates 4 separate buckets to plan out their goals.  

1-year bucket – for large loosely defined goals that a team wants to reach within a year. 

6-month bucket – for goals that are getting ready to be implemented. Goals are moved to this bucket and become little more defined plans to be achieved. 

3-month bucket – for plans that are almost ready to go. Plans are moved to this bucket as the team is getting ready to implement them. Adding more details and performing necessary steps like the analysis. 

Current bucket – for tasks that the team will be implementing next. As a plan is ready to go forth, the team moves it to this bucket and divides it into clear tasks to be completed. 

Bucket-size planning creates a system where Scrumban teams can draw a roadmap for their future. It is also great for on-demand planning as the team can draw tasks from the current bucket straight into the backlog supplementing them with additional items that came up in Iteration Review.  Try out Teamhood to create your Bucket size planning board for free.

Differences between Scrum, Kanban, and Scrumban

Scrumban merges aspects from Scrum and Kanban, making them work together in a hybrid approach. Using the structure of Scrum, adds in features of Kanban, making it more flexible and responsive to change. Created to become a stepping stone for Scrum users wanting to use Kanban, Scrumban has become a standalone framework great for fast-paced and ever-changing projects.

Contrary to Scrum which is best for long-term projects, Scrumban can easily handle and respond to change. At the same time, contrary to Kanban, it has more structure and clearly measured iterations which helps control and predict the output of the team. Being the merge of the two, it may be more difficult to understand at first but quickly becomes natural for everyone involved.

If you are curious to find out more about the differences between the three frameworks, read my post on Scrum vs Kanban vs Scrumban.

Scrumban Software

With the growing popularity of various Agile frameworks, more and more project management tools offer the ability to use Agile methodologies. Scrumban is no exception and now there is a variety of options for teams to choose from. Such tools allow for managing projects more easily and quickly as well as getting additional insights into the process and avoiding having to hold project information in various places.

If you set out to pick a Scrumban tool, look for one that is easily modifiable and can serve your needs not only now, but also in the future. A solution like Teamhood will offer you all the traditional Agile features as well as other project management tools like a Gantt chart and Project Portfolio management. Check this video to look into how Kanban boards work in Teamhood.

And now it is time to get Scrumban into practice. Create your Scrumban board in Teamhood and see for yourself if this framework fits your needs! You can check out these 5 Scrumban board examples to help get you started.

Summary 

Scrumban methodology started out as a way for Scrum users to step into practicing Kanban. However, over time, it proved to be a better alternative and thus Scrumban became a framework on its own. 

While Scrum and Kanban are still more popular amongst Agile practitioners, Scrumban has its own users. It is great for those who need some structure, but do not want to be overwhelmed with ceremonies. As well as for those that want to clearly visualize their process and track tasks through completion. 

Scrumban works best for projects with unclear and changing priorities. It can assist projects that are driven by events, like the helpdesk. It is also good for teams that focus on adding features and supporting an existing product. Still, wondering if it is the right choice for you? See this comparison of Kanban vs Scrum vs Scrumban or check out the Scrumban Ultimate Guide pdf to get all your questions answered.

This was a long read. To memorize the most important terminology and principles of Scrumban, we have built a Scrumban Cheat Sheet for you!