Difference Between Scrum vs Kanban

The origins of Scrum and Kanban can both be traced back to Lean Manufacturing, an approach to automotive manufacturing first popularised by Taiichi Ohno and Toyota.

The purpose of lean manufacturing is to minimize waste, which in turn reduces costs and maximizes productivity. This idea of maximising valuable outcomes and minimising waste is at the heart of Agile and thus at the core of both Scrum and Kanban. The divergence between both comes when determining why we would use one approach over the other.

If you plan to build software to solve a problem, but you expect you will need to be flexible in what you deliver to accommodate changing needs over time, Scrum is recommended.

Scrum framework was primarily a response to growing challenges in the software industry to take a flexible approach to software delivery. The industry was used to an inflexible, process heavy but low risk (scope/schedule/resources) approach to delivering software. E.g. Waterfall: Large upfront planning and design followed by strict handoffs and minimum deviation from the plan. This approach worked well if you could gather all your software requirements upfront, assume them to be facts, build a solution based on those ‘facts’ and present the finished work or working software to the business/user/stakeholder (referred to as ‘end user’ from here) at the end of the project for review in UAT. However in this new digital reality, the software industry recognised that when a user eventually viewed ‘working software’, often it was not what they thought it would be or requirements had changed in the interim.

The software industry needed an approach that allowed continuous interaction with the end user to ensure the ‘right thing was being built’ and not just ‘build the thing right’. It also needed to get working software in front of end users as frequently as possible to check it is what they needed and make any necessary changes with minimum waste. Scrum is an empowering, pull system that provides an approach which follows 4 basic concepts:

  1. Build software iteratively: From 1-3 weeks (shorter the better), produce software which the end user can review and provide feedback.
  2. Build software incrementally: Build units of actual working software that is functionally complete. Each unit is building upon the previous unit, and all are potentially shippable.
  3. Collaborate: End Users must be fully engaged in the software process rather than just at the start and the end. IT are experts on how to solve a problem. Business are experts on what is the next most important problem to solve.
  4. Sustainability: Scrum is based on empiricism i.e. past performance is a clear predictor of future performance. Persistent Scrum Teams know their capacity and velocity, and they can repeat it indefinitely. This allows for much more accurate future planning.


If team deliverables tend to be repeatable or similar in size and type, come from multiple stakeholders and can be prone to bottlenecks e.g. Application Support, then a Kanban approach is recommended.

As previously stated, Scrum and Kanban have origins in Lean Manufacturing. However Kanban, rather than being a framework like scrum that is adopted by a team, it is an ongoing improvement process where lean principles are adhered to in order to minimise waste and maximise productivity. Kanban is also an empowering pull system. However, rather than focus on short iterations producing working software which can be presented to the end user for review, Kanban’s main goal is to visualise all work in progress and maximise flow. The Kanban board is at the heart of this process improvement:

  1. Seeing the progress of all work.
  2. Identifying where work is being held up e.g. developers are producing too much work for testers to complete and is creating a bottleneck in test, that will only get bigger if not addressed.
  3. Putting measures in place to ensure work flows across the board in a predictable fashion and thus allow for capacity planning. E.g. Implementing WIP – Work in progress limits.

In summary, the goal of Kanban is to continuous improve the flow or work and significantly increase predictability of velocity and capacity of the Kanban team. While those are also goals of Scrum, Scrum includes the addition of iterations and increments of working software to allow end users to review at regular intervals

(Visited 14 times, 1 visits today)

Leave A Comment

Your email address will not be published. Required fields are marked *