For some time now, Scrum has been the leading Agile framework used by organizations around the world. The Version One State of Agile Report has shown a year-on-year increase in the adoption of Scrum with 68% of organizations using Scrum or a Scrum Hybrid in 2017. However, Kanban, an Agile framework which has some similarities to Scrum, has been completely overlooked by comparison. Whilst Scrum adopting has been increasing, the percentage of organizations using Kanban hasn’t changed for nearly 5 years (remaining stable at 5%). This blog explores the difference between Scrum and Kanban and how they compare in terms of added value.Kanban, a Japanese term meaning Signboard or Billboard, was originally implemented as a lean manufacturing method at Toyota. One of the key components of this method are the Kanban cards which are used to visually represent the flow of materials within a production environment. The Agile framework known as Kanban uses cards to represent tasks in a similar way on a Kanban board. Scrum also uses a board as an information radiator but in a slightly different way. They can both have a backlog, an ‘in progress’ column and a ‘done’ section –but that’s about where the similarities end.

Defined Roles vs. No Roles.

Defined roles ensure that everyone has their role to play in the team. When it comes to a Scrum team, the Scrum Master and Product Owner are essential to block any distractions or interference to ensure that the team can get on with the task at hand. On the other hand, it’s difficult to assign roles to very small teams as this can result in team members playing a dual role. This is where Kanban could be a good solution for smaller teams as the workflow is regulated by Work in Progress (WIP) limits. After all, there are fewer people required in a team to run Kanban. Although, on the other hand, it also means that the team does not have the positive influence of a Scrum Master removing blockages or a Product Owner who guards the vision.

Sprints vs. Work in Progress (WIP) Limits

WIP or Work in Progress limits are what helps keep productivity high and the flow of work steady in Kanban. Sprints are not used in Kanban as it was originally created with the aim of improving the efficiency of constant processes. To help team members retain focus and increase throughput, there is a limit on the number of items that can be worked on. This is decided on by the team at the start, so whilst adopting Kanban. Having this limit prevents team members from becoming
overloaded or distracted due to having to divide their attention. In Scrum, a team works on a specific number of items within a sprint, and as a result, a set timebox. This means that the limit is time, rather than the number of tasks. The amount of time per sprint is decided by the Scrum team at the start of a project. During every sprint, the team estimates the work using planning poker to be able to judge how much work will reasonably fit in a single sprint, so the limit is the time rather than the number of tasks. The difference between Scrum and Kanban, in this case, is very much related to the nature of the work being performed. Kanban is designed for ongoing work whilst Scrum is really made for finite projects.

Fixed Timeboxes vs. No Timeboxes

Speaking of timeboxes –Scrum utilizes timeboxing to improve efficiency and as part of the rituals of Scrum. The different events (sprint planning, daily scrum, sprint review and sprint retrospective) in a sprint all have a predefined maximum duration to help maximize productivity. In contrast, Kanban doesn’t use timeboxes at all. As a result, team members work on a maximum number of tasks (WIP limit) and can only pick up a new card when they have moved a card to the next column. This means that the emphasis is on achieving a consistent and efficient flow of work, rather than on time. As a result, the columns of a Kanban board should never be empty as the backlog tops up the WIP column every time it dips under the limit.

Estimating vs. Prioritizing Only

In Scrum, each task is given an estimation of the effort needed to complete it. A number of story points are assigned based on this estimation. This process involves each team member giving their own estimation before comparing with the rest. As a rule, each sprint a maximum number of points can be picked up by the team based on performance in the previous sprint. Although this can differ sometimes, in which case planning poker isa useful tool. This process of iterative improvement means that estimating will get more accurate with each sprint. The number of points are set in sprint planning and cannot be deviated from. When applying Kanban, there is no estimation –only prioritization. This means that tasks can be moved around or introduced to the backlog later. The items at the top of the backlog will always be picked up first. This gives a certain amount of flexibility if urgent issues come up or if other tasks become obsolete for example. Overall, neither Scrum nor Kanban is a ‘better’way of doing things. They just lend themselves better to different situations. Scrum is ideal for project-based working whilst Kanban is more suited to a constant flow of work. Scrum comes into its own when you have a big enough team (between 6 and 9 people) and the right people to take the required roles whilst Kanban shines for smaller teams. And, of course, if neither Scrum nor Kanban is the right fit for you, there’s always Scrumban!

EXIN Agile Scrum and EXIN Lean IT

Whether you choose Agile or Lean, EXIN offers certifications for every professional
at nearly every stage in their career. The EXIN Agile Scrum program features the only Scrum certifications that cover both the Scrum framework and the Agile methodology behind it. Choose from EXIN Agile Scrum Foundation, EXIN Agile Scrum Master or EXIN Agile Scrum Product Owner and embrace your role within your scrum team. EXIN also offers the EXIN Agile Scrum Product Owner Bridge for professionals who already have a Scrum Master certification and want to take the next step. The Lean IT certifications offered by EXIN are available at Foundation, Kaizen and Leadership levels and have been created by the Lean IT Association.