Scrum or Kanban: what should a small development team choose?

Scrum suits a small team building a new product that wants short cycles with regular demos; Kanban suits a team with an unpredictable flow of work: support, bug fixes, many small requests. Many teams end up with a mix: iterations and demos from Scrum plus a board with work-in-progress limits from Kanban.

Here is how the approaches differ in practice and how to choose without turning process into ritual.

How does Scrum differ from Kanban?

Scrum organises work into short iterations — sprints — with scope chosen upfront, fixed roles and regular meetings. Kanban organises work as a continuous flow: tasks move across a board, and the number of tasks in progress at once is limited.

Criterion	Scrum	Kanban
Rhythm	Fixed-length sprints, usually 1–4 weeks	Continuous flow without iterations
Planning	At the start of each sprint	Whenever capacity frees up
Changing work	Discouraged within a sprint	Possible at any time
Roles	Product owner, Scrum Master, developers	No mandatory roles
Key metric	What was done in a sprint	Time for a task to cross the board
Load limit	Sprint scope	Work-in-progress limit per column
Best suited to	Building a new product	Support and a stream of mixed requests

The official Scrum Guide describes Scrum's roles and events: sprint planning, the daily scrum, the sprint review and the retrospective.

When should you choose Scrum?

Choose Scrum when the team is building a new product or a major feature, the client has time for planning and demos, and priorities can be fixed for at least a couple of weeks. Short iterations give the client a regular checkpoint and a chance to change course.

Signs Scrum will fit:

• the work is product development, not a stream of urgent requests;
• there is a product owner who makes priority decisions;
• the client wants to see working results regularly;
• the team's composition is stable for at least a few sprints.

A small team does not have to follow the book to the letter. A dedicated Scrum Master in a team of four is usually overkill — the tech lead or project manager covers the role.

When should you choose Kanban?

Choose Kanban when tasks arrive unpredictably and cannot wait for the next sprint: product support, bug fixing, handling requests, operational work. It does not require restructuring the process and fits on top of how the team already works.

How to set up a Kanban board:

Backlog → Ready (limit 6) → In progress (limit 3) → Review (limit 2) → Testing (limit 2) → Done

The work-in-progress limit is Kanban's central idea. If the Review column is full, a developer does not pick up a new task but helps finish the current ones. This shortens the time from starting a task to shipping it.

Photo: Unsplash

Can you combine Scrum and Kanban?

You can, and most small teams end up doing exactly that: iterations, planning and regular demos from Scrum; a board with limits and the ability to take an urgent task without stopping the sprint from Kanban. This is sometimes called Scrumban.

What it looks like in practice

1. Two-week iterations with planning at the start and a demo at the end.
2. A board with work-in-progress limits instead of a rigid sprint scope.
3. Reserved capacity for urgent work and bugs — for example, a fifth of the team's time.
4. A short retrospective every iteration: what got in the way and what to change.

Priorities for iterations are easier to set with the methods from backlog prioritisation.

What mistakes do teams make when adopting them?

The main mistake is adopting a methodology for its own sake: meetings happen, the board is updated, yet delivery gets no more predictable for the client. The process should solve a concrete problem — missed deadlines, lost tasks, poor visibility — and change if it does not.

Typical mistakes:

• hour-long daily meetings instead of 15 minutes;
• a sprint that keeps getting new tasks added is no longer a sprint;
• Kanban without limits is just a to-do list where everything is "in progress";
• demos without the client lose the main value of iterations;
• retrospectives after which nothing changes.

In short

• Scrum is for building a new product in short iterations with regular demos.
• Kanban is for support and unpredictable work; its key idea is work-in-progress limits.
• Small teams usually do best with a mix: iterations and demos plus a board with limits.
• Do not follow the book where it does not help: roles and meetings must earn their place.
• Judge the process by its results — predictable delivery and visibility for the client.