Skip to content

Blog /Teamwork /

Comparing Scrum, Kanban, and Lean Methodologies

There are multiple Agile approaches available to use, but when and how to use them depends on your product, team, and goals.

July 27th 2021

by Linda Ikechukwu

in Teamwork

In 2001, a set of experienced software developers came together to brainstorm. Their goal: a replacement for the waterfall methodology, which was no longer effective for building software in the internet era due to rapidly changing technologies and evolving consumer needs. They came up with twelve principles and a manifesto that became the basics of the agile methodology for software development.

Agile methodology is an umbrella term for any set of frameworks and practices that involve building and launching software in incremental phases. The three most popular such frameworks: Scrum, Kanban, and Lean, all come with their own advantages and disadvantages.

In this piece, we’ll give you an overview of each and help you decide which is the best framework for your team.


The Scrum framework is the most widely used of the agile development frameworks and is designed to deliver value to the customer throughout the development of the project. In Scrum, the customer or stakeholder is actively involved in each incremental phase of the development.

How Does It Work?

Scrum requires teams to have clearly defined roles and processes. A scrum team is made up of:

  • A scrum master who guides the rest of the team on complying with all the principles of the scrum framework in order to maximize the ROI of the whole process.
  • A product owner who is responsible for maximizing the value of the product delivered by the scrum team and communicating to the rest of the team the vision of the product, feedback received from the stakeholders, and what tasks to prioritize.
  • Other professionals who possess the necessary technical knowledge to build the project. This can comprise developers, designers, devops engineers, or QA testers.

Aside from the fact that Scrum requires the existence of a competent team, it also lays down some principles and events that must occur during the course of development.

Scrum and Sprints

Scrum teams commit to shipping features incrementally at the end of every sprint. A sprint is a fixed timeframe (not exceeding one calendar month) within which certain product features are worked on and shipped. The features to be worked on each sprint are determined during the sprint planning from the product backlog. The product backlog is a list that collects features requested by the stakeholders, prepared by the product owner and prioritized according to which is more important to the stakeholders.

Before a sprint starts, the team holds a sprint planning session. Sprint planning occurs at the beginning of every sprint, and it is during this time that the scrum team plans the upcoming sprint and decides on what should be worked on during the upcoming sprint. Every task selected is added to the sprint backlog, which is the list of tasks to be worked on during the sprint.

A mandatory event that occurs during a sprint is the daily scrum, which is a fifteen minute timeboxed meeting held at the same time every day. During the daily scrum, what was done the previous day and what tasks will be done in the present day are discussed, as well as anything that is blocking progress. Some teams opt for alternative approaches to the traditional standup, like holding them asynchronously and using tools like Status Hero to automate them.

Then, there is the sprint review which is an informal meeting held at the end of every sprint. During the sprint review, the scrum team and stakeholders discuss what was accomplished during the sprint, what has changed, and determine what to do next based on the outcome of that.

Finally, there’s the sprint retrospective meeting, where the team reflects on the proceedings of the previous sprint and establishes improvements for the next sprint. For tips on how to run an effective retrospective, check out our guide.

When to Use the Scrum Framework

Scrum is best suited for teams that like to work following a regular rhythm and provides a nice balance of structure and predictability while still allowing for frequent adjustments based on user feedback. It is one of the most common methodologies in many large companies today.

Scrum is also ideal for software development agencies who build software for their clients. The frequent demos and check points that come with operating in sprints ensures that teams and clients are always on the same page.


Kanban is a visual-based agile framework with a focus on optimizing the flow of work in a continuous delivery manner. Unlike Scrum, where software is delivered at the end of a sprint, in the Kanban framework, features are shipped and delivered as soon as they are completed without a regular schedule or predetermined due dates.

How Does Kanban Work?

The work process of the Kanban agile framework revolves around what is called a Kanban board. A Kanban board is a tool used to visualize the entire project roadmap in order to promote transparency and collaboration between team members.

This board can be physical, like a white board or virtual, using a tool such as Trello. The board is divided into columns which can broadly be classified into tasks to be worked on (to-do), tasks that are currently being worked on (WIP), and tasks that have been completed (done). Teams usually customize their workflow stages (columns) based on how they work.

Image of Kanban board, courtesy

The product owner communicates with the customers or stakeholders to compile features that should be added to the product, which is then organized in order of priority on the to-do column of the Kanban board. Individual features and tasks are represented by single cards and all the details of each individual task can be read by expanding the card. Team members can then pick or be assigned a task to work on, and move it right through each workflow stage until they reach the last stage which is usually done. By representing work items visually on a Kanban board, team members are able to see the state of every piece of work at any time.

