Kanban and Scrum Boards: What Is the Difference?#

The short version#

Scrum works in sprints: fixed-length periods, usually two weeks. The team chooses a set of stories at the start of the sprint, delivers them by the end, and then plans the next sprint. The board shows the current sprint.
Kanban works as a continuous flow. There are no sprints. Work is pulled in as there is capacity, and the limit is on how much can be in progress at once. The board shows everything in flight.

Scrum asks “what can we finish in this sprint?” Kanban asks “how do we keep work moving, and how do we stop starting more than we can finish?”

Where Kanban comes from#

Kanban is the Japanese word for a signal card. It comes from the Toyota production system, where a card told the previous step to make more only when the next step needed it. In knowledge work the Kanban Method uses the same idea: make the work visible, limit work in progress, and manage the flow. Its practices are usually listed as:

visualise the work
limit work in progress (WIP)
manage flow
make the policies explicit
build feedback loops
improve collaboratively

Side by side#

Scrum compared with Kanban#
Aspect	Scrum	Kanban
Cadence	Fixed-length sprints, for example two weeks.	Continuous. Work is released when it is done.
Planning	Sprint planning, where the team commits to a sprint goal and a set of stories.	Whenever there is capacity, the next item is pulled from the top of the backlog.
Limits	The scope of the sprint is limited by the team’s capacity (velocity).	A WIP limit on each column or on the whole board.
Roles	Product Owner, Scrum Master and Developers.	No required roles. The existing roles stay.
Change during the iteration	Discouraged. New requests go to the backlog for the next sprint.	Allowed. A new item can enter at any time if it is the next priority and there is room.
Backlog	Required, and ordered by the Product Owner.	Optional, though most teams keep a queue of work waiting.
Estimates	Story points are common, and give the velocity.	Not required. Items are often sized “small enough” and flow is measured instead.
Meetings	Sprint planning, daily scrum, review and retrospective.	None are prescribed. Many teams have a daily stand-up and a periodic review.
Main measures	Velocity, burndown, sprint goal met.	Lead time, cycle time, throughput and the cumulative flow diagram.
Board	Reset at the end of each sprint. Unfinished items return to the backlog.	Never reset. Cards stay on it until done.
Fits best	Project work with a goal and a team that can commit, such as a new feature or tool.	Work that arrives unpredictably and must be handled in order of priority, such as support and operations.

Sprints, stories and the rest#

Scrum and Kanban share much of the vocabulary, and the confusion is often about what belongs to which.

Terms and where they apply#
Term	Meaning	Scrum	Kanban
Story	A piece of value, written from the user’s view. See Scrum and Jira in Practice.	Yes	Optional. It is a Jira issue type, so it can be used on any board.
Epic	A large body of work that is split into stories.	Yes	Optional. Often used to group related cards.
Task and bug	Work that is not a feature, or something that is broken.	Yes	Yes
Sprint	A fixed period that delivers an increment, with a sprint goal.	Yes	No
Story points and velocity	A relative size for each story, and the total completed in a sprint.	Common	Rare
Backlog	The ordered list of work waiting to be done.	Required	Optional
WIP limit	A cap on how many items can be in a column at once.	Rare	Core
Burndown	Remaining work in the sprint against time.	Yes	No
Cycle time and lead time	How long an item takes. Lead time runs from the request to done. Cycle time runs from the start of work to done.	Possible	Core
Retrospective	A review of how the team worked, and what to improve.	Yes	Good practice

In Jira, the issue types (epic, story, task, bug) are the same in both. What changes is the board and the settings: a Scrum board has a backlog, sprints and sprint reports, and a Kanban board has columns, optional WIP limits and flow reports.

WIP limits and flow#

A WIP limit is the feature that most separates Kanban from a plain task board. When a column is full, nobody pulls in a new item until one moves on. The team has to help to finish the work that is stuck, and that is the point. It reduces the amount of half-done work, which usually reduces the time that each item takes.

The link between them is Little’s Law: the average cycle time is the average number of items in progress divided by the throughput.

\[\text{Cycle time} = \frac{\text{Work in progress}}{\text{Throughput}}\]

If a team has 12 items in progress and finishes 6 a day, an item takes about 2 days. If it starts more work and has 24 in progress at the same throughput, each item takes about 4 days. A WIP limit keeps the first number down.

A Kanban board for IPV exceptions#

The IPV project in Example: An IPV Project suits Scrum, because it has a goal, an end and a team that can commit to a set of stories. Once it is live, the daily exceptions that it produces are a different kind of work. They arrive unpredictably, differ in size, and each needs an owner and a decision. A Kanban board fits that better.

An exceptions board on one morning#
Column	Meaning	WIP limit	Cards	Comment
Backlog	Flagged by the daily run, not yet picked up.		9	Ordered by size of the difference.
Investigating	A controller is checking the difference.	5	5	At the limit. Nothing new is started.
Awaiting desk	The desk has been asked to explain or re-mark.	4	3	One free slot.
Proposed adjustment	An IPV adjustment is ready for review.	3	2	One free slot.
Done	Resolved, with the evidence attached.		6	Cleared since the start of the week.

The board shows the problem at a glance. “Investigating” is full, so controllers should help to finish items, and not take new ones from the backlog. The exceptions also give measures to review:

Lead time: the days from the flag to the resolution, which should be under the target, such as 5 working days.
Ageing: how many cards have been in a column for more than a set number of days. These are the exceptions to chase.
Throughput: the number resolved each week.
Cumulative flow diagram: a Jira report that shows the count in each column over time. A band that keeps growing shows a bottleneck.

Scrumban#

Many teams use both. A team that is mostly on projects but has a flow of urgent requests might run sprints and also keep a WIP limit on the “In Progress” column, or reserve part of each sprint for unplanned work. Others run a Kanban board and add a regular review, a retrospective and a short planning meeting. This is sometimes called Scrumban. Nothing stops a team from using the parts that help, so long as it is clear which rules are in force.

Which to use#

Ask these questions:

Is there a goal and an end date? A project with a clear goal suits Scrum. Continuing work with no end suits Kanban.
Can the team commit to a set of work for two weeks? If urgent requests constantly break into the plan, Kanban is easier.
Does the work need to be reordered all the time? Kanban lets you take the next highest priority without waiting for a sprint boundary.
Do you need a forecast? Scrum gives one from velocity. Kanban gives one from throughput and cycle time.

For a valuation control team, a common split is Scrum for projects and change, as in Example: An IPV Project, and Kanban for run work such as exceptions, queries and month-end tasks.