BigPicture is now on ! Enjoy enterprise-grade Program & Portfolio Management, now fully integrated with boards and workspaces.  Try it now
May 11, 2022

Kanban vs. Scrum. Who wore it best?

Project Management
BigPicture Team

Scrum and Kanban – the two similar frameworks. One was popularized by Japanese car manufacturers around the 1950s. The second came around the beginning XXI century to take the IT world by storm. But which one is better? Is it even measurable? As usual, every framework provides different solutions to the specific needs of each team. This means, that the true challenge is choosing and implementing the right solution.

Introduction to Kanban and Scrum

What is Kanban?

We’ve already described Kanban in more detail in our article about the iterative and implementation approaches. Kanban roughly translates to “sign” and was developed in Japanese Toyota factories around the 1950s by Taiichi Ohno, an industrial engineer. Kanban controls manufacturing, tracks production, and orders new shipments of parts and materials. As a visual tool, it pinpoints the actions needed to keep the process flowing. One of the main goals of Kanban is to limit the buildup of excess inventory in the production process. We would call it to scope creep, as Kanban was successfully adopted by IT teams.

How does Kanban work?

As a primarily visual tool, let’s see how Kanban works in practice:

What is Scrum?

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It breaks your work down into smaller, more manageable chunks, and assigns specific roles and responsibilities to certain people. There are roles like Scrum Master, Product Owner, and Scrum Team.

Scrum Master, regarded as a master of ceremony, fosters an environment where:

  • A Product Owner orders the work for a complex problem into a Product Backlog.
  • The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  • The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  • Repeat the whole process again and again. 

How does Scrum work?

Scrum is simple. Try it as it is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon the collective intelligence of the people using it, rather than providing people with detailed instructions. It builds a framework that can be filled by teams’ specific needs and requirements.

Kanban vs. Scrum – Roles & Accountability

Scrum vs. Kanban –  Planning and Workflow

Commitment to Kanban and Scrum

Both frameworks share the common idea of every Agile-based approach – their rules aren’t written in stone. You can easily change and adopt some elements of these frameworks to fit your team’s needs, as the sole foundation of Agile is to increase business value by any means, not to play by the rules. Still, Scrum demands more commitment in three key areas.

The first are roles. Scrum Teams are self-governing entities, that have specific roles to fill (like Scrum Master or Product Owner) to make sure there is some kind of checks and balances. Meanwhile, Kanban doesn’t require you to appoint specific roles to anyone. The only additional role can be Agile Coach to ease the transition from Classic to Agile approach.

The second approach are ceremonies. Scrum has a set of events like Planning, Review, or Daily – they are necessary to keep the workflow on track, avoid scope creep and learn from past mistakes. Kanban has only practices keeping workflow visualization to keep every interested party up to date.

Last but not least, there are timelines. Scrum is built around sprints, that last 2 to 4 weeks and are focused on items that are in the backlog. Kanban is uninterrupted – it lasts as long as needed (usually to deliver specific business value), meaning it must be regularly updated.

Core Key Performance Indicators (KPIs)


Meetings and Events

As mentioned above, meetings and events are typical for Scrum. There are 5 main events:

  1. Sprint Planning.
  2. Sprint.
  3. Daily Scrum.
  4. Sprint Review.
  5. Sprint Retrospective.

We described them in greater detail in this article.

Kanban Board vs. Scrum Board

Tracking and Analyzing Work Progress, and Work Estimation

Both frameworks use boards to track the progress of your team, but in different ways. Scrum is based on Story Points – they let you know about the capabilities of your team members, if they can handle more work or if the scope creep lurks behind the shadows.

Kanban is based on the Work In Progress Limit (WIP). WIP is the number of task items that a team is currently working on. It frames the capacity of your team’s workflow at any moment. WIP limits the maximum number of work items in the workflow. Work In Progress is one of the key principles of Kanban.

Cadence, iteration, and scheduling

Cadence is the umbrella term, that refers to the duration of Sprint or Iteration. It may last one week, two weeks, or four weeks. Iteration is similar to Sprint, but, like Cadence, is a broader term that describes work periods in other Agile frameworks like Extreme Programming and SAFe®. In Scrum, work scheduling happens during the Sprint Planning phase. During this event, team members can both select the items to the backlog and assign story points to them.

