Scrum vs Kanban: cadence or flow?

Teams are often told to choose between Scrum and Kanban, as if one were a newer version of the other. They are two different answers to two different questions. Scrum asks how a team should plan, deliver and learn in regular cycles. Kanban asks how work should move through a system so that value flows smoothly and predictably. A team can use either, both or neither, and a lot of confusion comes from forgetting which question is being asked.

What Kanban is

The Kanban Guide describes Kanban as a strategy for optimising the flow of value through a process. It rests on three practices that work together: defining and visualising the workflow, actively managing the items in it, and improving the workflow.

The first practice produces what the Guide calls a Definition of Workflow. It includes the unit of work, where work starts and finishes, the states in between, how work in progress is controlled, the policies that apply, and a service level expectation based on the team's past cycle time. A Kanban board is the usual way to show it. The second practice means keeping the number of items in progress under control, stopping items from ageing, unblocking stalled work and reviewing active items regularly. Limiting work in progress creates a pull system: new work starts only when there is capacity. The third practice means reviewing and changing the workflow whenever context calls for it.

Four flow metrics belong to Kanban in the Guide: work in progress, throughput, work item age and cycle time. The Kanban Guide prescribes no roles and no fixed meetings or cadence.

What Scrum adds and fixes

Scrum is more prescriptive. It sets a team of three accountabilities, five events, three artifacts, and fixed-length Sprints. Work is chosen at the start of a Sprint, committed to as a Sprint Goal and inspected at its end. It also has a theory to match: empirical process control, with a rhythm designed to produce inspection and adaptation at known times.

The rhythm is the main difference. Scrum batches decisions at the edges of a Sprint. Kanban allows decisions at any time work flows. The Scrum Guide does refer to flow measures: it says that practices such as burn-downs, burn-ups or cumulative flows can help forecast progress, and that they do not replace empiricism.

The differences, side by side

The SBOK® Guide treats Kanban inside its overview of agile methods, describing it as a way of visualising production with aids such as task cards, Scrumboards and burndown charts, and says elsewhere that it aims to show how Scrum concepts align with Kanban, OKRs, DevOps and business analysis.

A worked example: two teams, two kinds of work

This is an illustrative pair. Team A builds a new onboarding flow for a mobile app. The work is a product with a goal, and each piece depends on decisions about what the product should be. A Sprint Goal such as "a new user can set up an account and make a first booking" gives the team a focus, and a review with stakeholders every two weeks checks the direction. Scrum suits it.

Team B runs a support and maintenance desk. Tickets arrive daily, with different sizes and urgencies, and it is hard to know on Monday what will arrive on Thursday. A two-week commitment would be broken by the first urgent bug. The team sets a limit of six items in progress, a rule that urgent items skip the queue but count against the limit, and a goal of resolving ninety percent of tickets within a stated number of days, based on the last quarter's cycle times. Kanban suits it.

The GOV.UK Service Manual makes this same observation: Scrum suits teams building something new or adding features each sprint, while teams running a live service with urgent requests may find sprints restrictive and can move to a flow-based method like Kanban, keeping activities such as stand-ups, retrospectives and regular progress reviews.

Combining them

Many teams use both, and the combination is common enough to have a name, Scrumban. There is no authoritative definition of it. In practice it means a Scrum Team that adds explicit work-in-progress limits and flow metrics to its board, or a Kanban team that adopts a regular retrospective and a planning cadence.

The Scrum Guide does not forbid this. It says Scrum is a container for other techniques and practices. A team that limits WIP inside a Sprint is still doing Scrum as long as the accountabilities, events and artifacts are intact. What it cannot do is drop the Sprint and still call it Scrum, which the Guide's final note rules out.

When to choose which

Some questions help.

1. Is the work a product being shaped, or a stream being served? Shaped work favours Scrum. Streams favour Kanban.
2. Do you need a regular point of stakeholder inspection? Scrum builds it in. Kanban leaves it to you.
3. How often does the order of work change? If priorities shift daily, Sprints may feel like a straitjacket. See change requests in the middle of a Sprint for how Scrum handles it.
4. Does the team need structure to start with? Scrum is more explicit. Kanban starts from what you do now.
5. Do you need to predict delivery dates for single items? Cycle time data in Kanban gives a direct answer.

None of these questions is decisive. The honest answer is often to start with the one that fits and borrow from the other.

Common mistakes

• Using a Kanban board and calling it Kanban. A board without work-in-progress limits and explicit policies is a task list.
• Using Sprints and never inspecting at the end. That is a fixed-length period, not Scrum.
• Mixing in flow metrics as targets, which tempts people to game them. See how velocity gets misused.
• Treating one as more mature than the other. The choice is about fit.

How to practise it

If you already use a board, try one change. Add a limit on the number of items in progress and watch what happens to the way people pick up work. In the simulator you get to see how a Sprint's shape affects your choices about scope and WIP.