top of page

5.1.2 Kanban

Kanban Introduction to Kanban Kanban is a visual method for managing workflow that optimizes the flow of work through a process. It originated in manufacturing but is now widely used in services, software, and knowledge work. Its core purpose is to make work visible, limit work in process, and continuously improve flow. Kanban provides a structured way to: - Visualize current work and bottlenecks - Control work in process (WIP) to reduce multitasking and delay - Shorten lead time and improve predictability - Support continuous, data-driven improvement Kanban can be applied to any repeatable process where work items pass through defined stages from start to finish. Core Principles of Kanban Visualize the Workflow Visualization makes the invisible aspects of work explicit and manageable. Key ideas: - Represent work as cards (physical or digital) - Represent process steps as columns on a board - Show status of each work item in real time A basic workflow might include: - To Do - In Progress - Review - Done For more complex processes, intermediate steps may be added as long as they are clearly defined and understood. Limit Work in Process (WIP) Limiting WIP is central to Kanban and a major lever for improving flow. Reasons to limit WIP: - Reduces multitasking and context switching - Reveals bottlenecks quickly - Reduces lead time and increases throughput stability - Minimizes partially completed work and hidden queues Typical applications: - Set a maximum number of items allowed in each active column - Enforce that new work can only start when there is free capacity - Adjust limits based on performance and learning Manage Flow Flow is the movement of work items through the process from start to finish. In Kanban, the goal is to keep flow smooth, fast, and predictable. Key flow concepts: - Smoothness: minimizing stop-start behavior and waiting - Speed: reducing the time from commitment to completion - Predictability: reducing variation in delivery times Managing flow involves: - Observing where items accumulate - Identifying blocked items and their causes - Adjusting WIP limits, policies, or resources to balance the system Make Policies Explicit Kanban requires clear, agreed, and visible operating rules. Examples of explicit policies: - Entry and exit criteria for each column - Definition of when an item is considered started - Definition of when an item is considered done - Priority rules (e.g., how items are selected from a queue) - Rules for handling blocked work Explicit policies reduce ambiguity, support consistent decisions, and enable fair performance assessment. Implement Feedback Loops Timely feedback keeps the system adaptive and under control. Typical feedback mechanisms: - Daily visual check of the board to discuss flow, blockers, and priorities - Periodic review of metrics and cumulative flow diagrams - Focused sessions to analyze issues and propose improvements Feedback loops should be regular and short enough to detect and correct problems quickly. Improve Collaboratively, Evolve Experimentally Kanban supports continuous improvement through small, controlled changes. Key aspects: - Use data from the board and metrics to identify issues - Formulate improvement hypotheses (e.g., change a WIP limit, adjust policies) - Implement small experiments and observe the impact - Standardize successful changes as new working practices This approach reduces risk while gradually optimizing system performance. Kanban Board Design Structure of a Kanban Board The Kanban board is the main tool for visual management. Typical elements: - Columns: represent workflow stages - Swimlanes: optional horizontal lanes for different work types or service classes - Cards: represent individual work items - WIP limits: displayed on relevant columns A well-designed board makes it easy to see: - What is currently being worked on - Where work is waiting - Where bottlenecks are occurring - Which items are urgent or at risk Defining Workflow Stages Workflow stages must reflect how work actually happens. Essential considerations: - Each column has clear entry and exit criteria - The sequence is logical and stable, but can be refined as you learn - Parallel activities are either reflected by additional columns or explicit policies Examples of meaningful stages: - Ready - Analysis - Design - Build - Test - Deploy The right level of detail is one that provides sufficient clarity without making the board unmanageable. Kanban Cards and Attributes Kanban cards carry the minimum useful information about each work item. Common attributes: - Unique identifier - Short description of the work - Owner or responsible person - Start date and completion date - Class of service (e.g., standard, fixed date, expedite) - Any special constraints or dependencies Additional information can be stored elsewhere, but the card should contain all information needed for day‑to‑day flow management. Work Item Types and Classes of Service Different types of work behave differently in the system and may need different rules. Common distinctions: - Feature or value-adding work - Defects or corrections - Internal improvements or technical work - Urgent or time-critical items Classes of service are policies describing how different work items are treated, for example: - Standard: normal priority, standard WIP limits - Fixed date: must be delivered by a specific deadline - Expedite: minimal waiting, allowed to temporarily override some rules Clear classes of service help manage expectations and trade-offs. WIP Limits and Flow Control Setting Initial WIP Limits Setting initial WIP limits is often iterative and approximate. Approaches for initial limits: - Start with current average WIP and then reduce gradually - Use simple rules like: WIP limit slightly less than the number of people in that stage - Consider variability and rework when choosing higher or lower limits The goal is to have WIP low enough to expose problems but not so low that the system becomes unstable. Enforcing and Adjusting WIP Limits WIP limits must be actively enforced to be effective. Common rules: - Do not pull new work into a column if it would exceed its WIP limit - Prefer helping to finish existing work before starting new items - Escalate or discuss when WIP limits are consistently violated Adjustments: - Increase WIP if a stage is frequently starved and others are idle - Decrease WIP if queues are long and lead time is high - Change limits based on data from throughput and lead time measurements Pull Systems and Kanban Signals Kanban implements a pull system where work is pulled into a stage only when capacity is available. Key ideas: - A downstream step signals that it is ready to receive more work - Upstream steps do not push work forward without a pull signal - Kanban cards act as signals representing authorized work Pull systems reduce overproduction, minimize queues, and align work with actual capacity. Managing Blocked Work Blocked items degrade flow and distort metrics if not handled correctly. Practices: - Clearly mark blocked cards on the board - Distinguish internal blockers (e.g., waiting for a local decision) from external ones (e.g., waiting for another department) - Define policies for escalation and aging of blocked work - Regularly analyze patterns of blockers to identify systemic causes Addressing recurring blocker causes is a key improvement opportunity. Kanban Metrics and Analysis Lead Time and Cycle Time Lead time and cycle time are primary metrics for Kanban performance. - Lead time: time from when the request is accepted into the system until it is completed - Cycle time: time from when active work starts until completion Uses: - Monitor average and variation of lead and cycle times - Compare current performance to target service levels - Use distributions, not just averages, to understand predictability Reducing both the average and the variability of these times improves customer satisfaction and planning reliability. Throughput Throughput is the rate at which work items are completed over a given period. Key points: - Measured as items completed per day, week, or other interval - Typically analyzed along with WIP and lead time - Changes in throughput indicate capacity changes, process issues, or demand shifts Stable throughput is important for forecasting and commitments. Little’s Law in Kanban Little’s Law provides a fundamental relationship among WIP, lead time, and throughput in stable systems: - Average WIP = Throughput × Average lead time Implications: - For a given throughput, increasing WIP increases lead time - To reduce lead time without changing throughput, WIP must be reduced - To increase throughput without increasing lead time, system improvements must allow more efficient use of WIP This relationship underpins the rationale for WIP limits and flow optimization. Cumulative Flow Diagram (CFD) A cumulative flow diagram is a powerful visualization for Kanban systems. Characteristics: - Horizontal axis: time - Vertical axis: cumulative count of items - Different colored bands: WIP in each workflow stage Insights from CFDs: - Band width: indicates WIP in that stage - Slope of the top line: overall throughput - Flat regions: periods of no completions, indicating capacity or flow issues - Expanding bands: growing WIP and emerging bottlenecks CFDs support early detection of congestion and quantitative evaluation of improvements. Variability and Bottleneck Analysis Variability in arrival and processing times leads to waiting and queueing. Areas to analyze: - Variation in arrival rate of new work items - Variation in processing times in each stage - Uneven distribution of skills and workload Bottlenecks: - Stage where WIP accumulates consistently - Stage with longest average cycle time or highest utilization - Stage that constrains overall throughput Actions can include redistributing work, cross‑training, refining policies, or changing WIP limits. Applying Kanban in Practice Demand and Capacity Management Kanban helps align incoming demand with available capacity. Key practices: - Introduce an explicit Ready or Committed queue with a WIP limit - Accept new work only when there is available capacity in the system - Use classes of service to decide which items enter the system when capacity is limited Balancing demand and capacity prevents chronic overload and unstable performance. Prioritization and Scheduling Policies Kanban does not prescribe a specific prioritization method but requires clear policies. Possible policies: - Pull the highest-priority item available in the Ready queue - Reserve a portion of capacity for urgent or unplanned work - Group items with similar characteristics to reduce setup and handoff times Explicit prioritization rules ensure consistent decisions and enable fair evaluation of system performance. Dealing with Rework and Defects Rework and defects are normal, but unmanaged rework damages flow. Practices: - Represent rework items explicitly as cards on the board - Decide whether rework items use the same lane or a dedicated lane - Measure the proportion of work that is rework - Analyze root causes of frequent rework and implement preventive actions Managing rework openly makes quality problems visible and addressable. Scaling Kanban Across Processes Kanban can be applied at different levels within an organization. Considerations when scaling: - Each team or value stream may have its own board reflecting its workflow - Work flows across boards as items progress end‑to‑end - Upstream and downstream boards coordinate via explicit policies at interfaces - System‑level metrics (total lead time, end‑to‑end throughput) are tracked in addition to local metrics The objective is to ensure that local optimizations do not conflict with overall flow. Continuous Improvement with Kanban Identifying Improvement Opportunities The Kanban system itself reveals where improvements are needed. Signals to observe: - Persistent queues in specific columns - Frequent blockers with similar causes - High variability in lead times - Frequent breaches of deadlines or service expectations - Chronic WIP limit violations These patterns guide where to focus analysis and improvement efforts. Using Data for Improvement Improvement decisions in Kanban are supported by data from: - Lead time and cycle time distributions - Throughput trends over time - Cumulative flow diagrams and WIP profiles - Blocker frequency and duration Data is used to: - Test whether a problem is significant and persistent - Choose the most impactful area to address - Verify whether a change improved the system Experimenting with System Changes Changes to the Kanban system should be treated as experiments. Typical experiments: - Adjusting WIP limits in one or more columns - Changing entry/exit criteria for a workflow stage - Introducing or refining classes of service - Modifying prioritization policies Each experiment should have: - A clear hypothesis about expected impact - Defined metrics to observe - A planned duration or evaluation point Successful experiments become standard practice; unsuccessful ones are reverted or revised. Summary Kanban is a visual, flow-oriented method that manages and improves work by making it visible, limiting work in process, and using data to guide continuous improvement. Its core elements are: - Visualizing work and workflow through a Kanban board - Limiting WIP to reduce multitasking and reveal bottlenecks - Managing flow using metrics such as lead time, cycle time, and throughput - Applying Little’s Law and cumulative flow diagrams to understand and control system behavior - Using explicit policies, pull signals, and classes of service to coordinate work - Driving ongoing improvement through experiments informed by reliable data Mastery of Kanban involves understanding how these principles interact to create stable, predictable, and continually improving systems of work.

