Scrum is one of the most popular Agile frameworks on the market and thus the most common first choice for new practitioners. It is easy to understand and ready to go, however after a while Scrum can prove to be just a little too restrictive. This is when most Agile users turn to Kanban or what was created to be a step between the two – Scrumban.
I have already discussed the ins and outs of the lean approach Kanban, thus this time I want to introduce you to Scrumban. A middle ground for Scrum and Kanban that became a standalone framework great for reacting to change while keeping order and even introducing long-term planning into the Agile mix. Let’s see how all of this is possible.
Scrumban – What is it?
Before getting to the specifics, I would like to note that Scrumban was created as a stepping stone. Once Kanban started to gain popularity more and more Scrum users became interested. However jumping from one practice to another proved to be difficult. This is where Scrumban was introduced as a way to move Scrum practitioners to Kanban.
It meant to introduce the practice slowly and act as a transitional mechanism before the full Kanban application. However, some practitioners never finished this process and turned Scrumban into a standalone framework instead.
To understand just how Scrumban operates, we first need to get to know its parents – Scrum and Kanban.
Scrum is an Agile framework that uses time-defined Sprints to plan and complete work. The team has predefined roles and assignments, they plan in advance and perform scheduled ceremonies to monitor the progress.
Kanban on the other hand is much looser in the way it runs. There are no predefined roles or meetings for the team. The team plans on demand and iterations end once the team feels they have added substantial value to the end goal.
So what is Scrumban? To put it simply – a hybrid.
Scrumban takes the structure of Scrum and adds in the flexibility provided by Kanban. Using the right parts from each, Scrumban becomes adaptable to changes as well as easily controlled and manageable.
How Does It Work?
In Scrumban, the work is organized in small Scrum-like iterations and monitored on a Kanban-like board. The team plans the work in advance and then completes it according to the WIP limits. The team uses a planning trigger to keep iterations short while all the team members stay in their preexisting roles.
Sounds simple enough, right? Here are more details.
The traditional Scrumban board is comprised out of three sections – To Do, Doing and Done. After the planning meeting, the team adds tasks to the ‘To Do’ section. Once the iteration begins, team members choose their tasks and pull them into the ‘Doing’ section. And once a team member finishes a task, he or she moves it to the ‘Done’ section.
To clearly represent the work processes teams usually expand these three sections with additional columns. Priority columns are added to the ‘To Do’ section and process steps, such as Design, Manufacturing and Testing are added to the ‘Doing’ section. Thus creating a board that clearly represents the process and helps the team work autonomously.
To make sure team members work on no more than one task at a time, Scrumban uses Work In Progress (WIP) limits. The team usually adds them to the top of the process columns and thus limits how many tasks can be pulled into each column. While it is most common to have WIP limits that are equal to the number of teammates, this can differ as well. Depending on the work your team does, this number can be increased to account for the time needed to review the work.
Scrumban teams use similar limits for planned tasks. To control how many tasks are added to the board during a planning session, To Do limits are added. This is a great way to focus your team on prioritizing and planning the most important work thus controlling the length of iterations.
Scrumban likes to keep its iterations short – most commonly under two weeks. This allows for the course of action to be changed quickly and without any major issues. Usually first few iterations are used to determine the team velocity – how many tasks the team completes in a certain timeframe. And then this is used to set the To Do limits and identify process issues. Which become noticeable if, for example, velocity suddenly drops.
Scrumban teams plan on-demand. Once the planning trigger goes off, the team knows it is time to hold a planning session. The trigger is a signal to let the team know there is only a certain amount of tasks left in the backlog. This number differs from team to team and represents enough tasks for the team to keep working while they plan a new iteration. The number is usually determined with the help of team velocity and can vary depending on the changing circumstances.
During the planning session most teams also choose to prioritize tasks. Noting which tasks are the most important and which can be completed later in the iteration. To mark this, teams can add priority numbers to the task cards or create additional priority columns in the To Do section.
Scrumban does not specify any particular roles to be assigned for the team members. Usually whatever roles the team had before using Scrumban are kept and reinforced. However, roles in Scrumban should be more specialized than the ones in Scrum as each team member chooses and pulls his own tasks from the To Do section. This ensures a smooth flow of work as each team member can pick the most appropriate task after they are done with their previous one.
Once the project nears its end and the deadline approaches, Scrumban uses two distinct tools to control what work is going to be completed.
First comes the Feature Freeze and this means than no more planning meetings will be held. The team can only work on items that have already been planned. Thus ensuring they complete tasks that have already been started.
Usually right after the Feature Freeze a Triage also happens. This is done by the project manager, where he or she decides which of the already planned items will be finished and which will not. This allows the team to complete the most important work, before taking on something that can be left behind.
With this mix of Scrum and Kanban features, Scrumban creates a framework with short lead time and just-in-time decisions. It is perfect for new product development, maintenance or any projects with constantly changing circumstances.
Bucket Size Planning
One big difference Scrumban has from Scrum and Kanban is a defined long-term planning process. This is called Bucket size planning and helps teams to set goals and directions for the future instead of only focusing on the now. Depending on the scale of the projects the team works on this could be used to plan for the current or future projects. Either way it works exactly the same.
In this technique the team uses four ‘buckets’ to plan their work. 1 year bucket, 6 months bucket, 3 months bucket and the current bucket. Usually these are simply four different task boards that hold the planned items. Some teams use lists or notes, there is no specific way and you are free to use whatever works.
1 year bucket
The first bucket and the one that holds largest goals for the team is the 1 year bucket. This is a place for vague ideas and plans for future projects. As no specification or details are needed in this phase, the 1 year bucket is closest to a roadmap showing the general direction for the team or company.
6 months bucket
The next bucket is just a little more defined. Once you feel a plan is ready to be moved closer to implementation, it goes into the 6 months bucket. Here, it becomes a little more specific on what should be accomplished by the team. However, still keeping the details to a minimum. The best example of what such items look like is a Scrum Epic. A large loosely defined idea that is not overwhelmed with details.
3 months bucket
One last step before implementation is the 3 months bucket. Here the team adds even more details to the items, specifying what should be achieved and why. When comparing to Scrum, the definition of such items is similar to User Stories.
Lastly, the team moves the items to the current bucket and divides it into clear tasks. From here, the team can pull tasks directly into the To Do section of a Scrumban board and start working. The current bucket is a great time saver as the team does not need separate planning sessions for new iterations.
One less meeting is always great, isn’t it?
While some see the bucket size planning as an unnecessary addition, it is a great way to set long-term goals and ease on-demand planning. By performing long-term planning, you already know the main goals and direction of the company and only need to pull tasks into the team board to be completed. Whether you decide to use this technique or not is up to you, but make sure to consider the benefits it brings before dismissing it.
Scrumban vs Scrum and Kanban
Scrumban merges aspects from Scrum and Kanban, making them work together in a hybrid approach. Using the structure of Scrum, it 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 that 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 differences between the three frameworks, read my post on Scrum vs Kanban vs Scrumban.
For those of you working in a fast and changing environment, Scrumban can be a great choice. It offers both – the ability to adopt quickly and still keeps the control of operations. Great for startups, product development and other fast pace projects it will work best with a team that values extra time and efficiency over strict rules.