"Scrum vs. Kanban" is a popular question, but the wrong one. Scrum is a framework for organizing product development. Kanban is a management approach for the flow of work. Both can only be meaningfully compared when it's clear at which level the comparison takes place. When developing your custom software, we value both methods.

Why the Scrum vs. Kanban comparison needs a clear separation

The official Scrum Guide describes Scrum as a framework with fixed roles, events, and artifacts.[^1] In contrast, the official Kanban Guide describes Kanban as a collection of principles, which thus prescribes significantly less structure.[^2]

A fair comparison therefore requires two steps. First, you understand both approaches individually, then you apply the appropriate criteria for your project. Agile web development forms the common framework within which both approaches operate.

Why traditional software development reached its limits

Before Scrum and Kanban emerged, most software projects followed a fixed sequence with consecutive phases for requirements, design, development, testing, and delivery. This model is called "Waterfall" because each phase must be completed before the next one begins.

The problem usually only became apparent late. Customers often saw the first working software only after months or years, when requirements had long since changed. Errors from the conception phase were often only discovered during testing, when correction was already expensive.

Which problems rigid phases caused

This approach led to three particularly common problems. First, customers received a visible result too late to take early corrective action. Second, responsibility was distributed across many documents and handovers, without anyone being concretely responsible for the overall result. Third, the fixed sequence of phases made every later change complex and expensive.

Precisely this experience characterized the early 1990s in the software industry. Teams searched for ways to receive real feedback earlier, instead of only experiencing it at the end of the project.

Scrum thus emerged as a direct response to the weaknesses of the waterfall model.[^1]

How Scrum concretely solves the problems of waterfall

Every element of Scrum addresses one of the three problems from the waterfall model. The so-called "Sprint" ensures that customers see a real result every few weeks, instead of only at the end of the project.

The "Increment" is this result: a usable piece of software at the end of each sprint. It replaces the long wait for a finished overall product with regular, verifiable intermediate stages.

The three roles solve the second problem, distributed responsibility. The "Product Owner" decides what has priority. The "Scrum Master" ensures a functioning process. The "Developers" deliver the increment. This way, every decision remains clearly assigned, unlike the many handovers in the waterfall model.

Roles, events, and artifacts at a glance

Scrum defines three roles that together form a Scrum team. Each role carries its own responsibility. No role decides alone.

The Sprint forms the fixed rhythm, typically two to four weeks long. Around it are fixed events such as Sprint Planning, Daily Scrum, Sprint Review, and Retrospective.

The most important elements at a glance:

  • Roles: Product Owner, Scrum Master, Developers
  • Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
  • Artifacts: Product Backlog, Sprint Backlog, Increment

Why fixed sprints create predictability

A fixed sprint rhythm makes progress predictable. Stakeholders know exactly when they can see and evaluate the next increment.

However, this predictability has its price. New requirements typically wait until the next sprint. Spontaneous changes in the middle of a sprint are not intended.

What Kanban achieves and what it was built for

Kanban doesn't organize roles or cycles, but the flow of work itself. Instead of fixed structure, there are principles that can be adapted to an existing system.

How Kanban came from manufacturing to software development

Kanban doesn't originally come from software development. Engineer Taiichi Ohno developed the principle in the 1950s at Toyota to couple production more closely to actual demand.

Software developer David J. Anderson transferred this idea to knowledge work from 2004, first in a team at Microsoft.[^2] Unlike Scrum, Kanban didn't replace a team's existing process. It only made it visible and improved it step by step.

Kanban thus addressed a different problem than Scrum. Teams with highly variable workloads, such as in support or maintenance, often need less fixed structure than a sprint provides. Fixed sprints would often have enforced more structure here than the work actually needed.

How Kanban works in practice

Kanban prescribes hardly any fixed structures. There are no sprints, no fixed roles, and no prescribed meetings. Instead, Kanban makes visible how work flows through a team and helps improve this flow step by step.

The central tool is the Kanban Board. It consists of columns that represent a team's work steps, for example "Open", "In Progress", "Review", and "Done". Each task is a card that moves through these columns from left to right.

An example from web development: A customer reports an error in the contact form. The ticket appears as a card in "Open". As soon as a developer has capacity, they move the card to "In Progress", then it goes to "Review" and after deployment to "Done". There's no sprint start and no sprint end. New tasks are added at any time and are processed as soon as there's space.

Why WIP limits make bottlenecks visible

For this flow to work, Kanban sets so-called WIP limits (Work in Progress). They define how many cards can be in a column at the same time at most. If the limit for "Review" is three, for example, no fourth card can enter until one of the three is completed.

This is precisely where Kanban's strength shows: If cards pile up before review, the team immediately sees where the problem is. Instead of starting new tasks, it specifically helps with the review. This way, bottlenecks don't only become visible in an evaluation after weeks, but directly in daily work.

How both approaches look in real software projects

The following two examples show how the choice plays out in practice.

A project example with fixed releases

A team is developing a new core function for software that must go live on a fixed date. Scrum fits well here because the sprint rhythm enforces fixed milestones.

Product Owner and team plan together what fits into the next sprint. After each sprint, a review shows the actual progress compared to the plan.

A project example with support focus

Another team handles ongoing support for an existing application. Requests come irregularly, sometimes several a day, sometimes none for days.

Kanban fits better here because it doesn't enforce a fixed cycle. New requests go directly into the flow instead of having to wait for the next sprint.

How Scrumban combines both approaches

Scrumban combines the structure of Scrum with the flow principle of Kanban. Teams keep fixed sprints. But they supplement them with elements like WIP limits.

When a combination makes more sense

A combination is worthwhile when a team must handle both plannable releases and unpredictable support work. The Bitkom guideline on agility in organizations describes precisely this transition between both approaches.[^3]

Conclusion

Scrum and Kanban solve different problems. Scrum emerged as a response to the rigid phases of the waterfall model and structures product development via roles, events, and artifacts. Kanban emerged as a response to invisible, overloaded work processes and optimizes the flow of existing work via principles instead of fixed structure.

Is your project not progressing properly? Often this isn't due to the team, but to a process that doesn't fit the type of work. We'll look at your current approach and show you where bottlenecks arise and how to solve them. Schedule a non-binding conversation now.

Footnotes and sources

[^1]: Ken Schwaber and Jeff Sutherland, "The Scrum Guide", official edition November 2020. https://scrumguides.org [^2]: Kanban University, "The Official Guide to The Kanban Method". https://kanban.university/kanban-guide/ [^3]: Bitkom e. V., guideline "Agilität in Organisationen: Ein Leitfaden für die Praxis", 2020. https://www.bitkom.org/sites/default/files/2020-12/201124_lf_agilitat-in-organisationen.pdf [^4]: Bitkom e. V., position paper "Innovation rechtssicher gestalten: Einsatz externer Spezialistinnen und Spezialisten", January 2025. https://www.bitkom.org/sites/main/files/2025-01/bitkom-positionspapier-innovation-rechtssicher-gestalten.pdf