The inspiration for this methodology came from rugby, where this term is used to denote a tight formation of players trying to win possession of the ball.
The first time the term scrum was used outside its original context happened in 1986 in the article "The New New Product Development Game." The paper showcased how some companies had achieved a better production performance than most competitors by utilizing a team-based approach. Therefore, the idea of scrum revolved around bringing a feasible framework to life, aimed at creating a productive environment for teams to work as cohesive units towards their common goals.
In 1995, the methodology was finally developed into an applicable framework for the software industry and was made publicly available at the OOPSLA conference. The next major benchmark event in Scrum evolution besides the creation of multiple Scrum organizations was the introduction of the first official guide to Scrum practices in 2010.
The history of Kanban starts decades earlier in Japan. To prevent further financial losses caused by overproduction and stay competitive with American rivals, Toyota implements a revolutionary method for workload management to help line workers realize when specific items need to be replenished, prepared, transported, etc.
The Kanban system is built upon the idea that to achieve a superior production performance and reduce various types of waste, teams need to focus on customer demand rather than on the production of specific amounts of goods and pushing them to an already oversaturated market.
The Kanban system utilizes cards to trigger actions in manufacturing processes. Roughly speaking, employees on the production line can't work on a new order before there is a demand for it, which they receive in the form of visual cues. This approach provides higher visibility into all the manufacturing processes and significantly reduces large stockpiles of goods and materials.
In 2010, the Kanban method was introduced for knowledge work.
Now that you have a better understanding of what Scrum and Kanban are, let's discuss the differences between the two frameworks so that you could decide for yourself which one suits your objectives. We are going to break down what defines Scrum and Kanban into several categories.
But first, before we discuss in detail all the points of difference, make sure to consult the table below to get a clear overview of what makes both these frameworks so distinctive.
SCRM |
Kanban |
| The system allows users to determine the amount of work that needs to be completed within each Sprint. | Users are allowed to set limits to the number of work items one can simultaneously have in progress in each stage of a workflow. |
| No changes to the existing tasks are allowed during a Sprint. | The Kanban system allows for continuous improvement of work processes before they are completed |
| Meetings are compulsory and fall into the following categories: Sprint planning, daily standup, Sprint review, Sprint retrospective, and more. | Meetings are optional and can include prioritization meetings and retrospective meetings. |
| Product owner, Scrum master, development team. | No roles are required to get the job done. However, the Kanban system allows for the creation of two optional roles: service delivery manager and service request manager. |
Roles in Scrum differ from what Kanban has to offer its users. In most general terms, three major roles build up the core of a Scrum team: Product Owner, Scrum Master, and Development Team.
As a rule, POs are responsible for identifying projects that need to be accomplished within a pre-defined period of time; communicating to their teams what exactly they are expected to deliver at the end of a Sprint; providing ongoing feedback; ensuring that the work done by the Scrum team aligns with business objectives.
SMs, in their turn, are mainly responsible for creating a healthy work environment with minimal organizational disruptions, even if these are caused by the product owner. They also make sure that every individual in the team works within the Scrum framework.
The development team or the Scrum team is responsible for accomplishing what the product owner has assigned to them. When it comes to deciding how to execute that work, all team members are autonomous and can completely rely on their expertise.
The Kanban system doesn't come with an extensive list of pre-defined roles. This approach encourages collaboration within teams, and in case one of the employees is unable to meet specific goals, other teammates with less tight schedules can take on the implementation of his or her project.
Nevertheless, teams using Kanban can incorporate two distinctive roles into this system: Service Delivery Manager and Service Request Manager. While the former tackles all the workflows in and out of the Kanban system, the latter focuses mainly on workflows that get into the system.
In other words, SDMs make sure team members are equally engaged in all processes going in specific workflows and work towards providing excellent customer service. SRMs, on the other hand, handle all the incoming projects, facilitate discussions around the end product, help teams define concrete and clear goals they will need to adhere to in order to deliver customers what they want.
In Scrum, based on their expertise and experience, development teams decide how much work they can handle in each timebox, which usually lasts for about two weeks. Unlike Kanban, however, having too many tasks in progress at the same time is not a matter of primary concern in Scrum.
The Kanban system allows users to predetermine a maximum number of tasks that can be simultaneously in progress in each stage of a workflow. This way, an individual cannot move on to the next task before the previous one has been completed. While ensuring a continuous flow of work, this approach prevents employees from dealing with lots of complex tasks and becoming completely exhausted.
All the items that need to be completed before the end of each Sprint are discussed during planning sessions. Once the Sprint is in progress, Scrum users cannot add new items or make any changes.
As long as specific users have permission to make changes to existing boards, other users can stay updated with what is going on at the various stages of a workflow. Even if a certain process has been in progress for quite a while, Kanban allows for changes and improvements before the process is completed.
There is a wide selection of metrics that can measure how well a team performs within a set time framework, the most popular of which include Velocity and Sprint Burndown.
While the former provides a clear picture of the product delivery rate at the end of each Sprint, the latter focuses on the amount of work still left to be completed before the due date. Based on the data provided by Velocity, it becomes possible to measure how much work a team will be able to handle in future timeboxes. Sprint burndown, on the other hand, shows whether a team is on schedule or not.
Some of the key Kanban analytics that can help you monitor your team's performance include the following: Cycle Time and Throughput.
Cycle Time measures the total amount of time spent to complete each task. What any team should strive for is low Cycle Time, indicating that nothing is stalling the progress of their work.
The Throughput metric, on the other hand, calculates the total amount of work completed by each employee within a specific time frame.
While the Cycle Time metrics enable users to predict the amount of time an employee will need to deliver future projects, the Throughput metric provides detailed insights into an employee's work capacity.
Meetings in Scrum are compulsory and fall into several types: Sprint planning, daily standup, Sprint review, and more.
Sprint planning usually occurs at the beginning of each Sprint. The goals of such sessions are to make it clear what the team is supposed to deliver by the end of a Sprint, determine the amount of time needed for successful project delivery, allocate roles and responsibilities to team members, and more.
Daily Standups take place throughout the entire Sprint and bring greater accountability to every team member. The idea behind this type of session is to enable employees to share with teammates what they have already achieved so far, their daily objectives, and whether anything is stalling the processes.
Sprint reviews occur at the end of each Sprint and bring all members of a Scrum team together to discuss the end product and receive feedback from the Product owner.
Meetings in Kanban are optional. As long as there is a continuous flow of new items, team members may remain autonomous. Besides, Kanban encourages collaboration through commenting, document sharing, new item creation, etc. This way, the system allows for continuous improvement of all ongoing processes. Therefore, there is no need to conduct daily standups, as all information regarding the team's progress can be easily accessed by other users inside the system.
On the other hand, Kanban encourages users to organize the following types of meetings: prioritization meetings and retrospective meetings.
Prioritization meetings enable users to discuss what items should be included in a workflow and identify which of them are most important.
Unlike Scrum, Kanban has no set iterations. Therefore, as far as retrospective meetings are concerned, it is entirely up to a team to decide whether to organize them or not. The goal of such sessions is to reflect on the previous work performance and agree on what needs to be improved to deliver better customer value.
As you can see, both Scrum and Kanban offer users completely different approaches to handle their workload. Yet, the question is not which one is better, but rather which one is more suitable to achieve your objectives. Whether you choose Kanban or Scrum, either one will help you move quickly from ideas to delivery and ensure increased productivity inside your team.