Scrum or Kanban: Which Method Fits Which Kind of Work

Scrum suits work that moves towards a product goal and can be cut into sprints of one month or less; Kanban suits work that arrives irregularly and should be finished continuously. The choice follows the pattern of incoming work and the need for feedback. Seven test questions settle it and avoid the most common mistake in rollouts: one method for every kind of work.

This article compares the two methods against their primary sources, the 2020 edition of the Scrum Guide and the 2020 Kanban Guide, and offers a comparison table, a checklist and a route to introduction. It is written for managing directors and heads of department who must decide how a team will work tomorrow and need a reasoned answer.

What is the difference between Scrum and Kanban?

Scrum provides a framework of roles, events and artefacts, whereas Kanban provides a principle for steering the flow of work. The Scrum Guide describes three accountabilities: Product Owner, Scrum Master and Developers. It adds five events, namely the Sprint as a container plus Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Its three artefacts, the Product Backlog, the Sprint Backlog and the Increment, each come with a commitment: the Product Goal, the Sprint Goal and the Definition of Done. A Sprint lasts one month at most, and at its end stands an Increment that is finished in the sense of the Definition of Done.

The 2020 Kanban Guide describes three practices: defining and visualising a workflow, actively managing the items in it, and improving it. A limit on work in progress belongs to the second practice. The guide prescribes neither roles nor fixed time boxes. It works with four measures: current work in progress, cycle time, throughput and work item age. These are linked by Little's Law, published in 1961: average work in progress equals throughput multiplied by average cycle time. A team that starts more at once waits longer for each individual result at the same throughput. How flow measures read in daily practice is covered in the article on flow metrics.

Both methods rest on transparency and regular inspection, and both require a team to make its work visible. The difference lies in rhythm. Scrum sets a goal each Sprint and inspects it at the end; Kanban delivers as soon as an item is finished and inspects the flow continuously.

When does Scrum fit, and when does Kanban?

Scrum fits when a team develops a product or service whose goal can be approached in stages and whose results a client can assess regularly. Kanban fits when work arrives in irregular quantities and with changing urgency, as in operations, support or the maintenance of plant and systems. Incoming work decides the matter because a Sprint presupposes a degree of predictability that is absent where a fault on Tuesday invalidates Monday's plan.

A development department building a new product gains from Sprints because every stage forces a decision about the next step. A service team handling requests of changing priority every day gains from limits on work in progress because they make waiting visible and put escalations into an order. Why work so often sits instead of moving is the subject of the article on waiting times in processes.

Which method fits which type of work?

Four types of work occur most often in companies, and each has an obvious choice. Product development with a clear client and a goal for the quarter needs a method that sets priorities and inspects results, which is Scrum. Operations and support with unpredictable intake need a method that steers sequence and waiting time, which is Kanban. Projects with a fixed end date and scope can be cut into stages and steered with Scrum, provided scope stays negotiable within the stages. Order handling with standardised steps, such as quotations, purchase orders or complaints, follows a throughput pattern and suits Kanban.

Business units outside software engineering benefit from both: a marketing team with a fixed campaign launch works in Sprints, while a purchasing team with a steady stream of requisitions needs a board with limits.

Mixed teams exist as well. A product team that also handles faults in live operation can work in Sprints and reserve a fixed share of capacity for them. The Kanban Guide for Scrum Teams, published by Scrum.org together with Daniel Vacanti and Yuval Yeret in 2021, describes this route: a Scrum team makes its flow visible, limits work in progress and measures cycle time and item age without giving up the events of the Scrum Guide.

Seven test questions for choosing a method

Seven questions lead to a reasoned choice when a team or a department answers them together. If most answers fall on one side, the team adopts that method for the next three months and reviews the choice afterwards.

1. Does the team know the goal for a period of two to four weeks at the start of that period? Yes points to Scrum, no to Kanban.
2. Does the order of work stay stable within a period? Yes points to Scrum, daily changes of priority to Kanban.
3. Can a client or user assess a result every two to four weeks? Yes points to Scrum, no or rarely to Kanban.
4. Can the work be cut into items of similar size? Yes allows Kanban with forecasts from throughput, and Scrum benefits as well.
5. Is there an owner of the outcome who decides priorities and is reachable day to day? Only then does Scrum work, because the Product Owner is accountable for the order of the Product Backlog.
6. Are waiting times between departments the main problem? Yes points to Kanban with limits at the handovers, because waiting becomes visible there.
7. Does senior management need a date for a goal? Yes points to Scrum with release planning, although a throughput-based forecast is also possible with Kanban.

How do you introduce Scrum or Kanban?

Introduction succeeds in five steps that apply to both methods and differ in sequence.

1. Measure the work: for four weeks the team records which kinds of work arrive, how many items there are and how long they sit. The answers to the test questions come from this record.
2. Choose a method per type of work: a team can run one method, a department several. The choice is written down together with the measure by which it should prove itself.
3. Settle roles and decision rights: for Scrum, a Product Owner and a Scrum Master are named; for Kanban, the team decides who may change limits and who decides priorities.
4. Begin: with Scrum, the team starts with a two-week Sprint and a Definition of Done; with Kanban, with a board that shows the real process and a limit just below the current amount of work in progress.
5. Review after three months: the team compares cycle time and throughput with the starting value, asks the recipients of its work, and decides whether to keep, adjust or change the method.

Those starting with Kanban will find an entry point in the article on introducing Kanban. Those who have a year of Scrum behind them and want to see what remains will find pointers in the article on Scrum in medium-sized companies.

Common mistakes when choosing a method

Three mistakes recur. First, a company picks one method for all teams because a uniform framework seems easier to steer, and so forces support teams into Sprints and development teams onto a board without a goal. Second, Kanban is taken for Scrum without rules, although limits on work in progress demand a discipline that many teams find harder than a Sprint. Third, Scrum is introduced without a Product Owner, so nobody in the team decides priorities and the backlog turns into a wish list. The Definition of Done guards against a further failing of both methods: items that count as finished but have not reached live operation.

Choosing a method with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the delivery management service he takes the role of delivery manager, project manager or product owner; in organisational design he defines roles and clarifies decision paths.

The approach follows the Niehues Delivery Model with its three phases. Three of its test questions count most for choosing a method: who decides, who delivers, who uses? Which roles and decision paths does operations need? Which measure shows after 90 days that the solution has landed? The answers produce a reasoned choice per team, measured against a baseline. The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange via contact.