The Kanban framework does not emphasize strict events in the course of building software, however, it requires that team members hold a daily stand-up meeting to discuss the progress of the workflow. Other principles that Kanban encourages in order to maximize efficiency are:

  • Have a Work-in-Progress(WIP) limit: It’s important for the team to limit the number of WIP tasks to the capacity of the team, in order to ensure that the team does not take on more than it can chew.
  • Maintain existing roles and responsibilities: With Kanban, organizations do not need to completely overhaul their work culture. They can maintain efficiency by staying within the confines of their existing setup.
  • Measure success: Cycle time deals with the amount of time it takes to move a task from start to finish. Improving cycle times indicates the success of Kanban teams.
  • Implement feedback loops: Feedback loops ensure that organizations are constantly responding to changes and improving their workflow. Kanban encourages the existence of periodic retrospective meetings for team reviews.

When to Use the Kanban Framework

Kanban is ideal for organizations that want to incorporate the benefits of agile but are not willing to make very drastic changes to their workflow. It’s also suited for projects in which priorities change on the fly, and ad hoc tasks can happen anytime.


The primary goal of the Lean methodology is to help teams build products with the bare minimum of what they need to succeed, while also eliminating waste. Waste in this context refers to anything that does not add value to the finished product—either directly or indirectly. This can be in the form of unnecessary meetings, product features that won’t add value to end users, or superfluous feedback loops. In general, if the end result can be achieved without a particular activity, then that activity is a waste.

How Does Lean Work?

Lean advocates for what is popularly referred to as the Minimum Viable Product (MVP) strategy. The team first releases a bare-minimum version of their product to the market, observing what the reaction is, what users like and don’t like, and then make adjustments or improvements based on that. This means that the initial idea for the product may not eventually be what the product matures into, based on the feedback received from end users.

The Lean framework is based on two major practices:

  • automation
  • continuous improvement

Any process that can be automated should be automated in order to eliminate waste and give the team time to focus on things that actually matter. Questions like: “what does customer data say?”, “how does this decision affect the end product?”, should be regularly considered as part of the continuous improvement practice. This feedback should be used to improve both the product and workflow processes, to ensure that the team continues to build a successful product that delivers exactly what end users need.

Just like Kanban, Lean framework does not emphasize strict events in the course of building software, however, it specifies some principles that should be adhered to in order to quicken delivery and bring higher value to the end-user.

  • Build quality in: Lean encourages software teams to build with measures that ensure quality is incorporated from the beginning to prevent unnecessary quality checks. Things like pair programming and test driven development.
  • Amplify knowledge: Teams should retain valuable learning in the form of proper documentation of tools, processes and components, code reviews, knowledge sharing sessions, and thoroughly commented code. This helps to reduce knowledge gaps within the teams and thereby reduce the incident of waste events.
  • Delay commitment: Lean teams should always strive to build software in a flexible way, so that when new knowledge is made available, engineers can act upon it without having to rebuild what has been done earlier. For example, hold off on making binding commitments (such as main architectural decisions) as late as possible.
  • Deliver fast: Put value into the hands of the customers as fast as possible. Build a simple solution, put it in front of customers, and enhance incrementally based on customer feedback.
  • Respect people: This principle defines that everybody should have a voice, especially those closest to the product, like the engineers. It empowers employees to have a say and the autonomy to make decisions.
  • Optimize the whole thing: This principle focuses on optimizing the workflow process, starting with the fundamentals. Hire professionals who are committed to continuous improvement and can deliver as much value in the shortest amount of time and in the most efficient way possible.

When to Use the Lean Framework

Lean focuses on market validation and building a successful product which users will find useful. Lean is ideal for new product development teams or startups who are venturing into a relatively new niche, haven’t formulated a finished product, don’t have a huge budget, and need to validate their idea. It helps such teams build, fail, and deliver software faster and cheaper.

Scrum vs Kanban vs Lean

Scrum Kanban Lean
Ideology Solve complex problems while delivering valuable products Use a visual board to improve workflows and processes Maximize product value to customers by reducing waste
Delivery Iteratively at the end of each sprint Continuously Continuously
Rituals Timeboxed rituals such as sprints, daily scrum, sprint planning, sprint retrospective and sprint review No timeboxed rituals except for the daily standup. Demos can happen at any time. No standard or compulsory rituals but encourages daily standups, retrospectives, and reviews.
Roles Scrum master, product owner, development teams No formal or predefined roles No formal or predefined roles
Metrics Team velocity: Amount of work completed in a sprint Cycle time: Amount of time it takes for a card to move from the first column to the last column Lead time: Time between receiving feedback and implementing it
Change philosophy When a sprint has started, nothing should be dropped or added Priorities can change at any time Priorities only change if it is on par with customer feedback
Practices/Principles Sprint planning, sprint, daily scrum, retrospectives Visualize the flow of work, limit work in progress, implement feedback loops, maintain existing roles and responsibilities Build quality in, amplify and share knowledge, delay commitment, deliver quickly


While this is a comparison post between the Scrum, Kanban, and Lean frameworks of the agile software development methodology, you should understand that no one method is better than the other. Each has its pros and cons, and sometimes they even complement one another. Most modern teams often use a combination of two, or even all three frameworks together. Discover what works for your team and flex the system accordingly.

More in Teamwork

Subscribe to The Steady Beat

A weekly-ish round-up of hand-picked articles and resources for people who make software products: designers, engineers, product managers, and organizational leaders.

Subscribe now