KSD cheat sheet

Service purpose answers two questions: what customer need is met, and what the service does to meet it; both must be stated in one sentence a customer would recognize.

A purpose statement is testable when it names the beneficiary, the outcome, and the boundary of what the service will not do.

Customer, not internal department, defines value; internal stakeholders are constraints on delivery, not the source of purpose.

Demand is the rate and pattern of work arriving; capacity is the rate the system can complete work; purpose is only achievable when demand is understood against capacity.

Distinguish the service (ongoing co-created value) from the product (what is exchanged) and the outcome (change in the customer's condition).

Three questions to validate purpose: Who is worse off without us? What measurable change do we cause? What would we refuse to do?

Purpose drift signal: work items that no stated purpose explains accumulate in queues and consume capacity without a customer outcome.

Purpose is the anchor for every later decision (classes of service, policies, WIP limits); if purpose is unclear, prioritization becomes opinion.

Classes of service are named categories of work with explicit policies for priority, WIP allocation, and expected time; typical set: expedite, fixed-date, standard, intangible.

Expedite class rule: capacity reserved (commonly one slot or a small percentage of WIP), each item requires explicit sponsor approval, and expedited items are capped so the class cannot starve standard work.

Fixed-date class: work is pulled by date risk, not arrival order; start no later than the last responsible moment computed from lead time and due date.

Standard class: pulled in FIFO order within its WIP allocation; no reordering without changing the item's class.

Intangible class: cost of delay is low or deferred; pulled only when capacity is otherwise idle, so it never displaces value-bearing work.

A policy is a written rule that says who decides, on what information, within what limit; unwritten conventions are not policies and cannot be audited.

Capacity is designed, not discovered: set WIP limits per column and per class so total WIP equals the number of work items the system can finish at its current cycle time.

Definition of ready and definition of done are policies at the workflow boundaries; they gate entry and exit and prevent partial work from consuming capacity.

Core flow metrics: WIP, throughput (items per period), cycle time (start to finish), and work item age (elapsed time since start for unfinished items).

Little's Law: average cycle time = average WIP / average throughput; use it to predict the effect of a WIP change before making it.

Lead time clock starts at customer request; cycle time clock starts when work begins; report which clock you use or numbers are not comparable.

Work item age is the earliest warning signal: items older than the 85th percentile of historical cycle time are at risk now, not at the deadline.

Cumulative flow diagram bands widening indicate a bottleneck upstream of the widening column; flat arrival and departure lines indicate balanced flow.

Feedback loop cadence: daily flow review on blocked and aging items, periodic retrospective on policies and classes of service, both tied to data not anecdote.

A next experiment is written as: hypothesis, change to one policy or limit, metric and threshold, time box, and decision rule for adopt or revert.

Change one variable per experiment; simultaneous changes to WIP limit, class policy, and staffing make the result uninterpretable.

Map the full value stream from customer request to customer outcome, including queues, handoffs, approvals, and rework loops, not just the team's own steps.

Local optimization test: an improvement that reduces one station's cycle time but increases total lead time has made the system worse.

Queues are the dominant cost in knowledge work; queue size grows with capacity utilization, so utilization near 100% produces long and unpredictable lead times.

Handoffs add wait time and information loss; count handoffs as a first-class metric when diagnosing delay.

Rework loops are hidden capacity drains; measure the percentage of items that return to an earlier stage to size the loss.

Bottleneck rule: system throughput is set by the constraint; improving non-constraint steps increases WIP, not output.

Feedback delays between cause and effect make the system feel unpredictable; shorten the loop before adding control mechanisms.

Variation exists in arrival rate and in processing time; policies should absorb variation (buffers, classes of service) rather than pretend it is absent.

STATIK stands for Systems Thinking Approach To Introducing Kanban; it is a six-step method for designing a kanban system for a specific context.

Step 1: understand what makes the service fit for purpose, identifying customer expectations and the sources of dissatisfaction.

Step 2: analyze demand, its sources, and its patterns (types, volumes, variability, predictability) to shape classes of service.

Step 3: analyze the system's capability, including capacity, skills, and current performance against demand.

Step 4: model the workflow by discovering the actual steps and handoffs, then visualize them on a board.

Step 5: identify classes of service and set explicit policies for each, including priority and WIP allocation.

Step 6: design the kanban system: WIP limits, cadences, and feedback meetings, then run it and iterate; STATIK is a design loop, not a one-time event.

STATIK output is a working system hypothesis; validate it against demand and capability data before scaling the board.

Visualize every work item as a card and every stage as a column; if work is not on the board it cannot be limited, measured, or pulled.

Blocked items are marked explicitly with the reason and the owner; blocked work still occupies WIP and must be counted.

Pull means a worker starts a new item only when capacity frees up under the WIP limit; push means assigning work regardless of capacity.

WIP limit rule: when a column is at its limit, stop starting and swarm on finishing; the limit is a commitment, not a suggestion.

Pull with intention means the pull decision uses class of service and age, not just availability; FIFO within class, age-based escalation for risk.

Board design must expose policies: classes of service, definitions of ready and done, and the WIP limit per column visible on the board itself.

Measure flow from the board: count items in each column, compute work item age, and plot cumulative flow to see where work accumulates.

Explicit pull signals replace verbal coordination; the signal is the empty slot under the limit, so the system self-regulates without a dispatcher.