Scrum Kanban Scrumban

Scrum vs Kanban vs Scrumban – How Do They Compare

Agile methodologies have taken over the project management field in the last decade and such names as Scrum, Kanban and Scrumban have become the norm. If you are trying to choose one of the three for your team however, it can be just a little tricky. All of them stem from the same place and have similar values, meaning finding the differences is just a little bit harder. Scrum vs Kanban vs Scrumban is just what you need to solve this.

Keep on reading to find out the main differences and similarities between the three methods. As well as which will work best in each situation.

Boards 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.

Scrum uses 1-4 week long iterations to complete the planned tasks. Meaning each iteration has a set time, 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.

Contrary to Scrum, Kanban does not go by 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 digital Kanban boards so that the finished tasks are out of sight and not taking up too much space.

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

Team Members and 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 on 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.
SCR22582 InfoGraphic LQ

Kanban

When practicing Kanban, it is the team that decides when one iteration is over and a new one can begin. Thus there is no need for a cross-functional team. Usually 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 team roles in Kanban as well. The whole team is responsible for planning, prioritizing and the end result that is achieved.

When comparing teams and their roles in Scrum vs Kanban vs Scrumban, the later takes a middle ground. It works great for both – teams that are cross-functional or not. It also 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

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.

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 prediciting by the number of tasks left in the backlog.

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 in 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 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 also controlled by the length of the iteration. The amount 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 amount of tasks that can be worked on at one time. This keeps team member only working on one task at a moment and not taking on new work before something 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:

  1. 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.
  2. 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.
  3. Iteration review. Optional for all three Agile applications, this meeting is held after the iteration is over. Its purpose being to present the iteration results to the clients and gather their feedback.
  4. 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 the future projects.
  5. Additional Kaizen meeting can be held by both Kanban and Scrumban practitioners. This meeting is usually held 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.

Performance

burndown

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.

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 to better understand the work rate and estimate progress.

Lead and Cycle time

Rules and Which to Choose

When comparing Scrum vs Kanban 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.

Scrum is the strictest of the three practices. 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 lacks somewhat. Scrum is best suites for large long-term projects in need of more efficiency.

Kanban has quite a different reputation being loose and non-restrictive to its users. While it may seem daunting at first, the flexibility it offers means the ability to adopt to any field or industry. Kanban is a great option for teams with continuous flow of tasks, like manufacturing, engineering or development.

Scrumban is set right in the middle of the previous two. Taking some of the rules from Scrum and some of the flexibility of Kanban, it offers both 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.

The Overview

scrum vs kanban vs scrumban
Teamhood is a hyper visual project and team management solution that helps companies to streamline business processes and deliver results faster. Teamhood is designed for professional teams seeking efficiency at work and full empowerment of their talents. Teamhood provides workspaces, customized boards with fine-tuned time tracking, collaboration functionalities as well as visual agile metrics reporting.
Teamhood is developed by Eylean, a project management software company since 2011. Eylean products are valued by its numerous customers globally such as Mercedes AG, Festool, Johnson&Johnson, Rabobank and others.

© 2020 Teamhood ® by Eylean. All rights reserved. We use cookies on our website.

Teamhood uses cookies to improve your experience, personalize content and ads, to provide social media features and to analyze our website‘s traffic. By agreeing you accept the use of Cookies in accordance with our Cookie Policy.