Scrum vs Kanban: the differences, and which one fits a small team
By Andrei Finogeev, founder of Weft ·
Scrum plans work in fixed sprints of one month or less, with three accountabilities (Product Owner, Scrum Master, Developers) and four events inside every sprint. Kanban has no sprints and no prescribed roles: work flows continuously across a board, and the team explicitly limits how much is in progress. Pick Scrum when a team of several people needs a fixed delivery rhythm and a stable goal per cycle; pick Kanban when work arrives unpredictably and priorities change daily. Scrumban sits between them: Kanban's flow, with sprints only where they help.
Scrum vs Kanban vs Scrumban: cheat sheet
Scrum as defined by the 2020 Scrum Guide, Kanban as defined by the Kanban Guide (v2025.5). Scrumban has no official guide; the column describes how it is usually run.
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Cadence | Fixed sprints of one month or less, back to back | Continuous flow, no iterations | Continuous flow; optional sprints, usually one or two weeks |
| Roles | Product Owner, Scrum Master, Developers | None prescribed | None prescribed; often one person owns priorities |
| Meetings | Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective | None prescribed | Only what the team finds useful, typically planning and a review |
| What limits work | What the team commits to for the sprint | An explicit limit on work in progress | A work-in-progress limit, plus the sprint goal if there is one |
| Changing scope mid-cycle | The Sprint Goal stays fixed; the Sprint Backlog can be refined | Any time: the next item is pulled when there is room | Any time; the sprint goal is a target, not a lock |
| Main measures | Progress toward the Sprint Goal and the Product Goal | Work in progress, throughput, work item age, cycle time | Usually Kanban's flow measures |
| Board | Optional; reset every sprint | The core of the method; persists | Persists; a sprint is a slice of it |
| Fits best | Product teams of up to about ten people building toward a goal | Support, operations, and anyone whose work arrives unplanned | Small teams and solo founders who want flow and a short-term goal |
What Scrum is
Scrum was first presented by Ken Schwaber and Jeff Sutherland at the OOPSLA conference in 1995; the rules today are the 2020 Scrum Guide. A Scrum Team is typically ten people or fewer, and it works in sprints: fixed-length events of one month or less that start right after the previous one ends.
Each sprint has four events. Sprint Planning (at most eight hours for a one-month sprint) sets the Sprint Goal and picks the work. The Daily Scrum is a 15-minute check for the Developers. The Sprint Review (at most four hours) shows the result to stakeholders, and the Sprint Retrospective (at most three hours) looks at how the team worked.
Scrum has three artifacts, each with a commitment: the Product Backlog (the Product Goal), the Sprint Backlog (the Sprint Goal) and the Increment (the Definition of Done).
What Kanban is
The Kanban Guide defines Kanban as "a strategy for optimizing the flow of value through a process". It comes from the card system Toyota used to signal when to produce more, and was adapted for knowledge work in the 2000s.
It has three practices: define and visualize the workflow, actively manage the items in it, and improve it. The one hard rule is that the people in the system explicitly control how many items are in progress between started and finished: the work-in-progress (WIP) limit.
Kanban prescribes no roles, no sprints and no meetings. It tracks four flow measures: work in progress, throughput, work item age and cycle time.
Pros and cons
Scrum
- A fixed rhythm: everyone knows when the next result is due
- A clear goal per sprint keeps the team from drifting
- Built-in moments to inspect the product and the process
- Four events per sprint are a real time cost for a team of two or three
- Urgent work either waits for the next sprint or breaks the plan
- Needs someone in each accountability, which one founder cannot split
Kanban
- Starts on the board you already have; nothing to install but a WIP limit
- New work can be pulled in at any time
- Flow measures show where work gets stuck
- No built-in deadline or goal, so long-running work can drift
- Without a WIP limit it is just a to-do list with columns
- Planning ahead is left entirely to the team
Which one to pick
- A product team of five to ten with a stable roadmap
- Scrum. The events pay for themselves when several people need to agree on one goal every couple of weeks.
- Support, operations, or a team that lives on incoming requests
- Kanban. Work arrives when it arrives; a WIP limit and a clear Done column matter more than a sprint plan.
- A solo founder or a team of two to five
- Scrumban. Keep a continuous board with a WIP limit, and use a one- or two-week sprint as a short-term goal, without the full set of Scrum events.
Scrumban: the middle ground
Scrumban was described by Corey Ladas as a way for Scrum teams to move toward pull-based flow. In practice it means a Kanban board with WIP limits that never resets, plus sprints as optional time-boxes that group part of the work. Our full guide covers the rules and how to set up the board: What is Scrumban?
When AI agents do part of the work
If ChatGPT, Claude, Cursor or Codex picks up tasks for you, Scrum's events have no one to attend them: an agent does not join a standup. What still matters is what Kanban provides: a board that shows what is in progress, a WIP limit so ten tasks are not started at once, and a clear rule for when a card is done.
The bottleneck also moves. Agents finish work quickly, and the slow step becomes your review of what they did. A limit on how much finished work can wait for you is a WIP limit on the human column.
Weft is a Scrumban board built for this: columns, optional sprints, a limit on how much finished work can wait for your review, and an AI that claims a task before starting, reports progress, and stops to ask you when only you can decide.
Questions
Are Scrum and Kanban the same?
No. Both are agile approaches and both often use a board, but Scrum plans work in fixed sprints with set roles and events, while Kanban has continuous flow, no prescribed roles and an explicit limit on work in progress.
Do you do sprints in Kanban?
Not in Kanban as such: the Kanban Guide prescribes no iterations. Teams that add sprints to a Kanban board are usually doing Scrumban.
How does a Scrum sprint work?
A sprint is a fixed period of one month or less. It starts with Sprint Planning, which sets the Sprint Goal; the Developers meet for a 15-minute Daily Scrum; it ends with a Sprint Review of the result and a Sprint Retrospective on the process, and the next sprint starts right away.
Who invented Scrumban?
The term is credited to Corey Ladas, who described Scrumban in essays and a 2009 book as a way for Scrum teams to move toward Kanban-style pull.
Is Scrum the same as Agile?
No. Agile is the set of values and principles in the 2001 Agile Manifesto; Scrum and Kanban are two specific ways to work that follow them.
Can a solo developer use Scrum?
Not as written: Scrum assumes a team with three separate accountabilities. A solo developer usually keeps the parts that help, a backlog and a short sprint goal, and runs the board as Kanban — which is Scrumban.
Sources
Read on 11 November 2026.