Kanban
Flow-based continuous delivery
Kanban is a flow-based method for managing work. Work items are visualised on a board, work-in-progress (WIP) is explicitly limited, and the goal is to maximise throughput and minimise cycle time rather than meet sprint targets. There are no fixed iterations — work flows continuously from request to delivery.
Originated at Toyota in the 1940s as a manufacturing scheduling system. Applied to software by David J. Anderson in 2007.
Use Kanban when
- ✓Work arrives unpredictably (support, bug fixes, ops requests)
- ✓You want to reduce multitasking and context-switching
- ✓Team is in maintenance mode or running continuous releases
- ✓You need a lightweight process with minimal ceremony overhead
Avoid it when
- ✗Stakeholders need predictable delivery dates (use Scrum's sprint cadence)
- ✗The team needs the structure of sprint goals to stay focused
- ✗You're building a new product that requires sustained discovery and planning cycles
Key Concepts
A cap on how many items can be in a given column at once. Forces finishing work before starting new work.
The time from when work starts to when it's done. Kanban teams optimise for shorter, more consistent cycle times.
The time from when a request is made to when it's delivered. Includes queue time.
The number of items completed per unit of time. The primary Kanban delivery metric.
A chart showing work in each stage over time. Bands widening = bottleneck forming.
Categories of work (e.g. expedite, standard, intangible) that get different WIP priority.
How it works
Map the workflow as columns on a board. Every step from "requested" to "done" gets a column.
Set explicit limits per column. Start with 1–2× team size and tighten over time.
Monitor cycle time and throughput. Use the CFD to spot bottlenecks before they block delivery.
Hold regular retrospectives. Adjust WIP limits, column definitions, and policies based on data.
Tools that support Kanban
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Spreadsheet-familiar interface makes adoption easy for teams transitioning from Excel — minimal training needed for basic use
Extremely intuitive drag-and-drop Kanban interface — virtually zero learning curve, new users productive within minutes
Best-in-class infinite canvas experience — the gold standard for collaborative whiteboarding with real-time multiplayer editing
Frequently Asked Questions
Yes — this is sometimes called Scrumban. Teams keep the sprint cadence for planning and retrospectives but use a Kanban board and WIP limits for day-to-day execution. Useful for teams transitioning between the two.
A common starting point is the number of people who work in that stage. If 3 engineers work on development, start with a WIP limit of 3. Observe for two weeks, then adjust. The goal is to surface bottlenecks, not eliminate all slack.
Most Kanban teams don't estimate in points. Instead, they use historical cycle time data to forecast: 'items like this typically take 3–5 days.' This is more honest than point-based estimation for variable work.