You’ve heard these terms before: Kanban and Scrum. But what, exactly, do they mean? Isn’t scrum a rugby term?
Every team runs their own Kanban or Scrum processes differently, so you might encounter different strategies depending on where you go. Both frameworks stem from visual project management methodologies, and they can both be great ways for teams to collaborate. But before we can compare and contrast the two methodologies, we first need to understand what we mean when we say each of these things.
Kanban most commonly refers to a visual project management strategy, where work is displayed in a board-like view with columns to represent stages of work. In a Kanban board, individual tasks progress through stages until they are completed.Read: A beginner's guide to Kanban boards
The Kanban method was initially developed as a lean manufacturing methodology by Taiichi Ohno during his time at Toyota. In Japanese, Kanban is a combination of two words: 看 (Kàn), meaning sign and 板 (Bǎn) meaning board. Initially, Ohno’s Kanban system used paper cards to track demand in the Toyota factory. Instead of attempting to anticipate demand and produce for that anticipated demand, his Kanban method produced and re-supplied products as a result of consumer demand.
The Kanban framework Taiichi Ohno developed has been digitalized, adapted, and refined over several decades to become the Agile project management system we now recognize today. At its core, the modern Kanban framework is an online, visual method to manage work. Today, when people say “Kanban,” they are frequently referring to Kanban boards: the visual project management view that brings the Kanban methodology to life.
In a Kanban board, columns represent the various stages of work. Within each column, visual cards—similar to Ohno’s initial paper cards on the factory floor—represent individual tasks.
Kanban boards are one of the most popular forms of visual project management. Like other types of visual project management, Kanban boards are sometimes most effective for providing easy, at-a-glance insight into a project.Read: 3 ways to visualize a project plan: Timelines, calendars, and boards
When you use a Kanban board for visual project management, you provide your team with a wealth of at-a-glance information. If you build your Kanban board in a work management tool, your Kanban board “cards”—which represent individual tasks or deliverables—will also capture task assignee, due date, and any relevant tags like priority or task type. With a work management tool, you’ll also be able to expand the card to view task details, context, relevant files, and more.
Kanban boards are a flexible way for your team to visualize work in progress. Traditionally, Kanban board columns display the stages of work (e.g., To do, In progress, and Done), which is why they’re popular visual project management tools for teams that run ongoing processes and projects like creative requests or bug tracking projects. But you can also set up your own Kanban board columns to represent anything you’d like. You can create columns based on task assignee, “swimlane” and responsibility, or due date.
Because of how effective they can be for visualizing work, Kanban boards are a key component of most project management tools. If you’re looking to choose the right project management tool for your team, make sure it offers Kanban as a view. Better yet, look for a tool that allows you to view work in multiple ways. For example, in Asana, Boards View (or Kanban) is one of four ways you can view work, in addition to Timeline View, Calendar View, and List View.Read: The four ways to visualize work in Asana
Scrum, like Kanban, is a framework to collaborate and get high-impact work done. Unlike Kanban, which is based almost exclusively on the visual form of project management that Taiichi Ohno pioneered, Scrum is a full framework, and you can “run teams” on Scrum.
The term “Scrum” was initially used in product development by Hirotaka Takeuchi and Ikujiro Nonaka in their 1986 Harvard Business Review article The New New Product Development Game. In the article, they introduce scrum:
“Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.”
Then in 1995, Ken Schwaber and Jeff Sutherland published the SCRUM Development Process, where they outlined the techniques and principles of modern Scrum. Schwaber and Sutherland would go on to research and refine their Scrum methodology, most famously in their Scrum Guide—a living document they update on a regular basis. The Scrum Guide defines Scrum “not as a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.” According to Schwaber and Sutherland, Scrum helps teams continuously improve their product, their team, and their overall working environment. Scrum does this by encouraging teams to take a look at how effective their work techniques are, and challenges teams to continuously evolve and improve them.
Today, product, engineering, software development, and other Agile teams run Scrum to execute their work faster and more effectively. To run a Scrum, teams typically assign a Scrum Master, who is in charge of running the three distinct Scrum phases and keeping everyone on track. The Scrum Master can be your team lead, project manager, product owner, or the person most interested in implementing the three traditional Scrum phases:
Phase 1: Sprint planning. A Scrum sprint is usually 2 weeks long, though teams can run faster or shorter sprints. During the sprint planning phase, the Scrum Master and team take a look at the team’s product backlog and select work to accomplish during the sprint.
Phase 2: Daily Scrum standups. Over the course of the Scrum (also known as the Scrum “cycle time”), teams traditionally meet quickly every day to check in on progress and make sure the amount of assigned work is appropriate.
Phase 3: Sprint retrospective. When the Scrum is over, the Scrum Master hosts a sprint retrospective meeting to evaluate what work was done, route any unfinished work back into the backlog, and prepare for the next sprint.
The goal of Scrum isn’t to build something in two weeks, ship it, and never see it again. Rather, Scrum embraces a mindset of “continuous improvement,” where teams take small steps towards bigger goals. By breaking work into smaller chunks and working on those chunks, Scrum helps teams better prioritize and ship work more efficiently.
Teams that run Scrum have clearly established rules, rituals, and responsibilities. Additionally, your daily scrum meetings, combined with sprint planning and sprint review (or “retrospective” meetings), help teams continuously check in and improve on current processes.
Because it draws from a backlog of work, and begins with a sprint planning meeting, Scrum offers an easy, built-in structure for team leads or product owners to manage and support their team’s most important work. This level of built-in prioritization is combined with clearly defined responsibilities. During a Scrum, your team has a pre-set and limited amount of work and amount of time for each sprint.
When we talk about Kanban and Scrum, there’s often a third frequently-used term: Agile.
Agile teams often run Scrum and use Kanban boards—but it’s helpful to think of Agile as a larger, umbrella term. Just like you can use a Kanban board without running Scrum, you can also have an Agile team that doesn’t run Scrum or use Kanban boards. Think of Agile as a project management philosophy. To follow an Agile methodology is to believe in iterative and incremental development to help teams respond to change and deal with uncertainty. Both Kanban and Scrum are subsets of the Agile methodology.Learn more: Manage your agile projects with a better agile management tool
Now that you have a better sense of what Kanban and Scrum are and where the two frameworks come from, let’s talk about the difference between the two, so you know which one to use when.
As a defined framework, Scrum includes a specific set of “rules” for teams to follow. You can choose to modify or adapt any of the Scrum rules depending on your team, but at a basic level every Scrum will have: a Scrum Master, a backlog of work, a sprint period, regular standup meetings, and a defined end to each sprint.
Kanban, on the other hand, is most frequently used to visualize work—any work. In fact, many teams run Scrum on a Kanban board—but in those cases, they’re still running Scrum, not Kanban. Think of Kanban less as a “methodology” with a set of rules, and more as a way to visualize work.
Scrum runs on sprints, which are two-week work cycles. During a Scrum cycle, your team starts with a backlog of work. Then, at the end of a sprint, you have a collection of finished work—no matter what that work is. That isn’t to say every team will finish every task assigned during a Scrum. But the goal of Scrum is to have a deliverable at the “end” of your sprint.
In fact, for teams that run Scrum on Kanban boards (or, as they’re sometimes called, Scrum boards), they frequently create a new board for every Scrum sprint. The reason for this is twofold:
Teams that create new boards for every sprint can start with a clean slate. This makes it easier for the Scrum Master and Scrum team to visualize the new work they have to do for each sprint.
Scrum Masters use past Scrum boards to track what work was accomplished during each Scrum cycle. Since a big reason teams implement Scrum is process improvement and efficiency, it can be helpful to look back and see what you’ve accomplished.
Unlike Scrum, Kanban boards don’t necessarily have to have a beginning or end date. In fact, at Asana, we most frequently use Kanban boards to represent ongoing processes. Because of the flexible nature of these visual boards, they make a great way to manage work intake processes or creative request projects, with no specific timeframe.
When you’re running a Scrum, it’s important to track work as it moves through stages. From the product backlog all the way to a completed deliverable, measuring the flow of work is one of the key ways to keep the sprint on track—and a huge part of your daily standup Scrum meetings.
But within a non-Scrum based Kanban board, board columns can represent a variety of work, not just work status. For example, you could create a Kanban board with “swimlane” columns for each member of your team to track the work they’re doing. Alternatively, a Kanban board could have columns representing the work that will be accomplished each month—or a retrospective Kanban board that captures the work that was previously accomplished in a set month. Kanban board columns can be whatever you need them to represent—unlike Scrum, which has more defined rules.
One of the core tenets of Agile methodology is flexibility and continous improvement—in fact, it’s one of the reasons product, engineering, and software development teams are so drawn to Agile philosophies. Continuous improvement is a big part of both Kanban and Scrum.
In Scrum, instead of working on a product for a long period of time and then shipping it once it’s perfect, the process of continuous improvement embraces “process over perfection.” During a sprint, teams work on and ship new products, features, or tools—then they continuously improve them if needed.
In Kanban, continous improvement applies more to the team and their processes than to individual tasks. Kanban challenges teams to always look for ways to incrementally change, improve, and—ultimately—evolve.
Even though collaboration might look different depending on the framework your team chooses, both Kanban and Scrum are, fundamentally, a way for teams to work better together.
In a Scrum framework, the strict rules are a great way for teams to gain visibility on each others’ work. The set roles, established meetings, and regular sprints make it easy for any member of the Scrum team to gain quick insight into what each team member is working on, the progress of that work, and what they can expect to accomplish at the end of each sprint. Better yet, if multiple teams at your company run Scrum, cross-functional teams can quickly orient and understand a Scrum board, since they’re all relatively similar.
Similarly, Kanban encourages visibility between coworkers. Once you decide what your Kanban board represents, teams can quickly and easily get at-a-glance insight simply by looking at the board.
There’s no exact rule for when your team should use Kanban, Scrum, or another form of visual project management. However, a good way to decide if Kanban is right for you is if:
Your team needs a visual project management system
You want an at-a-glance way to understand where a project stands
You’re not on an engineering, product, or software development team
You run ongoing processes and projects
Most of your work isn’t produced in short periods of time
Even if you choose not to run a Scrum framework, you can still pull inspiration from it. For example, maybe you don’t want your work to be limited to two week sprints—but keeping a backlog of work would be helpful for your team to better understand and prioritize tasks. The best part of Kanban is you can pull what works for you, and discard the rest.
Scrum can be a powerful way to organize and prioritize your entire process. Though not every team thrives on Scrum, you might benefit from Scrum if:
You’re on an engineering, product, software development, or Agile-based team
You think your team could benefit from a slightly more rigid structure
You have a large backlog of work to get through
Your team is motivated by quick deadlines and deliverables
Someone on your team is committed to being the Scrum Master
Remember: you can always run Scrum on a Kanban board. In order to host effective daily standup meetings and stellar sprint planning and retrospectives, you need a strong way to visualize work through stages and track all of your work in progress. Kanban boards can help you tackle your sprint backlog and organize the flow of work during a sprint, so every Scrum cycle is a success.
The good news is—you don’t have to choose. If Scrum feels right for your team, you can visualize your Scrum workflow in a Kanban board. Alternatively, if you’re not confident you need the entire Scrum framework, that’s ok too. You can use a Kanban board to keep your team organized and agile.
The most important thing is to find a framework—and a tool—that works for you. So, whether you’re using a Scrum or a Kanban framework, make sure your work management system is flexible enough to support your team, so you can get your best work done.