What about Kanban, you may ask. Well, the workflow is based on capacity – the amount of Work In Progress tasks team members are working on right now. Time periods don’t have any actual use in Kanban.

Relationship between Scrum and Kanban methodology

Although similar, Kanban and Scrum differ in a crucial way. That is the representation of team workflow – Kanban centers around visualizing tasks, while Scrum structures workflow and team culture to deliver projects in short timelines. But they don’t exclude each other – some teams adopt Scrumban. It’s a combination of both frameworks, designed as a transition tool from Kanban to Scrum, it combines Kanban board with Scrum Events. This is a pretty rough description of Scrumban, but don’t worry – this term will be back on our website.

Kanban or Scrum. Who Wins?

The hardest question to answer about Agile frameworks is their superiority. Mostly due to its pure subjectiveness – each team has different needs, workflows, capabilities, and capacities. Kanban is a great framework for existing projects because it does not disrupt the workflow. Also, it visualizes the tasks that must be done and increases productivity.

Scrum lets you divide huge tasks into smaller, more manageable chunks of work, as well as teach your team members how to cooperate, express their concerns, and be more productive. Scrum is usually considered a cost-lowering framework that makes the business value delivery faster but needs proper implementation.

It’s difficult to pinpoint the obvious winner – as usual, the most popular answer is “it depends”.

Work in Progress (WIP) Throttling Methods

  1. Forecasting, or based on previous experiences – it’s the best way to estimate, how many eggs you can put into your team’s basket. Forecasts are a popular and reliable method if done correctly.
  2. Just In Time Delivery – management strategy that aligns orders with production schedules. Increases efficiency and decreases waste. This method requires producers to forecast demand accurately.
  3. Stick to the WIP Limits – limits are the maximum amount of work that can exist in each status of a workflow. Keeping eye on it allows you to react faster and helps you avoid bottlenecks.
  4. Right people in the right place – Kanban isn’t only about technicalities. Assign tasks to people that will work on them in the most efficient way possible. It may require some experiments, and sometimes failed, but in the long run, it will improve the way you assign tasks.

Making changes to iteration

Changes are usually adding or removing items from your backlog. With Scrum, it’s a dangerous game. During the Scrum Planning event, the team members decide, how many items and story points they can work on to reach their quota. That seals the deal – adding items to your backlog during the sprint can result in scope creep. This is a grave mistake, that results in overworking and potential crunch, and can result in lower morale and delays in delivery.

Kanban, on the other hand, is a continuous framework – meaning you do not have planning events or timeslots you must fit into. You just add the items into your workstream. Hence, you must be careful about your team’s capacity and remember about Just In Time Delivery.

What between iterations?

Each end means new beginnings – and the best beginnings are the ones, that grow directly from past experiences. Within Sprint, you can assess teams’ work during the Review Event, or much more people-oriented Retrospective. While the Review is the more formal thing and checks what was done and what wasn’t, the Retrospective is an opportunity to talk more in-depth about things we’re happy and unhappy about, like communication, task assignment, or even the number of items and story points. It’s a great way to dissect the workflow and spot the potential problems, address them and solve them.

Kanban is a continuous process. It doesn’t have specific roles, like Scrum Master or Product Owner. This means you have to find the opportunity to learn, talk, and add new work during the workflow. It sounds rigid, but properly implemented it helps you to keep up the delivery time and bring the business value when it’s needed.

Task sharing in Scrum and Kanban

Among many rules, cross-team cooperation is one of the necessities in Scrum. People with different backgrounds must work together and use their experience to their advantage. This way they can deliver many different items within one Sprint. Eventually, they easily swap tasks with other teams or ask for help.

Kanban meanwhile does not force you to have cross-teams. On the contrary, it allows teams to specialize in a specific feature or part of the product. Like in a factory, one team can be focused on building, the second is building the body, the third works on the interior, etc.

Good practices when working with Agile methodologies

  1. Stay open-minded.
  2. Talk to team members.
  3. Don’t follow the book to the T.
  4. Adjust the framework to your needs.
  5. Lay the foundation of your work with previous experience.
  6. Don’t hesitate to experiment.
  7. Avoid crunch at all costs.
  8. Keep every interested party up-to-date.
  9. Don’t oversell your product.
  10. Avoid fixed deadlines.