Scrum and Kanban are project management techniques. They are representatives of the popular Agile family methodology. These methods are flexible and iterative and can be used in any industry, but they are best suited for the IT industry. Both methods are close, so their tools can be used in combination. A hybrid approach is very common when the best of Scrum and Kanban is used.
What is the difference between Scrum and Kanban
Principles of the Agile Manifesto:
People and interactions are more important than processes and tools. A team that works together and is committed to one common goal has great potential and achieves great success. The team is a single whole, therefore the team is responsible for a positive result or failure together. The main principle is free communication between specialists and collective discussions.- A working product is much more important than comprehensive documentation. In Scrum and Kanban, the emphasis is on reducing workflow and increasing communication within the team, as well as continuous discussion of the current project. Visualization of the development process is very important. For this, special boards with cards are used, each of which corresponds to a specific task.
- Cooperation with the customer is more important than agreeing on the terms of the contract. The key to success is daily communication with the customer and feedback. It helps to understand what is important for the customer and what product he needs.
- Being ready for change is more important than following the original plan. This principle is necessary in order to be able to quickly respond to feedback and improve the product being developed.
Despite the fact that these methodologies are similar and have a lot in common, they have a lot of differences, which will be considered in this article.
1. Teams
A Scrum team is versatile. It consists of as many broad specialists as is needed to solve each task
of the project.
In most cases, 5-7 people are enough. With more people, the result is less obvious through countless conversations. At the same time, Scrum team specialists do not have formal competence, for example, a tester can help a designer, and an analyst can help a developer, or vice versa.
In Kanban, the main task is to balance the various highly specialized specialists within the team. Several highly specialized teams can work on a task. For example, the analytical department works first, then the design department works, and only after that the developers start to work. In this case, universal commands are allowed as well.
2. Roles
A Scrum team needs more resources than a Kanban team.
Additional roles are needed to manage the entire development process: Scrum Master and Product Owner.
Scrum Master is the organizer. They do not lead or give directions. The Scrum Master organizes meetings, eliminates household and other problems, motivates the team, monitors the status of tasks, and monitors compliance with the Scrum approach. In addition to the tasks of the organizer, the Scrum Master works on the project, like other team members.
The Product Owner interacts with the customer, connects the custo
mer and the team, monitors the development of the project, but is not a formal team leader.
They prioritize the tasks. It is to them that the team provides the result
of the work.
In a Kanban team, such resources are not needed, since the process is linear and more organizationally simple.
The team does not have the Scrum master and Product owner roles. The team is a whole one.
3. Planning
In both methods, the project is divided into dozens, maybe hundreds of smaller tasks. All future tasks of the project are included in a common list of tasks — a backlog. Each task has its own priority and relevance.
The difference is that in Scrum, the product owner prioritizes the tasks, while in Kanban, the tasks are prioritized by the team.
4. Time frame
In Scrum, the team divides project time into equal chunks — sprints, lasting one to four weeks, but the shorter the chunk, the easier it is to make changes. In Scrum, deadlines are a must for the team.
Each sprint consists of four sequential phases:
- Planning. The team checks the tasks in the general list of tasks for the project and forms them by priority. In the sprint, they take as many tasks, in the opinion of the team, as they have time to do.
- Execution. Team members work simultaneously, for example: a programmer creates code, at this time a tester writes tests for it, and a technical writer writes documentation.
- Release. By the time of each release, the product should be functional, useful for the user and enhanced compared to the previous sprint.
- Retrospective. Team members discuss the sprint and the problems that have arisen in the process together. Together they think about how to improve the quality of work and do more in the next sprint.
Scrum is less flexible because it is strictly forbidden to add tasks to an ongoing sprint in this method. Even the most urgent and important tasks will go to work from the next sprint.
At the end of the segment, unfinished tasks go back to the backlog. And at the planning stage for the next sprint, the need and time for their completion are determined.
Also in Scrum, time for daily meetings needs to be allocated, at which sprints are planned and organizational issues are resolved.
In Kanban, mandatory meeting reports are not needed. They can be held once a week or a month.
In the Kanban methodology, the project is not divided into universal sprints, but into stages of performing specific tasks, for example: «Planned», «Under development», «Testing», «Completed», etc. These stages can be of different lengths. New tasks can be added at any time. If something needs to be done urgently, the team will not wait for the next stage to complete an urgent task. The task can be in work as long as it takes for it until the team completes it or cancels it.
So, in Kanban, it is more difficult to control product development time and predict when a module will be completed than in Scrum.
5. Boards
Physical or electronic boards are used to visualize these methodologies, for example, Trello, Jira, etc. They allow the workflow to be as open and understandable as possible for all team specialists. And also to plan tasks and set some restrictions.
The board is divided into columns, which are assigned different task states, for example:«To do», «In progress», «Review», «Test», «Done», etc. The number and names of columns, of course, depend on the specific project, but in general, the fewer the better. The cards describe the tasks and also indicate the priority. As assignments are completed, they move across the board to another column, allowing how the assignments are being performed and where problems arise to be seen.
The difference between the methods is that with Kanban, the board is constantly in a filled state. And in Scrum, the board is cleared every time a new iteration occurs.
6. Indicators
Scrum measures the total weight of all tasks performed per sprint. By dividing the total weight of the project tasks by the spring performance, the estimated completion date for the project is obtained. Improving productivity is the main metric of a team in Scrum.
Kanban measures the average time it takes to complete one task across the board. This time is an indicator of the team’s effectiveness. Team members do not focus on specific tasks, they make sure that the average execution time is minimal.
As you can see, Kanban and Scrum have their own specifics. This or that project requires a certain approach to development. In some cases, you need to use Scrum, in others — Kanban. Scrum is perfect for managing one large-scale project with a duration of three months or more that has a comprehensive specification and requirements before starting a development. In this case, the team can easily prepare a detailed development plan and divide the whole process into sprints. And Kanban is great for small projects that don’t take as much planning time. It is also ideal for long-term projects in which there is no clear specification and tasks are formed during the development process.
