EXIN Kanban Foundation cheat sheet

Kanban is a strategy for optimizing the flow of value through a process, using a visual signal system and limiting work in progress; it is not a project-management lifecycle or a team role model.

Core practices: visualize the workflow, limit work in progress (WIP), manage flow, make policies explicit, implement feedback loops, and improve collaboratively and experimentally.

The Kanban board shows columns as workflow states and cards as work items; the board must reflect the real process, including queues, buffers, and handoffs, not an idealized process.

WIP limits are explicit caps on the number of items allowed in a workflow state at one time; a full column signals a pull constraint, and new work is pulled only when capacity frees up.

Pull means downstream stages signal readiness and upstream stages release work only on that signal; push (assigning work regardless of downstream capacity) is what WIP limits are designed to prevent.

Little's Law: average lead time = average WIP / average throughput. Halving WIP at constant throughput halves lead time; raising throughput at constant WIP lowers lead time.

Lead time is measured from the moment a customer request is committed (or arrives, depending on the agreed start point) to delivery; cycle time is measured from when work starts to when it finishes. The start point must be defined explicitly.

Flow metrics include throughput (items completed per period), WIP (items in progress at a point in time), work item age (time since start), and flow efficiency (active time divided by total elapsed time).

Kanban is evolutionary and non-disruptive: it starts with the current process as it is, makes it visible, and improves it through small, measured changes rather than a prescribed reorganization.

Feedback-loop cadences in the Kanban Method include the daily standup (flow and blockers), replenishment (selecting new work), delivery planning (release scope), and the operations review (flow, metrics, and system-level issues).

A service-delivery review examines how well the service meets customer expectations; a risk review examines pending work items against risk dimensions such as size, complexity, and dependencies.

Classes of service (e.g., expedite, fixed date, standard, intangible) set explicit policies for how different item types are prioritized and treated on the board; expedite items typically get a dedicated lane and separate WIP allowance.

Blocked items should be made visible (flag, blocker column, or color) and tracked; blocked time is a major driver of poor flow efficiency and should be analyzed for systemic causes.

The Kanban Maturity Model describes levels of organizational maturity in adopting Kanban, from team-level visualization up to enterprise-wide fitness for purpose; it is a map, not a certification requirement.

STATIK (Systems Thinking Approach to Introducing Kanban) is a structured method for designing a Kanban system: understand purpose, understand sources of dissatisfaction, analyze demand, analyze capability, model the workflow, identify classes of service, design the Kanban system, and socialize/implement.

Change in Kanban is managed experimentally: state the hypothesis, define the measure, run the change over a defined period, review the data, and keep, adjust, or revert the change.

Kanban boards should show policies explicitly - definitions of ready and done, WIP limits, classes of service, and escalation rules - because unstated policies cause inconsistent decisions and hidden bottlenecks.

Kanban complements existing frameworks (Scrum, waterfall, DevOps) by adding flow visibility and WIP control to whatever process already exists; it does not require replacing the current method.