Kanban

By Allen Jay Bercero

Kanban is an agile method for managing work as a continuous flow: you visualize every item on a board, cap how many things are in progress at once, and pull new work only when there’s capacity. Unlike Scrum, it has no fixed sprints, no prescribed roles, and no required ceremonies. You overlay it on however you already work and improve from there.

The name is Japanese for “signboard” or “visual card.” It came from the Toyota Production System (Taiichi Ohno, 1940s–50s), where physical cards signaled when to produce or restock. David J. Anderson adapted it for knowledge work around 2007–2010.

Also known as

the Kanban Method · “flow-based” or “continuous” agile · (loosely) “the board”

Watch the two meanings of the word: Kanban (the method), an entire way of managing work, versus a kanban board, the visual tool. Every Scrum team using a board is not therefore “doing Kanban.”

Don't confuse with

• Kanban vs Scrum. Both agile. Scrum = fixed sprints, defined roles, batch commitment. Kanban = continuous flow, no roles, pull as you go. See the table below.
• A kanban board vs the Kanban method. Jira/Trello boards are tools; the method is the six practices below.

The core practices

Kanban is defined by practices, not roles or meetings:

1. Visualize the workflow. Put every work item as a card on a board with columns for each stage (e.g. To Do → In Progress → Review → Done). You can’t improve a flow you can’t see.
2. Limit work-in-progress (WIP). Set a maximum number of items allowed in each column. This is the heart of Kanban. It exposes bottlenecks and stops the team from starting more than it can finish.
3. Manage flow. Watch how work moves across the board; smooth out the places it piles up.
4. Make process policies explicit. Write down the rules for how work moves (what “Done” means for each column, etc.).
5. Implement feedback loops. Regular reviews of the flow and the system.
6. Improve collaboratively, evolve experimentally. Change incrementally, using data.

In plain English

Draw your work as sticky notes moving left to right across columns. Rule: only N notes allowed “in progress” at once. Finish something before you start something new. Watch where notes get stuck, and fix that.

Pull, not push

Kanban is a pull system: a person finishes an item, then pulls the next one from the previous column. Work is pulled when there’s capacity, not pushed onto people on a schedule. WIP limits are what make this work.

How progress is measured

Instead of Scrum’s velocity, Kanban uses flow metrics:

• Cycle time: how long one item takes from “started” to “done.”
• Lead time: how long from “requested” to “done.”
• Throughput: how many items finish per week.
• A cumulative flow diagram visualizes all of this over time.

Scrum vs Kanban at a glance

	Scrum	Kanban
Cadence	Fixed sprints (1–4 wks)	Continuous flow
Commitment	Batch, per sprint	Per item, as capacity frees
Roles	Product Owner, Scrum Master, Developers	None prescribed
Events	5 defined events	None required
Change mid-cycle	Avoided (protect the Sprint Goal)	Fine. Just pull the next thing
Key limit	Sprint scope	Work-in-progress (WIP)
Great for	Feature development with planning rhythm	Support, ops, maintenance, unpredictable arrival of work

Neither is “more agile.” Teams with steady, plannable feature work often prefer Scrum; teams handling interrupt-driven work (support, operations) often prefer Kanban. Scrumban blends the two.

See also

• Scrum: the sprint-based alternative
• Agile software development: the family Kanban belongs to
• Software development process: where Kanban sits among the approaches

References

• D. J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press (2010). https://kanbanbooks.com/kanban-successful-evolutionary-change-for-your-technology-business/
• T. Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press (Japanese 1978; English translation 1988). Origin of the kanban signaling method. https://archive.org/details/toyotaproduction0000onot