What is Scrumban?

What Scrumban actually is

Scrumban keeps the parts of Kanban and Scrum that pull their weight, and drops the rest. From Kanban, it takes the visual board, the column-based workflow, and an explicit limit on how much is in progress — the things that make flow legible. From Scrum, it takes the time-boxed sprint — the thing that turns a backlog into a plan.

What it skips: daily standups, sprint grooming meetings, story-point ceremonies, retrospectives-as-ritual. Those work for ten engineers in a tuned org; they do not work for one founder trying to ship on a Saturday.

The name comes from Corey Ladas, whose essay and later book Scrumban described how Scrum teams could move from fixed iterations toward pull-based flow.

Scrumban vs Kanban vs Scrum

The three differ mostly in two things: whether work is planned in time-boxes, and how much process surrounds the board.

Sources: the Scrum Guide for sprints, roles and events; the Kanban Guide for flow and limits on work in progress.

What does a Scrumban board look like?

A Scrumban board is a Kanban board with a sprint laid over it. The columns show where work is; the sprint says which part of the backlog this week is about. A minimal board has four columns:

• Backlog — everything you might do. Unordered at the bottom, ordered at the top.
• Todo — what you have decided to do next. Small on purpose: when it runs low, that is the signal to plan.
• Doing — what someone (a person or an AI agent) is working on right now.
• Done — finished work. Cleared or archived at the end of a sprint.

How do you set up a Scrumban board?

1. Create the four columns: Backlog, Todo, Doing, Done.
2. Put everything you know about into Backlog. Do not sort it all — sort the top.
3. Decide how much may be in Doing at once. For one person, one or two things; for a small team, about one per person.
4. Pick a sprint length — one or two weeks — and write a one-sentence goal for it. Pull into Todo only what serves that goal.
5. Work by pulling: when something in Doing is finished, take the next card from the top of Todo. Nobody pushes work onto anyone.
6. Plan when Todo runs low, not on a calendar. At the end of the sprint, look at what got done and what did not, then start the next one.

Why Weft picks Scrumban

Weft exists because most task managers are shaped for one of two extremes: either a lone-todo app (infinite list, no cadence) or a fifty-person Agile suite (process overhead for a founder of one). Scrumban sits precisely in the middle — enough structure to force a weekly or bi-weekly ship, not so much that you spend the ship-day administering it.

How Weft implements it

• Four default columns: Backlog, Todo, Doing, Done. Work in progress is limited by what waits for you, not by a number per column. The Kanban Guide treats an explicit policy for limiting work in progress as part of a workflow definition, so that new items are pulled in only as capacity frees up.
• One active sprint at a time, with an optional goal. Sprints are optional — skip them if pure Kanban fits. The Scrum Guide defines Sprints as fixed-length events of one month or less, with a new Sprint starting immediately after the conclusion of the previous one.
• Tasks have priority, estimate, due date, and an optional sprint attachment. No epics, no workflows, no custom fields.
• Cycle time starts when a task moves into a column with semantic="doing" and ends in "done". The numbers come out of honest use, not story-point arithmetic.

Scrumban with AI agents

Pulling is what makes Scrumban work for AI agents too. An agent connected to Weft over MCP takes the next card itself: start_task claims it, so a second agent cannot pick up the same card, and complete_task finishes it with what was done and the evidence. When an agent needs a decision, it asks you instead of guessing — and while too much finished work waits for you, agents stop starting new tasks. That is the Kanban limit on work in progress, applied to the one resource that does not scale: your attention.

When Scrumban is not the right method

• You run multiple concurrent Scrum teams. The Scrum Guide puts a Scrum Team at typically 10 or fewer people, and says that larger products should be organised into several Scrum Teams sharing one Product Goal and one Product Backlog. Program-level reporting, shared velocity, cross-team dependencies — full Scrum in Jira earns its keep. The Nexus Guide is written for that situation: several Scrum Teams working from a single Product Backlog, with extra practices for surfacing and resolving cross-team dependencies.
• You do pure support / continuous ops. No sprint cadence needed — pure Kanban or a ticketing system fits better.
• You need Gantt charts and timelines. Scrumban is sprint-focused, not dependency-graph-focused.

Scrumban questions