Kanban vs Scrum vs Scrumban: Which One Are You Actually Running?

Introduction

Almost every comparison of these three starts with history: Toyota, the 2001 manifesto, David Anderson at Microsoft. None of that helps on a Tuesday when someone asks why the board looks like that.

The useful version is narrower. Scrum, Kanban and Scrumban disagree about exactly three things, and everything else is elaboration. Once you can name those three, you can look at your own team and say which one you are running, which is usually not the one on the wiki page.

The Three Things They Disagree About

Cadence. Is work batched into a fixed timebox, or does it flow continuously? Scrum batches into a sprint. Kanban does not batch at all. Scrumban keeps a rhythm for planning and review but lets delivery run continuously underneath it.

Commitment point. When does the team promise something? Scrum commits to a set of items at the start of each sprint. Kanban commits one item at a time, at the moment it is pulled. Scrumban commits when the queue drops below a threshold and someone replenishes it.

Limit on work in progress. Scrum limits WIP indirectly, through sprint capacity. Kanban limits it directly and explicitly, with a number. Scrumban takes the explicit limit and keeps it.

Roles, ceremonies, estimation units and board layouts all follow from those three, and they are also the only part most teams ever argue about.

Side by Side

Which One Are You Actually Running?

Four questions. Answer them about last month, not about the process document.

• Did anything get added to an in-flight sprint? If urgent work routinely lands mid-timebox and gets worked on, the timebox is not a commitment, it is a calendar. You are running Kanban with a fortnightly meeting.
• Does anyone read the velocity number? If the burndown is produced and never referenced in a decision, the estimation ritual is costing you a half-day per fortnight and returning nothing.
• Is there a number that stops someone starting new work? If not, you have no WIP limit, whatever the board says. See WIP limits without the bureaucracy.
• What happens to the leftovers? If unfinished items roll into the next sprint as a matter of course, the sprint boundary is not doing the job it exists to do.

The common answer for a team of two to fifteen is: additions happen weekly, nobody reads velocity, there is no WIP limit, and leftovers always roll over. That team is running Scrumban badly and calling it Scrum. It is not a failure of discipline. It is a method built for a larger group being worn by a smaller one.

Why the Timebox Stops Paying for Itself Below Fifteen People

A sprint buys you two things. It creates a protected window where priorities hold still, and it produces a forecast in the form of velocity. Both have a price: planning, estimation, review and retrospective, plus the cost of holding work at a boundary rather than shipping it when it is ready.

At thirty people the protection is worth a lot, because the interruption pressure comes from several directions and someone has to absorb it. At six people, the person absorbing the interruption is usually the same person who would have to decide anyway, so the protection is mostly theatre. Meanwhile the ceremony cost does not scale down: a two-week cycle takes roughly the same number of meeting hours per person whether you are six or thirty.

The forecast has a similar problem. Velocity is a batch average that needs several stable timeboxes before it means anything, and a six-person team rarely gets several stable timeboxes in a row. Cycle time distribution gives you a usable forecast far sooner, from data the team produces by working rather than by estimating. See cycle time vs lead time and what to tell a client instead of a number.

To be precise, since this gets read as ideology: the objection is to the timebox at small scale, not to planning. A prioritised list, a limit on simultaneous work and a moment where someone decides what matters are the parts worth keeping.

The Fourth Option: Drop the Board Too

Scrumban is the usual landing spot for a small team that has outgrown sprints, and it is a real improvement. But it keeps one inherited assumption: that work is represented as cards in columns that people move by hand.

Columns are a status display and a maintenance job. Somebody drags cards, somebody notices a card in the wrong column, somebody argues about whether code review is its own column. None of that produces anything.

FlowBoard takes the parts of Kanban that carry weight and drops the columns. Work lives in one prioritised flow, sorted top to bottom by a priority score rather than by position on a board, so reprioritising means changing an input, not rearranging cards. Status is a field on the item. Readiness is separate from status and shown as a colour: red for not ready, amber for in progress or needing work, green for ready to ship, so nobody has to take "it is basically done" on trust.

