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 frameworks like Scrum or Kanban. But what about Scrumban? If this framework isn’t familiar territory or you’re not sure how to put Scrumban to work, then you’ve landed in the right place.
We’ve developed this Beginner’s guide to Scrumban to help you get up to speed on what Scrumban is, its many benefits, how to put it into practice, measure success, and some of the best practices to use. It won’t be long before you’re up and sprinting, so get ready to hit the ground running with this powerful framework.
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.
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, clear backlogs and can help your team to speed up product development time and improve quality.
What is Kanban?
Kanban is another well-known and often-used framework. It’s a visual development method to control and manage workflow. It uses visual boards that show task-related cards that can help your team to quickly see all of the outstanding work, work in progress, and all the completed work. As work is completed, team members can 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 the Scrum structure and the 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. This makes it possible to better adapt as changes are needed. 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 some 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 come up with a lot of documentation and complete quite a bit of 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 believes that 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. There is a focus on specific principles and practices that differs from the traditional Scrum or Kanban foundation. These 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 that can 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 and establish the queuing system for the work that is to be started and completed.
- 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.
- Leverages continuous improvement techniques within specific meetings to continually look for ways to improve processes and how work gets done.
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, there are some core elements and steps that you’ll need to understand to ensure that you’re getting the best results. These include 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 program. 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 is displayed as being within one of three columns.
- To Do
- Work In Progress (WIP)
The Scrumban board visually represents your user stories and the progress of the team. Columns are adapted and expanded as your team’s work progresses. Depending on the nature of your project and its complexity, you can add other columns such as priority, design, manufacturing, tests, and so on.
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 would move it to the ‘WIP’ column, and once they complete that task they then move it to the ’Done’ column (or next relevant column if other columns have been added).
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 work in progress
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. This number is the Throughput Forecast and defines that the total WIP Limit of this iteration as that amount. For new items that are added, old items must be either 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.
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
Bucket size planning makes it possible to plan for the long-term in Scrumban. This is based on a three bucket (three stage) system that all work items have to go through before they can be added to the Scrumban board. The three buckets or stages are 1-Year, 6-Month, and 3-Month.
1-year: The 1-year bucket is reserved for your company’s longer-term, more strategic goals.
6-month: Once your company decides to move ahead with a long-term plan, then that plan is moved to the 6-month bucket, and the requirements are refined.
3-month: When the company is ready to start implementing this plan, the requirements are moved to the 3-month bucket where they are broken down into clear tasks to be completed. Your team draws tasks from this bucket during their on-demand planning meeting and begins to work on the tasks.
Your tasks should be prioritized during the planning meeting by adding tasks to the board and marking the priorities. This helps each member on your team know which tasks should be completed first and which tasks can be completed later. Prioritization can be undertaken by adding numbers or by adding a priority column, where the most important tasks are placed at the top and the least important ones at the bottom.
Without being able to determine progress, identify success criteria, or measure success, your team can’t know where they are doing well or what the things are that they need to improve upon. 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. This is 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. In Scrumban, there’s no need for the Burndown Chart that is used by Scrum.
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.
- Recognize when Scrumban is the best framework to use instead of Scrum, Kanban, or others.
- 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.
- Identify, document any changes or unplanned tasks in order to address any potential risks to WIP and the timeline.
- Ensure that your team is set up for success by being realistic with WIP. If your team is overloaded, they are unlikely to be able to focus clearly and meet their goals or your deadlines.
- Remember to establish success criteria and measure WIP. It’s important to know what’s working and what isn’t.
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. This, in turn, increases organizational alignment, which is an essential feature of success.
Does this mean that Scrumban will work for any project or in any company? No, it’s important that you know how it will work for the types of projects your company has. You’ll also have to take your project goals, team experience, readiness, timing, and other factors into account. 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.