Kanban vs Scrum: choosing the best Agile project management framework

“We work by the Agile methodology.” You are going to hear this statement quite a lot in talking to software development teams. And it is true, according to the statistics, that about 90% of developers worldwide were using Agile in 2018.

However, Agile is not uniform. Being a general approach to organizing a working process, Agile software development sets the common values and principles intended to make the development process more streamlined, effective and responsive to change. These values and principles can be found in the Agile Manifesto giving the general recommendations on setting up the development flow.

In real life, though, these Agile principles have found several practical implementations known as software development frameworks. Kanban and Scrum are among the most popular and frequently used. However, while both methodologies have a common goal of creating an effective workflow, there are certain differences that we are going to discuss today.

Understanding the workings of Scrum and Kanban can help both the clients and the developers to understand the working rhythm of the team and to plan their activities accordingly.

Basics of Scrum and Kanban

Before we plunge deeply into the differences between Scrum and Kanban, let’s look at the main concepts of both frameworks. This way, it will be easier to make our Kanban vs Scrum comparison. Both of them are aimed at setting the flows of a self-organizing team; however, some approaches are different.

What is Scrum?

Scrum gets its name from a rugby term meaning a formation of players working together to take possession of the ball. In software development, Scrum also refers to the methodology of organizing the teamwork so as to make the development of sophisticated software products more efficient.

The Scrum philosophy is based on the assumption – or, should we say, fact? – that the development team does not know the outcome of the project at the beginning and is going to learn and adapt as the work progresses. Scrum is designed to make that adaptation easier by resetting the priorities at the beginning of each iteration, which is called “sprint” in the Scrum terminology.

Here we come to one of the central concepts of Scrum – the sprint, which is a time period of 2 to 4 weeks during which a certain amount of work is done. Sprints help to break the project scope into more easily managed tasks and to deliver functioning software components more frequently. We will get into more details on sprint planning, adjustment, and completion shortly.

Working in sprints and focusing on the tasks that should be completed within each sprint allow great flexibility in planning. The team starts each new sprint with a “clean slate” and plans the tasks taking into account the current situation and any changes in the project requirements that have been received so far.

kanban-vs-scrum-comparison-agile-frameworks

What is Kanban?

Kanban was first invented by Toyota in an attempt to optimize its factory inventory. In Japanese, “kanban” means a board or a card. In the original implementation, a factory department that was getting low on a certain item would send a “kanban" to the warehouse requesting a refill. The warehouse, in its turn, sent the “kanban” to the supplier to order more inventory.

From this example, we can see that the Kanban methodology is focused on the current capacity, and this is the main concept that it brought into software development. Unlike Scrum, Kanban has no time limits; instead, it limits the amount of work that can be performed at the same time.

One of the main metrics of Kanban is the “work in progress” – the tasks that are currently being performed. According to Kanban, in order to achieve maximum efficiency, the work in progress should be limited to correspond to the team's capacity, thus lowering the risk of any bottlenecks.

Kanban is also well-adapted to change, which is important as changes can be made at any stage of the project and added to the pool of tasks to be performed.

Scrum vs Kanban – the main differences

If we want to compare Scrum and Kanban, we need to look at the way both frameworks organize the workflow and the main entities and definitions they use.

Roles

The assignment of roles is the first big difference between Scrum and Kanban. In Scrum, you always find three major roles in a team:

  • Product Owner, who is in charge of the product. Product Owners analyze the customer’s requirements regarding the product and translate them into tasks for the team. Product Owners also prioritize the tasks and decide when a particular functional component may be released.
  • Scrum Master, who is in charge of the team. Scrum Masters, first of all, introduce the Scrum principles to their team members and assist them in their implementation. Also, Scrum Masters manage the distribution of human resources needed to deliver a particular sprint.
  • Team, who are in charge of the work. The team members actually get the work done. A scrum team possesses multiple skills, with several skills often combined in one person. The team works by the self-organization principle, assisting each other to get the job done.

Kanban, in its turn, has no strict requirements as to the team roles. There may also be a Product Owner supervising the tasks in the project backlog, but otherwise, the team is self-organized.

kanban-vs-scrum-project-management-for-enterprises

Workflow

As we mentioned already, Scrum development progresses in iterations, defining the work to be done within each iteration, while Kanban aims at limiting the current work in progress with no specific time limits. Let’s see what these two approaches mean in real life.

Scrum flow

Project planning starts with defining the backlog, that is, the list of user stories that should be worked on to deliver the completed product. In this context, Scrum uses the following major concepts that will help us understand how the work is planned and distributed:

  • Product backlog - representing the main “To Do” list of the team. The product backlog includes all features and bug fixes that need to be done for the project to be considered finished. The backlog is constantly updated with new requirements or detected errors which are scheduled for work. The Product Owner is in charge of the backlog, bringing it into sync with both the customer’s feedback and recommendations and the team's work progress. Some items of the backlog may be moved up or down in the priority rating, some may be added as the requirements change, and others may be removed altogether.
  • Sprint backlog - consisting of the tasks to be done within a particular sprint. The items for the sprint backlog are selected to deliver a finished feature or component at the end of the sprint. While the sprint backlog also allows certain flexibility and modification, the goals of the sprint should remain unchanged and the changes should be kept to a minimum.
  • Sprint goal, or increment - being a usable product delivered as the result of the sprint. Usually, a sprint ends with a demo showing the completed features or components. In this respect, an important concept is the definition of “done” that refers to each user story to consider it complete. The definition of “done” may vary according to the user story: it may include multiple tasks, such as development, testing, design, documentation, and presentation, and it may also involve different team members.

