Agile, Lean, Scrum, Kanban: these terms are all used to describe very similar project management approaches, and adding to the confusion, they’re often used interchangeably. People refer to Scrum ceremonies as Agile ceremonies, use Kanban boards for Scrum. If you’re new to Agile, it gets confusing quickly.
If you’re struggling to understand the key differences between Scrum and Kanban—or to pick the right approach and/or tool for your team—we’ve put together this Scrum vs. Kanban comparison guide to help you get up to speed and make the right decisions.
What Is Agile?
Before we jump into defining Scrum and Kanban, it’s helpful to have a general understanding of Agile since Agile is at the core of both methodologies. However, unlike Scrum and Kanban, Agile is more of a philosophy than a project management methodology.
Agile was developed in 2001 by a group of 17 software developers who called themselves “The Agile Alliance.” Over the course of two days, these developers wrote The Agile Manifesto, a set of guiding principles that encourage things like consistent progress and collaboration over process documentation and contract negotiation.
Prior to the release of The Agile Manifesto, most software development projects followed Waterfall, a project management methodology where all of the requirements for projects were created and estimated before development began. Development teams would commit to doing a set amount of work in a set amount of time.
This created several issues:
- If problems came up during the development process, they were difficult to address because teams had already committed to a specific scope of work.
- Because the requirements for projects were fully written in advance, development teams received very little input from project sponsors.
- Because the development team was working in a silo, project sponsors often didn’t see the outcome of any development work until development was complete, which often led to project sponsors discovering problems with the finished product.
The Agile Alliance felt that a better approach to development would be for teams to work collaboratively with project sponsors over the course of the development timeline, gathering requirements and creating code using an iterative approach.
An iterative approach, they felt, would give developers a way to address issues that arose during development and allow project sponsors to see what was being developed while it was being developed and weigh in with any concerns before it was too late to address them.
What Is Scrum?
While Agile is a philosophy that advocates for a collaborative, iterative approach to software development, Scrum is a methodology that’s commonly used to put Agile philosophy into practice.
Scrum provides a framework that project sponsors and software developers can use to work together and follow Agile’s guiding principles. It was developed by Ken Schwaber and Jeff Sutherland, two members of The Agile Alliance, and described in The Scrum Guide.
A Scrum team consists of three roles:
- Product Owner: The Product Owner is a representative of the project stakeholders who is available throughout the development process to answer questions, review completed work, and prioritize requirements. The Product Owner’s involvement with the development team helps teams adhere to Agile’s push for more collaboration.
- Scrum Master: The Scrum Master leads the development team, keeps everyone focused on their work, teaches others on the team about Scrum, and leads all of the Scrum meetings. He/she operates as the conductor of the team, making sure everything is running smoothly and everyone is following the rules of Scrum.
- Development Team: The Development Team is a group of three to nine developers who are responsible for doing the work that’s described and prioritized by the Product Owner.
The Development Team works from a prioritized Product Backlog (list of project requirements) that’s composed of User Stories. User Stories are Scrum’s method of writing requirements that, instead of writing what needs to be done, explains how what the Product Owner is asking for will benefit the user of what’s being developed.
User Stories always follow a specific format: As a [who], I want to [what] so that [why]. For example:
As a MeisterTask user, I want to be able to drag and drop cards within lanes on my board so that I can prioritize the tasks in my lists.
Development work is completed in an iteration called a Sprint—a period lasting between one week and one month when the team focuses on a set, planned amount of work. That work is planned during a Scrum ceremony called Sprint Planning where teams decide on and plan the work for however many User Stories they believe can be completed during the Sprint.
During the Sprint, Scrum teams have a Daily Scrum meeting at the beginning of each day where each member of the Development Team answers three questions:
- What did you work on yesterday?
- What will you work on today?
- Are there any impediments blocking you from completing your work?
At the end of each Sprint, the team holds two meetings. The first is the Sprint Review where the Development Team demos the work completed during the Sprint to the Product Owner for sign-off. The second is the Sprint Retrospective where the team seeks to improve in future sprints by answering three questions:
- What went well during this Sprint?
- What didn’t go well?
- What should we do differently next Sprint?
In addition to helping teams practice Agile, Scrum is designed to make sure that everyone is working at a consistent pace throughout the project, the work being completed is exactly what the project sponsors want, and teams are consistently improving over the course of a project.
What Is Kanban?
Kanban was originally developed by Taiichi Ohno, an industrial engineer at Toyota, to create a more efficient manufacturing process. It was later applied to software development by David J. Anderson in his 2010 book Kanban: Successful Evolutionary Change for Your Technology Business.
Kanban uses an assembly-line approach to move work through a queue. Like Scrum, Kanban has a backlog of prioritized project tasks, but rather than planning work in Sprints, team members grab the highest-priority task in the backlog that’s ready to be completed.
The core feature of the Kanban Method is the Kanban board. As in manufacturing where products are built in pieces in an assembly line, Kanban tasks move through a series of lanes as different pieces of work are completed.
For example, if each task in your backlog requires backend development, then frontend development, then testing, then approval, your Kanban board might look like this:
Tasks would move from one lane to the next as each set of work is completed.
Another key feature of Kanban is Work-In-Progress (WIP) limits. Let’s say, for example, that your backend development team is working at a much faster rate than your frontend development team. The frontend team could end up with dozens of tasks in their queue while your testers sit around with nothing to do.
WIP limits set a limit on the number of tasks that can be in any one lane at a time. When a team’s WIP limit is reached, it serves as a signal that there’s a blocker for that team.
To remove that blocker, other members of the team could help to clear out the frontend development queue, or it might serve as a signal that your team is imbalanced: you need fewer backend developers and more frontend developers.
Finally, while Kanban lacks the specific retrospective ceremonies of Scrum, a core principle of the methodology is continuous improvement. Teams need to reflect incrementally to look for ways to improve the flow of their work, remove blockers, and streamline their processes.
Kanban vs. Scrum
As you have probably already seen, Scrum is a complex and strict methodology with a lot of rules and a highly specific framework that teams must adhere to. Kanban is a leaner approach with fewer rules and a simpler framework. Both, however, help teams adhere to the core principles of Agile: collaboration and flexibility.
Choosing which methodology is right for your team requires you to consider a few different factors:
- How much structure does your team need? If your team works better with detailed rules and processes, Scrum is probably the better approach. Kanban is more flexible.
- Do you have dependencies on other teams/projects? Scrum’s detailed planning processes are more efficient when your work has lots of dependencies on individuals and teams outside of your Scrum team. Kanban works better when all of your work can be completed by your team.
- Do your tasks have dependencies on other tasks? Scrum’s planning works better when some items in your backlog must be completed before others can begin. Kanban works better when each task can be completed in isolation of others.
Neither methodology is inherently better than the other. The “right” choice for your team depends on your organizational structure, team preferences, and the specifics of your work and project.
And you don’t even necessarily have to always adhere to one or the other methodology. In fact, teams that have been working together for a while can easily switch back and forth between the two methodologies to accommodate different types of projects and sets of work.
Scrum and Kanban Outside of Software Development
While Scrum and Kanban have their roots in software development, the philosophies and frameworks of the methodologies are useful in lots of different industries and disciplines.
For example, Kanban works really well for content marketing. Most content marketing workflows start with a backlog of ideas—an editorial calendar—that are planned by a content marketing manager. From there, they may go to an SEO specialist, then to a writer, then to an editor, then to a designer before they’re published.
Kanban can also be a helpful approach for HR teams during the hiring process. Because different tasks need to be completed by different individuals (some by HR, some by the hiring manager) at different times, Kanban is helpful for streamlining that collaboration.
Scrum could be used by a design team that’s working on redesigning a website. Say you need to release the redesign in six months, and there are lots of tasks that need to be completed as part of that project:
- updating site-wide elements such as navigation menus, buttons, and calls-to-action
- updating the images used on individual blog posts and landing pages
- revising the layout of all site landing pages
- updating your company style guide to reflect your new guidelines
Due to the hard deadline and the design team’s need to work with other teams like development, sales, product, and marketing, Scrum could be a perfect fit for managing this project.
Most large, dependency-heavy, and complex projects—regardless of the discipline that’s spearheading the project—can benefit from the structure Scrum provides. And most workflows that require input or attention from multiple individuals can benefit from the assembly-line approach of Kanban.
Choosing the Right Scrum and Kanban Tools
There are tons of tools to choose from if your team is practicing Scrum and/or Kanban. Some are specific to Scrum and have features for Scrum-specific ceremonies like Sprint Planning and Release Planning and use Scrum terminology like User Stories and Sprints.
And while Scrum-specific tools work well if you think your team will only ever use Scrum, they’re less effective—and far more cumbersome—if you want to take the leaner Kanban approach.
Kanban tools offer more flexibility for teams that plan to use both methodologies at different times depending on the specifics of the work they’re doing.
Obviously, Kanban tools are designed for and work well with the Kanban Method. But they work just as well for Scrum. Many teams run Scrum using a Kanban board—a practice that’s sometimes referred to as ScrumBan.
A Kanban board can start with a “Product Backlog” lane where all of your incomplete User Stories live. Product Owners work in that lane, creating all of the User Stories needed for the project and prioritizing them by dragging and dropping cards in priority order from the top of the list to its bottom.
When it’s time for Sprint Planning, the Development Team can pull the User Stories into the “Sprint Plan” lane to create a plan for the upcoming sprint. They can also add estimates if needed and use checklists to break User Stories down into individual tasks.
When the Development Team is working on a user story, team members can move the card into an “In Progress” lane. You can also add a “Blocked” lane for user stories that cannot be completed because of a blocker that the Scrum Master needs to help remove.
Finally, you can create a “Done” or “Acceptance” lane for User Stories that need to be demoed to the Product Owner for approval. And when approval is received, each card can move to a completed lane for the Sprint in which the User Story was completed.
In addition to Kanban tools offering a more flexible approach to both Scrum and Kanban, they’re easy for interested parties outside of the team to understand. Project managers, project sponsors, and team managers can view the team’s board at any time to get a quick, overall view of the project’s progress.
This is great for teams, too, because it usually means fewer status update meetings.
Start Building More Agile Teams and Processes
At its core, Agile is focused on continuous improvement. For The Agile Alliance, the improvements they sought to make were focused on collaboration, flexibility, and incremental delivery. But those may not be the improvements your team needs to make. And if so, that’s okay.
Back when I worked as a Product Owner, I heard people say countless times “If you’re doing X, you’re not Agile.” But Agile itself isn’t a rules-based system; it’s a system of principles. And those principles can be applied by any team in any way that works for them as long as the goal is continuous improvement.
So my advice is that as you investigate the different Agile methodologies, worry less about following the books and focus more on doing what’s needed to fix the problems that are plaguing your team and delaying your progress.
The definitions and the processes are all just documentation, and as The Agile Manifesto says, working software—or, in other words, the end result—is more important than defining how you get there.