The replacement for the sprint boundary is the release. A release is a real object that tasks belong to, not a label applied afterwards. You can freeze it when you need to stop adding scope, and ship it when everything in it is green. Shipping closes the tasks, generates the changelog and notifies the people who were waiting, in one action rather than a checklist someone runs from memory at seven in the evening.

That is the trade: you give up the fixed cadence and the velocity number, and you get back the ceremony hours, the ability to reprioritise on any day, and a release process that does not depend on someone remembering. FlowBoard is built for teams of two to fifteen and deliberately does not try to serve fifty. At fifty, the timebox is probably still earning its keep.

How to Choose

Stay on Scrum if the timebox is genuinely holding priorities still, someone acts on velocity, and the team is large enough that a dedicated product owner is a real role rather than a hat the founder wears on Mondays.

Move to Kanban or Scrumban if you are already breaking the sprint most weeks. You are not abandoning a working system, you are writing down the one you already have. Start by setting an explicit WIP limit and measuring throughput; keep the planning meeting if it is useful and drop the estimation part of it first.

Go to continuous flow if the board itself has become the chore. The signal is specific: the columns get tidied before the weekly meeting rather than as work happens. That means the board has become a report, and a report should be generated, not maintained. See continuous flow project management.

What Usually Goes Wrong in the Switch

Dropping the limit along with the timebox. The sprint was implicitly capping WIP. Remove it without setting an explicit number and WIP climbs, cycle time climbs with it, and within a month somebody concludes that "Kanban does not work here". Set the number on the first day.

Keeping every ceremony. Teams drop the sprint and keep planning, review, retro and a daily standup, which is the ceremony cost of Scrum with none of the protection. Keep the retrospective. Question the rest.

Expecting the forecast on day one. Cycle time based forecasting needs a few weeks of completed items before the distribution means anything. Say so to whoever is asking for dates.

Calling it a tooling decision. Changing tools without changing the commitment point or the WIP limit reproduces the old process in new software. The method is the three things at the top of this article.

Frequently Asked Questions

What is the difference between Kanban and Scrum in one sentence?

Scrum commits to a batch of work for a fixed timebox and measures velocity; Kanban commits to one item at a time, limits work in progress with an explicit number, and measures cycle time and throughput.

What is Scrumban, exactly?

Scrumban keeps Scrum's planning rhythm and roles but replaces the sprint commitment with continuous pull and an explicit WIP limit. Work is replenished when the ready queue drops below a threshold rather than refilled on a calendar date.

Is Scrumban just Scrum done badly?

No, though the two look identical from outside. The difference is intent: Scrumban deliberately removes the batch commitment and replaces it with a WIP limit and a replenishment trigger. Scrum done badly removes the commitment and replaces it with nothing, which is why WIP climbs.

Can a team of three use Kanban?

Yes, and it is the easier fit at that size: Kanban prescribes no roles and no ceremonies, so there is nothing to scale down. A WIP limit of two items per person and a weekly look at cycle time is the whole system.

Do you need story points for Kanban or Scrumban?

No. Both forecast from cycle time and throughput, measured from items the team has actually finished. Most small teams drop estimation once they have four to six weeks of completed items.

What replaces the sprint review if there is no sprint?

The release. In FlowBoard a release is a first-class object that tasks belong to; you freeze it when you stop adding scope and ship it when every item is green, which closes the tasks, generates the changelog and notifies whoever was waiting.

What to Do This Week

Answer the four diagnostic questions above about the last four weeks and write the answers down. If three of them point away from the method on your wiki page, you are already running something else and paying the overhead of both.

Then pick the single cheapest change: set one WIP limit for the whole team and leave it alone for a month. It costs nothing, it needs no tooling migration, and it is the only one of these ideas that works regardless of which of the three you decide you are running.

Next: the flow metrics guide for what to measure once the timebox is gone, and why small teams should skip Scrum for the longer version of the argument above.