Kanban

What is Kanban?

Kanban is a way of managing work by making it visible and limiting how much of it happens at once. The core artifact is a board with columns representing stages (for example: To Do, In Progress, Review, Done) and cards representing tasks that move left to right. The name comes from the Japanese word for signboard, and the method traces back to Toyota's factory floors, where cards signaled when to pull new inventory into production. Software teams adapted the idea, and it is now summarized well on Wikipedia's Kanban development page.

Two rules do most of the work. First, visualize everything: if a task is not on the board, it does not exist. Second, limit work in progress (WIP): each column gets a cap, say three cards, and nobody starts a new task while a column is full. Instead of pushing more work into the system, the team swarms on finishing what is already started. Day to day this feels less like ceremony and more like a shared habit: pull a card, move it, finish it, pull the next one.

Why Kanban matters for startups

For a 1 to 5 person team, process overhead is expensive. Kanban has almost none: no mandatory roles, no fixed-length cycles, no estimation meetings. You can adopt it in an afternoon with a whiteboard or any free tool.

The WIP limit is the part that changes decisions. Small teams die from having eleven things 80 percent done. A capped board forces the uncomfortable question "should we even start this?" before every new task, which is exactly the discipline that prevents feature creep and keeps a small product backlog honest.

Kanban in practice

Imagine a three-person team building an invoicing tool. Before Kanban, they had 14 tasks in progress and shipped roughly one finished feature a month. They set up a board with a WIP limit of two per person. The first week is frustrating: the founder wants to start a referral feature but the board is full, so she instead helps review a teammate's half-done export feature.

Within a month, cycle time (the days from starting a card to finishing it) drops from 19 days to 6, and they ship five small improvements. Nothing about their skills changed. They simply stopped paying the tax of context switching across a dozen open tasks.

Kanban vs Scrum

Teams often choose between Kanban and Scrum, the other popular flavor of agile methodology. They solve similar problems with different trade-offs.

Aspect	Kanban	Scrum
Cadence	Continuous flow, no fixed cycles	Fixed sprints, usually 1 to 4 weeks
Roles	None required	Product Owner, Scrum Master, developers
Planning	Pull the next card when capacity frees up	Sprint planning commits a batch of work
Change mid-cycle	Anytime, reprioritize the queue	Discouraged during a sprint
Key metric	Cycle time, throughput	Velocity per sprint

Rule of thumb: Kanban suits continuous, interrupt-heavy work (support, ops, tiny teams), while Scrum suits teams that benefit from committed goals and a regular demo rhythm. Many startups run a hybrid: a Kanban board with a light weekly planning ritual.

Common mistakes

• Using the board without WIP limits. That is just a to-do list with columns. The limit is the mechanism; set one even if it feels arbitrary, then tune it.
• Letting cards rot. A card sitting in one column for weeks is a signal, not wallpaper. Discuss blocked cards daily and either unblock or kill them.
• Making cards too big. "Build billing" will sit in progress for a month. Slice work so most cards finish in 1 to 3 days.
• Skipping the Done definition. If "done" is ambiguous, cards bounce back from Done and your metrics lie. Agree on what finished means (tested, deployed, documented).
• Tracking nothing. Without cycle time or throughput you cannot tell whether a change helped. Even a simple weekly count of finished cards works.

Related concepts

Kanban is one practice inside the broader family of agile development. It pairs naturally with a prioritized backlog to feed the board and a lightweight product roadmap to keep the queue pointed at goals rather than whims.