Agile frameworks have taken over the project management field in the last decade and such names as Kanban, Scrum, and Scrumban have now become the norm. However, if you are trying to choose one for your team, it can be just a little tricky. All of them stem from the same place and have similar values, meaning finding the differences between Scrum vs Kanban is just a little bit harder. Below you will find a full comparison of Scrum vs Kanban vs Scrumban – read through and pick something that sticks.
The comparison below is divided into sections. Where each section discusses the differences of the approaches in one aspect, for example, board management or team roles. You can read through all of them, just the sections that interest you or navigate to the bottom of the post for a comparison table that lays out all of the differences.
The origin of Kanban and Scrum
Just before we dive into the differences between Scrumban, Kanban, and Scrum, it is worth noting that all three are separate frameworks and all of them are considered Agile. Scrum was created by Ken Schwaber and Jeff Sutherland, Kanban has its roots in Lean project management, and Scrumban is the combination of the two that was first created as a way to switch, but stayed as a standalone framework.
As such, all of the three frameworks are considered to be under the Agile umbrella, but none of them represents Agile alone.
Board management and Iterations
When deciding on which Agile approach is right for your team, one of the first things to consider is how you like to work. With these methods, it means thinking about the board and iterations first.
Kanban definition does not outline any predefined iterations. Instead, the work continues until the team feels like there is significant value added to the end result. Therefore it is the team that decides when one iteration is over and a new one can begin. Since the work is being done continuously, the Kanban board is continuous too. It does not reset after each iteration and instead holds the work items of the whole project. In this case, it is often better to choose online Kanban boards so that the finished tasks are out of sight and not taking up too much space.
Scrum, on the other hand, uses 1-4 week iterations to complete the planned tasks. Meaning each iteration is set in time with planned tasks and has to end at a certain time. In a similar way, the Scrum board is reset after each iteration to be filled with new tasks and prepared for the new work phase.
Scrumban uses a board similar to Kanban, however, it works in defined iterations. Work is planned and completed in 1-4 week iterations, where teams complete the planned tasks and then plan again for the next iteration.
Kanban board vs Scrum board
With all three practices, the teams are encouraged to create a task board that best serves their process. However, there are certain guidelines that define the differences in Scrum board vs Kanban board vs Scrumban board.
The Kanban board is usually a full representation of the team’s process. It usually has a Backlog with several columns that are used to prioritize tasks for the team. An the In progress section is composed of as many columns as there are steps in the team’s process. For example, Design, Manufacturing, Testing, Quality Assurance, Done. With the focus on the team pulling tasks out of the backlog by themselves, there is quite a difference between Kanban vs Scrum board.
The Scrum board is usually composed out of the Product Backlog, Sprint Backlog, In Progress, and Completed sections. The Product Backlog is managed by the Product Owner and holds all user stories that are yet to be worked on. The Sprint Backlog holds the tasks that the team is committed to complete in the current iteration. And the two sections – In Progress and Done, help track the execution of tasks.
The Scrumban board is a mix of Kanban and Scrum boards (in some cases referred to Agile boards) largely depends on what visualization approach the team likes more. Most teams tend to lean towards a modified Kanban board as it offers more information right there on the board.
Team Members and Roles
Kanban team roles
Usually, the Kanban team is a set of various professionals that can achieve the end goal together. Each team member takes tasks from the backlog based on their priority and specifications. Since it is the team that drives the whole process, there are no defined Kanban roles. The whole team is responsible for planning, prioritizing, and the end result that is achieved.
Scrum team roles
Since Scrum works within very clear time constraints, it is best when the team is cross-functional. This way, team members can work on various tasks and are not limited to just one function. When the end of an iteration approaches the whole team can pitch in to finish up the planned work.
Despite having a cross-functional team, Scrum does assign specific roles to the team members.
- Product Owner sets the team vision and priorities. He or she is responsible for what the team does and where it is going. It is the job of the product owner to prioritize and decide which items will be taken on in the next sprint.
- Scrum Master facilitates the Scrum process. Usually, it is the most knowledgeable Scrum user on the team or even an outside consultant that helps in the Scrum application. Their function is to guide the team in how they apply Scrum and help if there are any uncertainties in the practice.
- The team completes work items and builds the final product. This is a cross-functional set of professionals that work to achieve the end goal.
Scrumban team roles
When comparing teams and their roles in Kanban vs Scrum vs Scrumban, the latter takes a middle ground. It works great for both – teams that are cross-functional or not. Scrumban does not define any specific roles to be used but allows for the team to decide if and what roles should be added. Therefore each team can pick and choose what is the best for them.
Planning and Estimation
It is the team that chooses when to hold a planning session in Kanban. It usually happens when a part of the product is finished or when the planning trigger activates. Either way at this time the team sits down and fills the backlog with new tasks to complete. Here, they can also choose to use estimation to have more predictability for the process. Kanban teams estimate in two ways – using time units or making all the tasks the same size and then calculating the time needed using lead and cycle time metrics.
In Scrum, planning, and estimation is done based on the length of the iteration (sprint). Before a new iteration can begin, the Product Owner plans which tasks should be completed and sits down with the team to estimate the time needed to complete them. If during the estimation it becomes clear that there is too much work for the allocated time, work items are divided into smaller ones.
Planning in Scrumban is done on demand. Once the planning trigger activates, the team sits down and plans work items for the next iteration. Team velocity is used to determine how many tasks the team will be able to complete during an iteration. Thus the team only adds that number of tasks into their plan. For long-term goals, Scrumban teams use bucket size planning.
Work Routines and Scope Limits
When talking about how the tasks are distributed among the team, all three methods use the pull principle. Task assignments are chosen by the team members themselves. The time when team members choose their tasks in Scrum and Kanban differs, however.
Scrum asks team members to commit to tasks in the planning stage of each iteration. It is here when assignments are decided for the next phase and cannot be changed before a new one begins. The scope is controlled by the length of the iteration. The estimated hours of planned work items cannot exceed the length of the sprint.
Kanban and Scrumban methods practice a little different approach. Instead of having team members commit to tasks in the planning stage, they are free to choose their tasks once the work begins. WIP (Work In Progress) limits the number of tasks that can be worked on at one time. This keeps team members only working on one task at a moment and not taking on new work before the previous task is completed.
Meetings and Performance
Similar meetings are held by the practitioners of all three methods. The main difference here is that Scrum requires them to happen at a certain time, while in Kanban and Scrumban there is more flexibility for the team to choose when they will be held. There are 4 main meetings between these methods:
- Sprint planning or Planning session. A time when the team plans what work should be completed next. In Scrum, Sprint planning is held before each iteration. While in Kanban and Scrumban new work is planned when the old one is finished.
- Daily Scrum or Daily Standup. A short 15-minute meeting to catch up with what everyone on the team is doing. Team members present what they have done yesterday and what they have planned for today.
- Iteration review. Optional for all three Agile applications, this meeting is held after the iteration is over. Its purpose is to present iteration results to the clients and gather their feedback.
- Retrospective. This meeting happens once the project is over and is aimed to discuss the process, not the result. Team members communicate what has and hasn’t worked and how they would like to continue in future projects.
- Additional Kaizen meetings can be held by both Kanban and Scrumban practitioners. This meeting is usually included if a team runs into a problem in need of solving. It is a place where teams from several departments gather and brainstorm ideas and solutions for a particular issue.
Kanban uses two metrics to measure performance – Cumulative Flow Diagram (CFD) and Lead Cycle time. Cumulative Flow Diagram shows how many tasks have been completed and are still left to do at any time in the project. Lead and Cycle time measure how much time was spent on delivering a task. Lead time (also used in Scrumban) calculates time from the moment it was requested by the client and cycle time begins once the work has begun. Both these metrics allow us to better understand the work rate and estimate progress.
The main performance metric for Scrum is the burndown chart. It depicts how much work remains to be done and how it decreased from the beginning of the project. Allowing the team to monitor the rate at which the work is being completed.
Rules and Which to Choose
When comparing Kanban vs Scrum vs Scrumban, we find a lot of similarities stemming from the Agile background. However, all of these practices have particular differences that make them better suited for one work environment or another.
Kanban has a reputation for being loose and non-restrictive to its users. While it may seem daunting at first, the flexibility it offers means the ability to adapt to any field or industry. Kanban is a great option for teams with a continuous flow of tasks, like manufacturing, engineering, or development. Here is a Kanban sheet for a quick reminder of the main practices.
If you are wondering when to use Kanban vs Scrum, consider how much you like following rules. Both Kanban and Scrum offer stem from the same background, but Kanban offers a much looser process, while Scrum asks to follow quite a few rules.
Scrum is the strictest of the three practices. By holding the most rules and limitations, it is one of the most understandable Agile applications for a new user. However, if a team is in need of flexibility, this approach somewhat lacks. Scrum is best suited for large long-term projects in need of more efficiency.
Scrumban is set right in the middle of the previous two. Taking some of the rules from Scrum and some of the flexibility from Kanban, it offers the best of both worlds to its users. Scrumban is a great option for new teams and fast-moving environments like startups, where there is need for a lot of flexibility as well as structure to keep it all together. If you feel like Kanban and Scrum are somewhat lacking, opting for this mix of two may be your best bet.
You can find out more about in our ultimate guide on Scrumban.
Frequently asked questions
Which one is better scrum, kanban or scrumban?
There is no single best method. You must choose the agile method based on your challenges. All methods can provide significant value if implemented correctly and for a tailored challenge. Methods like scrumban are the result of combining techniques to tackle wider area of challenges where scrum or kanban lacks. But it does not mean that scrumban is superior.
How to switch from Scrum to Kanban?
This is a very common question and usually switching the method is not the best option. Teams which tried doing scrum and failed, often try to switch to Kanban by thinking that it is simpler and will yield better results. Usually this is not the case. Either lack of understanding that Kanban is a whole system on it’s own or poor implementation of scrum leads to such conclusion. We recommend sticking with method and checking whether there are issues related to it’s implementation first.
Is Kanban better than Scrum?
No it is not. Both methods are just fine. You should clearly understand both of them first and then investigate what kind of challenges do you want to solve. What kind of environment do you have. And only then choose a method.
What is the difference between scrum and kanban?
We recommend referring to the above comparison table to understand key aspects of each method. Nonetheless, the best understanding comes from practice which is of course time consuming and costly. But, failing to implement a method is costly too.