While most Agile practitioners are familiar with Scrum and Kanban, less 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.
There is no talking about the history of Scrumban before mentioning how Scrum and Kanban became associated with Agile. Both of Scrumban parent frameworks were introduced into managing software development teams for effectiveness and 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 Scrumban 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 steppingstone 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.
To understand how Scrumban 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. The 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 limited amount of work at all times. The team plans and reviews work based on demand and do not go by any specific roles or meetings.
So how do these two work together? Scrumban 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 a better way 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.
While it is easy to say that Scrumban is a mixture of the two most popular Agile approaches, understanding what this means is a little different. To make sure everything is crystal clear, lets overview the roles, tools and practices that Scrumban projects use. This way understanding all the elements it is composed of.
If you are coming to Scrumban from Scrum, there may be an expectation for certain roles. However, this is where Kanban approach of 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 finishing them to completion. 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.
To organize and monitor the process the framework 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 to make sure it delivers the most value.
First up, is the Scrumban board. Borrowing from Kanban, the main goal of this board is to visualize the whole process for the tasks. Flowing from left to right, each tasks lifecycle is monitored as it goes from initial planning to being done.
Each Scrumban board is composed out of 3 main sections that the team can modify according to their needs.
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.
Second, Progress section visualizes how tasks move through the progress 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.
Third, Done section holds all the finished project tasks. Allowing easy access to information throughout the project and visualizing the amount of work done.
Here is a Scrumban board example in Teamhood.
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 allowing 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.
Scrumban 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 the waiting time on new features and project completion.
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 times.
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.
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. Similarly 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.
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 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 fall below a certain number, the planning meeting is held and new tasks are added to the backlog.
There are several strategies team can follow with 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.
As there are no daily meetings in Scrumban, the next even 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.
Similarly to Scrum, there is no need for the whole team to participate. Only one or few representatives are sent. It is also common for a project manager to be part of the meeting to help communicate and set future goals.
Lastly, before a new cycle, the whole team sits down in a Retrospective. Just like in Scrum, this 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, retrospective should end with at least one actionable item for the next iteration.
Thus, gradually improving the project process.
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 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 a 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 analysis.
Current bucket – for tasks that the team will be implementing next. As a plan is ready to go forth, 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.
Scrumban started out as a way for Scrum users to step into practicing Kanban. However, for some 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 needing some structure, but not wanting to be overwhelmed with ceremonies. As well as for those that want to clearly visualize their process and track tasks through completion. You can aslo look into more detailed comparison of the three methodologies in our next article.
Scrumban works best for projects with unclear and changing priorities. It can assist projects that are driven by events, like helpdesk. It is also good for teams that focus on adding features and supporting an existing product.
Create your Scrumban board in Teamhood and see for yourself if this framework fits your needs!