Kanban vs Scrum for small teams: what each one actually requires

Most of what gets argued about under kanban vs scrum for small teams is in neither primary document. The Scrum Guide and the Kanban Guide together prescribe far less than the average article implies, and the few things they do prescribe are what small teams drop first. So this is a decision guide for three to fifteen people, read off those two documents.

What Scrum actually requires

All quotations below are from the Scrum Guide, November 2020, Ken Schwaber and Jeff Sutherland (scrumguides.org).

Three accountabilities: Developers, a Product Owner, a Scrum Master. The Scrum Master is not an optional facilitator — they are "accountable for establishing Scrum as defined in the Scrum Guide" and "accountable for the Scrum Team's effectiveness", which includes "causing the removal of impediments to the Scrum Team's progress" and "ensuring that all Scrum events take place and are positive, productive, and kept within the timebox."

Five timeboxed events: the Sprint, containing Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. "Sprints are fixed length events of one month or less to create consistency."

Three artifacts, each with a commitment: Product Backlog with a Product Goal, Sprint Backlog with a Sprint Goal, Increment with a Definition of Done.

A protected goal: during the Sprint "no changes are made that would endanger the Sprint Goal", though "scope may be clarified and renegotiated with the Product Owner as more is learned."

Size is not the objection people assume. A Scrum Team is "typically 10 or fewer people", and "smaller teams communicate better and are more productive."

What Kanban actually requires

From the Kanban Guide, v2025.5, May 2025 (kanbanguides.org). Kanban is "a strategy for optimizing the flow of value through a process", built from three practices: "defining and visualizing a workflow", "actively managing items in a workflow", "improving a workflow".

The concrete requirement is a Definition of Workflow. Its minimum contents: the units of value, when items start and finish, the states they flow through, "a definition of how WIP will be controlled from started to finished", "explicit policies about how work items can flow through each state", and "a service level expectation (SLE), which is a forecast of how long it should take a work item to flow from started to finished." Four metrics are mandatory: WIP, throughput, work item age, cycle time.

The absences matter as much. No roles — the Guide addresses "Kanban system members" and names no titles. No cadence: "there is no requirement, however, to wait for a formal meeting at a regular cadence to make these changes." No estimation at all.

Kanban is also built to sit on top of what you already do. Kanban University's official guide, David Anderson's formulation, is explicit: "Kanban is not a methodology nor a process framework. Rather, it is a management method… applied to an existing process or way of working", and its first change principle is "start with what you do now" (kanban.university). Which is the real distinction: Scrum is a framework with mandatory accountabilities, Kanban a method you apply to a process you already have — including, if you like, to Scrum.

The famous parts that are in neither document

Story points and velocity are not in the Scrum Guide. Neither phrase appears in it. The only sentence about sizing is "the Developers who will be doing the work are responsible for the sizing" — no unit is named, so points, days, shirt sizes or nothing are all conformant.

The burndown is not required. Its one appearance is optional and hedged: "various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism." Cumulative flow, a Kanban metric, sits in that same list.

Backlog grooming is not a Scrum event. There are five, and refinement is not one — the Guide calls it "an ongoing activity".

On the Kanban side, the board is not the requirement. Controlling WIP is: "there are no specific guidelines for how a visualization should look." Sticky notes with no WIP control are not Kanban; a spreadsheet with an agreed limit of three in progress is closer.

And Kanban does not mean refusing to forecast. The SLE is mandatory, derived from measured cycle time rather than from estimates.

Two teams arguing about this are usually comparing things they have each partly invented.

What each requires, side by side

Only the last row is opinion, and it is in neither document.

The common small-team failure: Scrum without a Scrum Master

Do small teams need Scrum? Plenty run it well. But the way it fails at this size is predictable, and it is not that the events are too heavy.

It is Scrum with the events and without the Scrum Master accountability. The events get adopted first because they are the visible part; the accountability that makes them work is invisible, so it gets skipped. The Guide is blunt about the result: "changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."

In practice, a Daily Scrum whose purpose is "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog" becomes a status report to whoever is most senior. Scope changes on Wednesday because saying no is nobody's accountability. Retrospectives produce observations and no change, because "causing the removal of impediments" is nobody's job. You keep the full cost of the ceremony and lose the protection it exists to provide.

To be fair to Scrum, the Guide never says the Scrum Master must be dedicated or full-time, or that one person cannot hold two accountabilities — a six-person team naming an engineer as Scrum Master violates nothing. The real question is narrower: will that person block a mid-Sprint scope change asked for by the founder? If not, you are not running Scrum. You are running its meetings.

Kanban vs Scrum for small teams, by team shape

Scrum's real advantages: a cadence that forces a decision on a fixed date whether or not anyone feels like having one, a Sprint Goal and a no-changes rule that protect focus by mechanism rather than by hope, a shared vocabulary, and an answer for a stakeholder who wants a commitment. Kanban's: low ceremony, tolerance of interruption, no estimation, continuous flow instead of a batch boundary.

Interrupt-heavy, support-adjacent work. Kanban. A Sprint Goal renegotiated twice a week is not a commitment, and the protection mechanism ends up fighting the job. Set a WIP limit, write down what may jump the queue, watch work item age.

Genuine external commitments. A dated client deliverable is the strongest case for Scrum; the Sprint boundary exists for it. If you would rather not adopt the framework, the Kanban answer is an SLE from your own cycle times — more defensible than a points estimate, but only once you have the history to compute one.

Two to four people. Neither, mostly. Five timeboxed events for three people who talk all day is machinery for manufacturing communication you already have. Take the smallest pieces: one visualised workflow, an agreed WIP number, a written definition of done. That is a legal Kanban system and it takes an afternoon.

No dedicated process owner. Do not run Scrum events. Kanban names no roles, so nothing goes quietly missing.

What this means for the tracker

Neither document requires software — Scrum "wraps around existing practices or renders them unnecessary", and a whiteboard satisfies everything Kanban asks for. The tool matters only for the accessories: a sprint object, a velocity chart, a burndown to put in front of someone.

We build one, so read the rest as interested. Kevta has no sprints, no story points, no burndown and no reporting layer, so it supports the flow-based half of this article well and the Scrum half poorly. What it does have maps onto a Definition of Workflow: a board's workflow is its Status property, with five stages an admin can rename and reorder (board docs), and board, list, table and calendar views over the same issues. A custom field will hold whatever estimate scale you want.

One gap worth stating plainly: Kevta does not enforce WIP limits. There is no per-column cap, so the number lives in your team's agreement rather than in the software. Naming a column "In progress (max 3)" is what we do; if you want it enforced, we do not do that today.

The useful move is smaller than picking a framework anyway. Make the workflow visible, agree how much can be in it at once, and name who owns the parts that are nobody's job by default — most of what a five-person team needs from issue tracking, and why too many statuses matters more than the label on your process. Kevta is in beta; there is a waitlist.