10.2 Kanban Framework

10.2 Kanban Framework

Originating from the Toyota Production System (TPS) and adapted for knowledge work by David J. Anderson, Kanban is an evolutionary method for managing and improving work systems. Unlike Scrum, which relies on fixed timeboxed iterations, Kanban is a flow-based approach that emphasizes continuous delivery, workload optimization, and minimizing system friction.

The Core Philosophy & 6 Core Practices of Kanban

Kanban does not require altering existing roles or organizational structures immediately; instead, it starts with the current process and drives continuous incremental improvement (Kaizen). The Kanban Method is commonly taught through 6 Core Practices:

1. Visualize the Workflow

The first step is making invisible knowledge work visible. Using a Kanban Board, work items are represented as cards moving across vertical columns representing workflow stages (e.g., To Do, Analysis, Development, Testing, Deployment). Visualizing work reveals hidden dependencies, queues, and operational bottlenecks.

2. Limit Work in Progress (WIP)

Imposing explicit WIP Limits on workflow columns prevents teams from taking on more work than their capacity allows. WIP limits transform a push system into a pull system, where team members pull new work into a column only when existing items move out, adhering to the principle: "Stop starting, start finishing."

3. Manage Flow

Flow refers to the movement of work items through the production system. Managing flow involves monitoring how smoothly work items progress, minimizing idle time, avoiding context switching, and proactively clearing blockers.

4. Make Policies Explicit

Make workflow definitions and operating policies explicit and accessible to the people managing the work. A physical display is not required, and the policy should fit the service. Explicit policies remove ambiguity and empower self-organizing teams to make consistent operational decisions.

5. Implement Feedback Loops

Kanban utilizes structured reviews (known as Kanban Cadences) at operational, strategy, and service-delivery levels. Key feedback loops include the Daily Standup (Kanban Meeting), Strategy Review, Service Delivery Review, and Operations Review.

6. Improve Collaboratively, Evolve Experimentally

Kanban promotes scientific, empirical improvement. Teams use models (such as the Theory of Constraints or Lean waste principles) to form hypotheses, execute small process experiments, measure results, and evolve continuously.

Flow Metrics, Little's Law & Service Level Expectations (SLE)

Quantitative measurement is central to Kanban. Rather than estimating work in relative story points or velocity, The current Kanban Guide identifies four required flow metrics:

1. Work in Progress (WIP): The number of work items that have started but not finished.
2. Throughput: The number of work items finished per unit of time; count items rather than a story-point total.
3. Work Item Age: The elapsed time between an item's start and the current time while it remains unfinished.
4. Cycle Time: The elapsed time from when an item starts until it finishes.

A team may also measure broader lead time from request to delivery. State the start and finish boundaries whenever using either term.

Customer Request Created
      │
      ├────────────────────── LEAD TIME ──────────────────────┐
      │                                                       │
      ▼                                                       ▼
[Backlog Entry] ───► [Work Started] ───────────────► [Work Delivered]
                          │                                   │
                          └────────── CYCLE TIME ─────────────┘

Little's Law in Flow Systems

For a stable system observed over a consistent boundary and period, Little's Law relates average WIP, average throughput, and average time in the system:

$\text{Lead Time} = \frac{\text{WIP}}{\text{Throughput}}$

Alternatively, for active execution within team boundaries:

$\text{Cycle Time} = \frac{\text{WIP}}{\text{Throughput}}$

Practical Example & Exam Math:

Suppose a software team maintains an average WIP of 24 work items across active columns, and their historical Throughput is 4 items per day.

• Using Little's Law: $\text{Cycle Time} = \frac{24\text{ items}}{4\text{ items/day}} = 6\text{ days}$.
• If a stable-system planning scenario targets an average Cycle Time of 4 days while Throughput remains 4 items/day, the corresponding target average WIP is: $\text{WIP} = \text{Cycle Time} \times \text{Throughput} = 4\text{ days} \times 4\text{ items/day} = 16\text{ items}$

A lower average WIP is associated with a lower average cycle time when throughput and system stability hold. Changing a board limit is an experiment, not a guarantee; monitor work-item age, blocked work, throughput, and cycle-time distribution to verify the effect.

Service Level Expectations (SLE)

A Service Level Expectation (SLE) is a probabilistic forecast based on historical Cycle Time data. An SLE consists of two components: a time duration and an associated probability (e.g., "85% of work items are completed in 10 days or fewer").

Unlike deterministic rigid deadlines, an SLE uses statistical distribution (often derived from a Cycle Time Scatterplot) to help teams manage customer expectations realistically and flag aging work items before they breach SLA thresholds.

Cumulative Flow Diagram (CFD) Analysis & Classes of Service

A Cumulative Flow Diagram (CFD) is a useful Kanban diagnostic. A CFD charts the cumulative total number of work items in each state of the workflow over time.

Total Items
   ▲
   │                              / Completed (Departure Line)
   │                             /
   │                            /  <--- Slope = Throughput
   │                           /
   │           /--------------/ Testing
   │          /--------------/  <--- Vertical Distance = WIP
   │         /--------------/ Development
   │        /--------------/ Analysis
   │       / (Arrival Line)
   └──────────────────────────────────────────► Time
           |<--- Horizontal Distance = Lead Time --->|

Key CFD Diagnostic Indicators:

• Horizontal Distance: The horizontal gap between the top boundary (arrival) and the bottom boundary (departure) represents the Lead Time (or Cycle Time) for items entering the system at that time.
• Vertical Distance: The vertical gap between two lines represents the total WIP present in that state or set of states.
• Line Slope: The slope of the top line represents the Arrival Rate, while the slope of the bottom line represents the Departure Rate (Throughput). Parallel lines indicate a stable system.
• Widening Band: A widening section in a specific stage indicates a bottleneck—work is arriving faster than it can be processed, causing WIP to accumulate.
• Narrowing Band: A narrowing section indicates starvation or capacity underutilization in that workflow stage.

Classes of Service

Not all work items carry equal risk or cost of delay. The Kanban Method commonly uses four Classes of Service to determine how they should be prioritized and pulled through the system:

Explicit class-of-service and WIP policies help teams balance urgency with flow; inspect the data because no class policy guarantees stability.