Search This Blog

Saturday, August 30, 2014

Differences between Kanban and Scrum

Recently when attending the 5-day Agile 2014 conference in Orlando, Florida, I had an opportunity to discuss various agile implementations. Some of the discussions centered on selecting the right type of agile methodology to consider for software implementations from extremely regulated medical devices industry and government projects where Scrum was considered prevalent. Then, when I found in my network of work and friends, there were questions that revolved around using Kanban because Scrum wasn’t working.

Having used Kanban and Scrum, I wondered why there is still confusion among the early adopters of Agile and why Kanban would be considered as a substitute for Scrum. Unclear understanding of agile concepts may actually lead to failure despite the methodology as discussed in one of my networking seminars on some impediments to agile’s failure (Readers can visit!video/c1emu for more information). So, I focus below on a comparative study of the basic premises between Kanban and Scrum. I hope this article captures the essence of these approaches demystifying the confusion and helping in the selection of the right approach for the challenge at hand.

Management focus
Maximize resource usage avoiding delay and enhancing accountability to support flow.
Consistent delivery in the cadence of execution, as the features in the product backlog is delivered.
Operating rhythm
No time-boxed iterative development exists.
Time-boxed iterative development – usually two to four weeks.
Granularity of work
Focus is at the task level for which the scope of work is generally known.
Focus is at the user story level for which the scope may not always be known, requiring it to be estimated before tasks can be identified and taken up by the team.
Agile Estimation & Planning
Estimation is generally not done. There is little to no ambiguity on the task that any member of that team should be able to take on the next available task and execute it.
User stories are estimated. Then, they are prioritized and risk adjusted so that these are included in the release and iteration planning.  
Value Delivery
Every task completion may not necessarily add minimally marketable value to the customer. Task identification and dependency require careful coordination.
The cadence of release and iteration planning focuses on adding minimally marketable feature through the scrum cycle. The self-organized team determines the task identification and dependency.
Progress Tracking
Flow of items throughout the lifecycle limiting delay. This is why the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat Yourself (DRY)” focuses on maximizing work not done
Focus is on tracking the velocity measuring the user stories done and delivered to customer in an iteration
Utility value
Better for managing workload and resource management.
E.g.: How many projects of different combinations can be taken up by a project?
Better for managing products, programs, and projects.
Thoughts to consider in software development
Use of Kanban for software development may impede flow if all the units don’t consume the work produced at the same speed. Therefore additional processes must be in place to support Kanban.
E.g.: QA not having capacity to test code developed by engineering team. If QA’s capacity comes from the fact that more defects are found in the build, then, more granularity in tasks to ensure proper code review, unit testing, and documentation are processes that the organizations must have in place.
Implementing Scrum doesn’t mean ability to write user stories and avoiding documentation completely! This requires a management shift to ensure critical thinking on the product, program, and projects. If iterative delivery is not understood by the management and client, then, Scrum is not an option to consider.

In summary, Kanban is similar to Scrum in that they both are light-weighted approaches but the operating philosophy is different. Scrum focuses on the work being delivered to customer through multiple iterative deliveries of minimally marketable value by assembling cross-functional, skilled, and self-organizing team. Kanban, on the other hand, focuses on the visualized workflow where flow is maximized by limiting what gets worked on by the team.   


  1. Good comparison, thank you.

    In "Agile Estimation & Planning" row. I think Kanban has a philosophy of sizing all work elements to be approximately the same size. What should flow in Kanban should be valuable work such as stories.

  2. Good point Ahmed. When Kanban is used for software development, it is critical to actually keep this in mind so that the next available task can be picked up avoiding delay. The same size will also help in ensuring that one member doesn't work too long on a particular task indicating incorrect estimation of that story or task.