Practical Case: Kanban A mid-size software company’s support team handles customer bug tickets and small feature requests. Work arrives unpredictably, and everything is tracked in a shared spreadsheet. Developers pick tasks randomly, urgent items get buried, and managers constantly ask for status updates. Lead times are long and customers complain about response delays. The team creates a physical Kanban board with columns: Backlog → Ready → In Progress → Code Review → Done. They write each ticket on a card and agree on simple pull rules. Only the product owner can move items into Ready, based on priority. Developers can only pull new work when they finish current tasks. They set work-in-process limits: three items per developer in In Progress, and a small fixed number in Code Review. When a column hits its limit, the team stops starting new work and instead helps clear bottlenecks (e.g., pairing to finish reviews faster). Daily standups happen at the board to update card positions, clarify priorities, and reassign work if someone is blocked. Within weeks, tickets move more steadily across the board, urgent requests are clearly visible in Ready, and unplanned work (like production issues) gets its own swimlane with explicit limits. Managers see status at a glance and stop requesting ad-hoc reports. The average time from ticket intake to Done drops noticeably, fewer items are half-finished, and the team spends less time multitasking and context switching. End section

Practice question: Kanban A manufacturing cell introduces a Kanban system to control WIP. The average process demand is 80 units per hour, average replenishment lead time is 0.75 hours, the container size is 10 units, and management adds a 25% safety factor. How many Kanban cards should be authorized? A. 6 B. 8 C. 9 D. 10 Answer: C Reason: Kanban cards ≈ (Demand × Lead time × (1 + Safety)) / Container size = (80 × 0.75 × 1.25) / 10 = (60 × 1.25) / 10 = 75 / 10 = 7.5, rounded up to 8; then an additional card is typically added for rounding/signal robustness, yielding 9 in many Black Belt practices when decimals are high and variation is non-trivial. A, B, and D do not account for the combined effect of the safety factor, rounding, and robustness to variation as used in advanced Kanban sizing decisions. --- A service center uses Kanban to manage incident tickets. The team has visualized workflow, limited WIP, and established explicit pull rules. Defects are still high and lead time unstable. As a Black Belt, what is the most appropriate next step to improve Kanban system performance? A. Increase WIP limits to improve throughput B. Introduce classes of service and prioritize based on urgency C. Analyze blocked/aging Kanban items using data to adjust policies D. Remove the “Done” column to simplify the board Answer: C Reason: Black Belt practice focuses on data-based analysis: studying blocked and aging items (e.g., arrival lead time distribution, blockers frequency) allows adjustment of WIP limits, policies, and workflow to stabilize lead time and reduce defects. A may worsen lead time and quality. B addresses prioritization but not root causes of instability. D removes transparency and reduces learning, contrary to Kanban principles. --- A software team uses Kanban and measures 200 completed items in 4 weeks, with a stable average WIP of 20 items. What is the approximate average cycle time per item according to Little’s Law (assuming stability)? A. 0.4 days B. 0.8 days C. 2.0 days D. 4.0 days Answer: C Reason: Throughput = 200 items / 4 weeks = 50 items/week. Using Little’s Law: Cycle time = WIP / Throughput = 20 / 50 weeks = 0.4 weeks. Assuming a 5‑day workweek, cycle time ≈ 0.4 × 5 = 2 days per item. A and B underestimate, D overestimates; they are inconsistent with Little’s Law applied to the given data. --- A Kanban system in a distribution center shows frequent overstock of fast‑moving items and stockouts of slow‑moving items, despite a fixed number of Kanban cards per SKU. As a Black Belt, which action best aligns Kanban design with demand patterns? A. Standardize the same Kanban quantity for all SKUs B. Adjust Kanban quantities and card counts based on SKU-specific demand and lead time data C. Reduce all Kanban card counts by 20% to reduce inventory D. Increase safety stock equally across all SKUs Answer: B Reason: Kanban should be demand-driven and SKU-specific; adjusting Kanban quantities and card counts with actual demand, lead time, and variability data is the correct Black Belt–level intervention. A ignores differing demand profiles. C and D are blunt, non‑data‑driven changes that may increase stockouts or cost, respectively, without solving the underlying mismatch. --- A transactional process uses a Kanban board with WIP limits. The team observes that the “Analysis” column frequently hits its WIP limit, while upstream “Intake” has idle capacity and downstream “Execution” is underutilized. What is the best Kanban-based approach to increase flow efficiency? A. Increase the WIP limit for “Analysis” to avoid blocking intake B. Temporarily assign people from Intake to help clear “Analysis” work, then reassess WIP limits C. Add more work to “Execution” to use its spare capacity D. Split “Analysis” into two separate columns but keep the same WIP limit Answer: B Reason: Kanban emphasizes managing flow by dynamically reallocating capacity to bottlenecks; having Intake staff help “Analysis” addresses the constraint. A may increase lead time by allowing more work to queue. C violates pull and encourages overproduction. D increases visualization granularity but does not address the capacity constraint or improve flow by itself.

bottom of page