If you’ve ever worked as a project manager you may be familiar with at least some of the commonly used project management methodologies or Agile methodologies like Scrum or Kanban.
But what about Scrumban?
If implementing Scrumban isn’t familiar territory or you’re not sure how to put it to work, then you’ve landed in the right place. We’ve developed this beginner’s guide to Scrumban methodology to help you get up to speed on what Scrumban is, its many benefits, how to put it into practice, and ultimately measure success.
Since Scrumban is a hybrid framework – Scrum + Kanban = Scrumban – it’s important to first have a good grasp of Scrum and Kanban. Let’s start with some of the basic definitions and the differences between Scrum, Kanban, and Scrumban and then jump into everything you’ll need to know about Scrumban and how to use it for process improvement.
What is Scrum?
Scrum is a widely recognized Agile framework that teams use to develop their products or services. It uses short work cycles called sprints (iterations) to discuss, limit, and complete work, and clear backlogs.
You can look at each sprint as a part of a calendar of event-driven actions that can help your team speed up product development time and improve quality.
What is Kanban?
Kanban is a visual development method to control and manage workflow. It uses boards that show task-related cards to quickly see all outstanding work, work in progress, and completed work. Team members update the status of tasks by dragging them to the appropriate status column.
What is Scrumban?
The Scrumban framework combines Scrum and Kanban to help your team improve the way work gets done. It combines Scrum structure and Kanban flexibility to create a hybrid framework that allows teams to increase versatility and agility when managing workflows.
Teams use Scrumban to better guide and manage the development of a product, service, or maintenance-based tasks. Scrumban also uses short iterations similar to Scrum sprints to control and manage the workload.
Why was Scrumban developed?
Scrumban was developed by Corey Ladas, a Lean-Kanban practitioner, as a way to transition from Scrum to a more evolved framework. Although Scrum and Kanban frameworks work well within many projects, each has their limitations. The Scrumban principles and practices create unique yet complementary Scrum and Kanban capabilities.
The benefits of adopting Scrumban
The combination of the Scrum and Kanban methodologies has many advantages:
- It leverages Scrum for agility and Kanban’s process overview to help staff stay in a state of continuous improvement.
- It can help your team to reduce or remove overhead stress, increase efficiency, and increase customer satisfaction.
- Your teams can gain greater clarity on how to apply Scrum Guide concepts in practice, without replacing them.
The biggest wins are in delivering a higher quality product, achieving continuous improvement, minimizing waste, and reducing lead time.
Project management trainer Sylvie Edwards uses Scrumban to help her students. Each semester she explains that her students encountered the same issues, making it necessary for them to provide a lot of documentation and complete significant planning for projects that were only ten weeks in length. She explained that “using core, although basic, Scrum ideas and mapping them for all to see on a Kanban board allows everyone to easily see who has been assigned tasks, what has been done, what is in progress and what remains.”
She said her students “have taken a real liking to this method that they can pick up easily and apply once they start to work outside of class. Some have also treated their school deliverables in the same manner and have seen improvements in being able to deliver to deadlines.”
In her case, Sylvie said Scrumban offered some real benefits to her students. “I discovered that you could marry the basic principles of Scrum and Kanban while trying to find an easy to grasp, visual tool that could help our students deliver small projects in very limited amounts of time.”
How does Scrumban differ from Scrum and Kanban?
While Scrumban overlaps with Scrum and Kanban in some ways, the team structures, roles, meetings (ceremonies), and guiding rules and principles differ. 
Key Scrumban principles
Scrumban teams use Scrum as the work method and Kanban as the lens through which they see, understand and improve their work. Scrumban key principles and attributes include:
- Organizational management, to help your company plan the work necessary to achieve efficiency.
- Simplification, Standardization, and Specialization: this means simplifying processes for greater efficiency, standardizing your company’s infrastructure to create more continuity, and hiring people who specialize in specific roles to effectively complete tasks.
- Using clearly stated policies about the way work gets done to ensure that all of your employees understand their roles and how they fit into project and company-wide goals.
- Applying flow laws and queuing theory, to manage and limit the flow of work to be done.
- Intentional economic prioritization that prioritizes the work do be done based on the value or economic benefit that it provides.
- Using the Scrum development iterative and incremental approach to complete the work.
- Is organized around teams.
- When appropriate, time-boxed iterations are used whereby teams work within predetermined development cycles to complete the work.
How do teams actually use Scrumban?
In general, with Scrumban there is no specific time commitment, whereas, with Scrum, the work in progress (WIP) is limited by the sprint’s time commitment. Scrumban teams have to limit themselves to the WIP limits that are determined.
When working with Scrumban, it is crucial to understand the following elements in order to be successful: the Scrumban method, the visual board, how to limit WIP, interactions, on-demand and bucket size planning, and using metrics.
As an example, let’s use a software development project for this purpose where we’re working with features (user stories) or tasks. Understanding the visual board, its elements and the Scrumban method are the first steps.
About the Scrumban board
In Scrumban, your team can use either a physical whiteboard or a visual boarding software. Each user story (feature) or task should be represented by either a post-it note on the whiteboard or the equivalent in the visual management software. The Scrumban board shows each user story and its status within one of three columns:
- To Do
- Work In Progress (WIP)
- Done
The Scrumban board represents the progress of the team. Depending on the nature of your project and its complexity, you can adapt and expand your board with other columns such as priority, design, manufacturing, tests, and so on.
Work methods
Planning meetings are held initially to identify and prioritize all current tasks and which user stories or tasks to complete first. Each task should be placed on the board in the “To Do” column. When a team member is ready to start work on a task, they move it to the ‘WIP’ column, and once they complete that task, they move it to the ’Done’ column.
Iterations
To keep interactions short, WIP thresholds should be used and a planning trigger should be set to let the other team members know when to do the next planning. Similar to Scrum, work iterations in Scrumban are kept short. This ensures that your team can easily adapt and amend their course of action to account for a rapidly changing environment.
The size of the iteration is measured in weeks, with the ideal size of an iteration depending on the work process of your team. It is recommended, however, not to exceed two weeks. Speed (a measure of productivity) is commonly used by the team to help understand any issues throughput to support continuous improvement.
Limiting WIP
A key goal with Scrumban is to limit work in progress (WIP) so that each individual on the team can focus on successfully and quickly completing only the tasks that are assigned within the current iteration. If you’ve previously been part of a Scrum Team, you are likely to already have the mindset of limiting WIP, and given the scope size vs. the team’s ability to deliver, this already limits how much work can enter an iteration.
You can maintain this common strategy in a Scrumban method, but Kanban suggests doing so in potentially different and even more granular ways, understanding that constraints stimulate behavioral changes in the team. This practice is called in the WIP Limit Kanban (the work in progress limit).
In the first Scrumban iteration, your team should try to predict how many product backlog items they will be able to deliver, or the Throughput Forecast. It defines the total WIP Limit of an iteration. For each new item, an old item must be finished or downgraded. As new sprints occur, you will have an average throughput history and you can adjust the WIP Limit according to the reality of the team’s performance.
Kanban also suggests that you can apply the WIP Limit by flow steps. For example, you should not have more than three items being developed at any one time. Each team should only be associated with doing one item. These more granular constraints help educate and discipline teams and ensure greater focus, objectivity and complete delivery.
When it comes to the end-to-end process and tasks, the WIP Limit rules should be clearly communicated to the Scrumban team. The WIP Limit is based on demand, which is referred to as a pull system.
On-demand planning
Scrumban planning should be based on demand and take place only when the planning trigger is activated. The planning trigger is associated with the number of tasks still in the To Do section of the board. When this goes down to a certain number the planning meeting should be held.
The number of tasks that should trigger a planning meeting is not predefined, as this depends on the speed of your team and how fast they can finish all of the existing tasks, as well as the time required to plan the next iteration. The tasks that your team has planned for the next iteration are added to the To Do section of the board.
Bucket size planning
1-year: reserved for your company’s longer-term, more strategic goals.
6-month: once a decision is made to move ahead with a long-term plan, it is plan is moved to the 6-month bucket, and the requirements are refined.
3-month: when the company is ready to start implementing the plan, the requirements are moved to the 3-month bucket where they are broken down into clear tasks for completion. Your team draws tasks from this bucket during their on-demand planning meeting and begins to work.
Prioritizing work
Your tasks should be prioritized in the table during the planning meeting. This helps each member on your team know which tasks should be completed first and which tasks can be completed later.
Measuring success
In a nutshell, successful teams have systems in place to both define and measure what success looks like.
The Service Level Expectations (SLE) chart is a forecasting chart and number dashboard that your Scrumban team should attach to or include with your Scrumban board. This chart tells everyone how much time is forecast to complete the work and helps to set expectations. SLE is based on Cycle Time, which is the time that elapses between the start and end of the work required.
Another important element to record is your team’s Average Throughput, or the average number of Product Backlog Items that your team can complete and move to the DONE column before the end of the Iteration. This number also counts towards the WIP Limit.
Best practices/tips for Scrumban beginners
Remember that Scrumban is distinct from Scrum because it emphasizes key principles and practices that are substantially different from the traditional Scrum foundation. Whether you’re a new Scrumban leader or just new to Scrumban, here are some best practices and tips to follow.
- Focus only on the current activities, avoid getting distracted by other related activities or noise that can compromise productivity.
- Keep your board simple and relevant. Avoid clutter that can over-complicate the process and timelines.
- Complete an entire task before moving on, avoid trying to multitask as this can cause unnecessary risk to the current WIP.
- Most importantly, limit the WIP to allow for realistic deadlines, use of resources, and higher quality deliverables. If your team is overloaded, they are unlikely to be able to focus clearly and meet their goals or your deadlines.
- Identify, document any changes or unplanned tasks in order to address any potential risks to WIP and the timeline.
Perhaps most importantly, remember that Scrumban’s embedded principles and practices are not unique to the software development process. They can be easily applied in many different contexts, providing a common language and shared experience between interrelated business functions.
Does this mean that Scrumban will work for any project or in any company?
Yes and no. A good team leader will assess the types of projects a company has and the unique goals, team experience, readiness, timing, and other factors. However, if you decide that Scrumban is the right choice, it can become a valuable tool that combines the best of two already amazing frameworks.
Get started