Kanban vs. Scrum vs. Agile – Part 1: Which PMI framework to choose?



Recently I overheard a conversation where someone asked the question: "Is Scrum better, or Kanban?", "How do I need to execute my project? Using Kanban or Scrum?". Sometimes there are also questions like “Is Kanban agile?” or “What about Scrum vs. agile?”. These questions, as well as many different opinions, put many managers in a dilemma about which framework to embrace. 

The quick answer is: Scrum and Kanban each have their own benefits. You have to select the appropriate one for the particular project. There is no “one fits all” concept. Let’s start by sorting out all those initial questions. 

Scrum (or Kanban) vs. Agile?

First we have to identify the relationship among those three terms – “Agile”, “Scrum” and “Kanban”. What are they and how are they related to each other? I like the very simple explanation of Scrum vs. Agile which Matthias Marschall wrote on his blog:

“Asking for the differences between Scrum vs. Agile or Agile vs. Scrum is like asking for the differences between Water and Ice. Ice is water in a specific physical state. The same could be said about Scrum vs. Agile. Scrum is agile in a specific shaping. It is an agile process framework. Scrum and Kanban in software development are both specific shaping of an agile software methodology. While Scrum vs Kanban or Kanban vs. Scrum is comparing two agile methodologies, Scrum vs Agile is comparing a concrete example with its fundamental principles.”

What is Scrum?

Scrum focuses on team collaboration and following the rules that will help create team structure.  By doing so, the team will be able to focus on their work and deliver high quality results on time. Scrum allows business stakeholders to prioritize, and even change the requirements. Scrum can allow such changes by using an iterative and incremental approach, known as "timeboxing". Scrum also focuses on receiving feedback from the business as early as possible (at the end of each of those iterations) to minimize the cost of “overwriting”. 

So, Scrum in a nutshell will:   

  • Split your organization into small, cross-functional, self-organizing teams.
  • Split your work into a list of small, concrete deliverables by assigning someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
  • Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
  • Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
  • Optimize the process by having a retrospective after each iteration.

What is Kanban?

Kanban is another technique for managing a development process in a highly efficient way. Kanban was orginally based off Toyota's 'just-in-time' (JIT) production system process. Back in the 1940s, Toyota optimized its engineering process by modeling it after how supermarkets stock shelves.

Most of the time producing software is a creative process, different from that of stocking shelves or manufacturing cars. But for some types of software development projects it can be applied successfully.

Kanban primarily follows several core principles:

  • Visualize the workflow - which is also used in Scrum. For example, Jira is a useful tool which supports both methodologies.
    • Divide the work up by writing each item on a card and putting it on the wall
    • Use labeled columns to illustrate where each item is in the workflow
  • Limit WIP (work in progress) – assign explicit limits as to how many items may be in progress at each workflow state. In manufacturing, the problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP, but how is this really applicable to a business software development process?
  • Measure the lead time -  The lead time is the average time to complete one item, sometimes called “cycle time”. You can optimize the process by making the lead time as small and predictable as possible.

In 2009, Henrik Kniberg published a version of a "practical guide" to comparing Kanban and Scrum. In his article, Kniberg presents an outline of the ways Kanban and Scrum are similar, and how they differ.

At the end of the article, he does a comparison and contrast for both approaches. Here’s a quick excerpt from the book:


  • Both are Lean and Agile
  • Both use pull scheduling
  • Both limit WIP
  • Both use transparency to drive process improvement
  • Both focus on delivering releasable software early and often
  • Both are based on self-organizing teams
  • Both require breaking the work into pieces
  • In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)




Timeboxed iterations prescribed.

Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.

Team commits to a specific amount of work for this iteration.

Commitment optional.

Uses Velocity as default metric for planning and process improvement.

Uses Lead time as default metric for planning and process improvement.  

Cross-functional teams prescribed.

Cross-functional teams optional. Specialist teams allowed.

Items must be broken down so they can be completed within 1 sprint.

No particular item size is prescribed.

Burndown chart prescribed

No particular type of diagram is prescribed

Work In Progress (WIP) limited indirectly (per sprint)

Work In Progress (WIP) limited directly (per workflow state)

Estimation prescribed

Estimation optional

Cannot add items to ongoing iteration

Can add new items whenever capacity is available

A sprint backlog is owned by one specific team

A Kanban board may be shared by multiple teams or individuals

Prescribes 3 roles (Product Owner / Scrum Master / Team)

Doesn’t prescribe any roles

A Scrum board is reset between each sprint

A Kanban board is persistent

Prescribes a prioritized product backlog

Prioritization is optional

Some teams even blend the ideas of Kanban and Scrum into "scrumban." They take fixed length sprints and roles from Scrum and the focus on work in progress limits and cycle time from Kanban.

We will continue the Scrum and Kanban discussion in upcoming posts. Stay tuned ....

Contact us