Each sprint starts with a planning phase where the tasks for the next sprint are selected. For the planning, the full team is usually present, including the Product Owner and the Scrum Master. The team decides what they can deliver by the end of the sprint and picks the corresponding user stories from the product backlog. This way, they put together the sprint backlog.

During the sprint, the team meets every day for a “daily scrum” where they discuss their progress and whatever blocks they might run into. The purpose of the daily scrum is to detect problems early enough and find the solution quickly so as not to disrupt the sprint flow.

After the sprint, the completed features are reviewed by the stakeholders. During the sprint review, the team has a chance to receive feedback on their work and the recommendations for changes, if any.

At the same time, the team meets for the sprint retrospective where they analyze the sprint they have just finished and find things that may be improved. After the retrospective, the process is reset, and the new sprint starts with the planning stage.

kanban-vs-scrum-workflow-sprint-development

Image credit: Scrum.org

Kanban flow

In Kanban, there are no time periods during which a certain amount of work should be done. Instead, Kanban is focused on balancing the team's capacity with the work that is currently in progress.

A Kanban project flow starts with the general backlog including all tasks that should be done. Each team member picks a task for him or herself from the backlog and concentrates on completing it. When the task is completed, the member selects the next one, and so forth until the backlog is exhausted. The backlog is prioritized with the most urgent tasks placed at the top to be picked up by the team first.

In Kanban, it is critical that the amount of work in progress does not exceed the team's capacity at any time during the project. For that purpose, there is a possibility to set a limit for any type of work according to the available capacity.

The Product Owner may set and change priorities in the backlog as much and as often as they like, as backlog management has no impact on the team's performance. The team cares only about the work in progress, returning to the backlog only after the current task is complete.

Each task travels along the “To Do” – “Work in Progress” – “Done” route. Of course, Kanban also supports the concept of the definitions of “done”, which is the criteria for each task's acceptance.

Eventually, the completed tasks form finished components for which it is possible to measure the time required to deliver them. In Kanban, it is called “cycle time”, and the cycle time measurement holds lots of optimization opportunities. Of course, all teams strive for shorter cycle times and look for ways to resolve bottlenecks, if any.

In this context, it is critical to have members with overlapping skills on the team. If a certain skill is possessed by only one person – for example, if you have only one tester – that is a bottleneck. All testing tasks will queue for processing delays in product delivery.

kanban-vs-scrum-managing-large-teams

Image credit: DZone

To summarize, we can say that the main difference is that Scrum is trying to get the scheduled work done within the specified time, while Kanban monitors to ensure that the work in progress never exceeds the set limit.

Kanban vs. Scrum board

Speaking of Scrum and Kanban, we cannot omit the subject of boards. Both approaches use boards as the visual tool to plan and monitor their performance. The boards reflect the main concepts of Scrum and Kanban, and are organized accordingly.

While there are lots of tools that are used to create and manage Scrum and Kanban boards (for example, Jira and TargetProcess support both, and Trello is originally a Kanban tool but can be also used for Scrum with an extension), you can use a plain whiteboard with markers and sticky notes to run a Scrum or Kanban process. The trick is to learn how, and the tool does not matter.

Scrum board

A Scrum board consists of a minimum of three columns labelled “To Do”, “In Progress”, and “Done”. When needed, you can add a “User Story” column showing the story to which the tasks belong or insert a “Testing” column before “Done”, but eventually they all show the task progress on time.

At the beginning of each sprint, all tasks are in the first column, and by the end of the sprint they should all move to the “Done” column after passing the definition of “done”. After that, the board can be cleared and prepared for the next sprint.

A Scrum board is always owned by one team working on the same product. Usually, Scrum teams are cross-functional including all skills, from developers and architects to testers and technical writers.

kanban-vs-scrum-custom-software-engineering-team-management

Image credit: Atlassian

Kanban board

A Kanban board generally looks and works the same as Scrum with one major difference – there is a limit shown in the “In progress” column. The number of tasks in progress should not exceed that number.

Kanban boards exist for the entire duration of the workflow. There is no need to reset them, as they are not bound to any particular time periods.

Since Kanban boards are intended for a particular workflow, they are not owned by any particular team and may be shared. In Kanban, a board can be used for a particular line of work, for example a marketing board.

kanban-vs-scrum-development-boards-top-software-engineering-companies-approach

Image credit: Atlassian

Which to choose – Scrum or Kanban?

If you have been waiting for a conclusive answer to this question, we may disappoint you. By now, we hope we have managed to show that both methodologies have their benefits and that both can help to set up an Agile development process. However, we offer a few guidelines that can help you choose what works best for your team.

Use Scrum if:

  • You can relatively easily break your scope into logical chunks that can be completed within a two-week period.
  • You need a high degree of predictability for the whole project. Scrum is focused on keeping the changes within a sprint to a minimum.
  • You have many new members on the team. With Scrum, it will be easier for them to understand the team discipline and make improvements, if needed.

Use Kanban if:

  • You expect a lot of frequent changes in the project.
  • It is difficult to isolate product components that can be delivered within a two-week period.
  • Your team is well-disciplined and can be trusted to schedule their activities without strict deadlines.

However, the good news is that you can always combine! There is even a methodology called Scrumban featuring methods of both Scrum and Kanban. In Scrumban, you work in short iterations keeping your work in progress within a certain limit. A new iteration is triggered by the work in progress falling under the limit.

As you see, choosing a project management methodology can be as flexible and free as you wish. No rules are carved in stone, and you can adapt, mix and match them as you see best for your project. Indeed, the main criteria in this selection process should always be your project success and your team satisfaction with the workflow.

Subscribe to our blog to learn more about popular trends in software development and project management, as well as about the latest news on the market of development tools and platforms. If you are particularly interested in a specific topic and want to learn more, or if you need professional development services, contact us – we’ll be happy to work with you!

↑ Go up

Similar post