Kanban
Kanban is an agile method that visualizes work on a WIP-limited board to expose bottlenecks, treating work as a continuous stream rather than time-boxed sprints. Columns typically run To Do, In Progress, Done, with refinements like Code Review, QA, and Deploying inserted as needed. It originated in Toyota's manufacturing system in the 1940s (Taiichi Ohno) and was adapted to software by David J. Anderson in the 2000s (Kanban: Successful Evolutionary Change for Your Technology Business, 2010). It is the most-used agile method outside Scrum and a natural fit for teams whose work doesn't break cleanly into sprint-sized chunks.
The four core practices: visualize the work (a board, physical or digital, shows every item and what state it's in), limit work in progress (each column has an explicit cap; new items can't enter a column if it's at the limit, which forces the team to finish before starting), manage flow (measure cycle time and throughput, optimize to reduce bottlenecks), and make policies explicit (the rules for when something moves from one column to the next are written down, not assumed). Kanban differs from Scrum in several structural ways: no sprints (continuous flow), no fixed roles (no Product Owner or Scrum Master required, though they can exist), priorities can change at any time as long as WIP limits hold, and changes happen evolutionarily (start where you are, adjust over time). Common tools: Linear, Jira, Trello, GitHub Projects, ClickUp, Asana, Notion, KanbanFlow, Kanbanize. The metric that matters most in Kanban: cycle time (how long an item takes from start to done), tracked as a distribution rather than an average, with the goal of reducing variance as much as reducing the mean. The 2020s shift: many product teams run hybrid models (Scrumban) that combine Kanban's flow with Scrum's ceremonies, picking from both depending on what the team actually needs.
Ryan's Take
Kanban does what Scrum only pretends to: it shows you the actual bottleneck. WIP limits force you to admit you were starting far more than you were finishing, and that the slow column was always going to be slow until you dealt with it. Switch over and within a month you will usually discover your real problem was never sprint planning. It was that QA was permanently backed up and nobody would say so out loud. Kanban says it for you.
What founders get wrong: Adopting Kanban without setting and enforcing WIP limits, which removes the entire mechanism by which Kanban works. A board with columns but no WIP limits is just a visualization, not a method. The discomfort of "we can't pull this in yet, the In Progress column is full" is the point; if the team routes around it, they've kept the appearance of Kanban and lost the substance.
Related: Scrum · Agile · Sprint · Product Backlog
FAQ
What is Kanban?
An agile method that visualizes work on a board with columns representing stages of completion and strictly limits work in progress (WIP) to expose bottlenecks and force flow. Treats work as a continuous stream rather than time-boxed sprints. Originated in Toyota manufacturing (1940s) and adapted to software by David J. Anderson in the 2000s.
What is the difference between Kanban and Scrum?
Scrum runs time-boxed sprints with fixed scope; Kanban runs continuous flow with WIP limits. Scrum has defined roles (Product Owner, Scrum Master); Kanban requires no specific roles. Scrum changes scope only at sprint boundaries; Kanban allows priority changes anytime as long as WIP limits hold.
What are WIP limits in Kanban?
Explicit caps on how many items can be in each column of the board at one time. They force the team to finish work before starting new work and expose bottlenecks immediately. Without WIP limits, Kanban becomes a visualization, not a method.
Find this article helpful?
This is just a small sample! Register to unlock our in-depth courses, hundreds of video courses, and a library of playbooks and articles to grow your startup fast. Let us Let us show you!
Submission confirms agreement to our Terms of Service and Privacy Policy.