You’ve probably heard kanban and scrum talked about when discussing Agile project management, but you might not know how to choose the right project management methodology for your needs, or even what the differences between kanban and scrum are. We’re here to help clear up some of the confusion between kanban and scrum, decide whether you need to choose one or the other, and understand what the key differences are between kanban vs. scrum.
Kanban vs. Scrum: Do You Need to Pick Just One?
Saying Kanban vs. Scrum is actually a bit misleading, because they are not project management methodologies that you necessarily have to choose between. In fact, the two methodologies can go hand-in-hand to help you be a better project manager.
Many scrum teams also employ the kanban methodology and use kanban boards in order to visualize their workflow better. Both kanban and scrum are project management methodologies that can be used by teams who adhere to Agile project management principles.
What Is Kanban?
Kanban is a project management methodology derived from the Japanese kaizen philosophy that uses a board, called a kanban board, to visually represent your workflow, limit work in progress, and identify bottlenecks to improve your flow of work. Cards that represent work are moved across the board through columns that are labeled “to-do”, “in progress”, and “completed”.
Teams that use kanban boards are focused on reducing the amount of time it takes to get a piece of work from “to-do” to “completed”. They release products continuously and implement changes continuously to improve work practices.
What Is Scrum?
Scrum is an iterative approach to project management that is most often applied by software development and IT teams. In the scrum methodology, a project is divided up into pre-defined work periods, usually two weeks long, called sprints.
The goal of scrum teams is to deliver working software at the end of each sprint, receive customer feedback, and quickly integrate learnings to improve their software. Scrum teams can use a kanban board to represent the workflow during a sprint.
Kanban vs. Scrum: What Are the Main Differences?
Although kanban and scrum are both Agile project management methodologies, there are some key differences that set them apart and make one or the other better suited to specific applications. The differences can be summed up by looking at release timeframe, team roles, measures of success, and how changes are implemented.
As mentioned previously, scrum teams release completed work at the end of each fixed time period called a sprint. Sprints are usually two weeks long, although the length can vary from team to team depending on the type of work they are doing.
With the kanban project management methodology, completed work is released continuously. Kanban boards have a continuous flow, in other words, products are released whenever they are ready and there are no fixed delivery dates.
On scrum teams, there are defined roles with prescribed responsibilities including a scrum master, product owner, and development team. The scrum master keeps the team on track with Agile and scrum principles, the product owner is responsible for prioritizing the work and managing the product backlog, and the development team chooses work to complete and delivers it at the end of each sprint.
Kanban is different from scrum in this sense because there are no defined team roles. Everyone on the team is responsible for the kanban board and collaborating equally on all the work. Each team member is expected to help identify problem areas in the workflow, help limit work in progress, and make suggestions for changes to improve work practices.
Measures of Success
The main measure of success, or key metric, on a scrum team is the velocity through each sprint. The velocity, or the amount of work completed during each sprint, is analyzed to determine how much work to take on during the next sprint. Therefore, each sprint relies on the success of the sprint before it.
With the kanban methodology, success is measured by the amount of work in progress (WIP), lead time, and cycle time. To state it another way, success is measured by how long it takes an item of work to get through the entire work cycle, from the “to-do” column of the kanban board to the “completed” column of the kanban board. Teams can limit the number of cards that are allowed in any one column at a time to limit the amount of WIP.
How Changes Are Implemented
In the scrum methodology, big changes are not implemented during the sprints. Instead, the team sits down at the end of each sprint to analyze the work, reflect on value to the customer based on feedback, and implement any necessary scope changes.
In the kanban methodology, changes are constantly implemented as part of the kaizen philosophy principle of continuous improvement. Kanban is very flexible in the sense that priorities can change, work can get added or removed from the kanban board, and WIP limits can be changed to better reflect the team’s capacity.
Kanban vs. Scrum: How to Use Them Together
Now that you know the key differences between the kanban and scrum project management methodologies, you may be wondering how you can use them together. If you are trying to decide between kanban and scrum, you can also use the two methods together in a hybrid methodology. For example, you can employ the scrum methodology of dividing work into sprints, and during those sprints use a kanban board to represent work items, identify bottlenecks, and be more productive during each sprint. Kanban boards can be customized beyond the basic three columns to represent more complex stages of your workflow.
That being said, if you do want to choose between kanban and scrum, then you should know which applications each one is best for. The kanban methodology is best suited to projects with priorities that vary widely so that you can easily adapt and implement changes as you go. Scrum is better suited to teams with more stable priorities that don’t change as much over time. Both kanban and scrum are powerful project management methodologies that you can use as needed to comply with Agile principles.