Skip to content
tezvyn:

Top 30 Kanban Interview Questions and Answers

30 multiple-choice questions on Kanban, drawn from 30 bites out of the 47 tagged Kanban on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

  1. Question 1 of 30

    A software development team consistently observes that their Lead Time is significantly longer than their Cycle Time. What does this disparity most likely suggest?

    Show the answer

    Answer: b · Significant bottlenecks exist in the workflow before or after the team's active development phase.

    The card explicitly states that "A large difference between Lead Time and Cycle Time signals that the biggest delays are happening outside of active development, in your queues and handoffs." Option A represents a common mistake, as focusing only on Cycle Time optimization ignores these larger, customer-impacting delays.

    Read the full bite: Cycle Time vs. Lead Time: Team Speed vs. Customer Wait

  2. Question 2 of 30

    A software team identifies its code review process as the primary constraint. According to the Theory of Constraints, which action should they prioritize before considering hiring more reviewers?

    Show the answer

    Answer: a · Implement stricter coding standards and encourage smaller pull requests to improve review efficiency.

    The Theory of Constraints (TOC) dictates that after identifying a constraint, the next step is to 'exploit' it by making the most of existing resources, such as improving review efficiency through better standards and smaller PRs (Option A). 'Elevating' the constraint, like hiring more reviewers (Option B), is a later step, only considered after exploiting and subordinating. Options C and D represent common misconceptions: focusing on local utilization or attempting to fix multiple bottlenecks at once, rather than the single primary constraint.

    Read the full bite: How would you identify and elevate your team's primary constraint?

  3. Question 3 of 30

    A team identifies that its manual QA process is the primary constraint, with work consistently piling up. According to the Theory of Constraints, what is the most effective initial action?

    Show the answer

    Answer: b · Analyze and improve the existing QA process to maximize its current efficiency.

    The first step after identifying a constraint is to 'Exploit' it—making the most of what you have. Hiring more people ('Elevate') is a later step, and improving a non-constraint (development speed) yields no system-wide benefit.

    Read the full bite: How would you identify and elevate a team's primary constraint?

  4. Question 4 of 30

    When evaluating success after launching a major workflow improvement, which approach best reflects agile outcome ownership?

    Show the answer

    Answer: a · Measure ticket throughput and cycle time for the workflow, gather qualitative stakeholder feedback, and visualize both in the iteration review.

    The correct answer blends quantitative workflow metrics with qualitative feedback and iteration-level visualization, which is the core of agile outcome ownership. Relying solely on uptime and bug counts treats operational stability as success rather than measuring delivered value.

    Read the full bite: How would you measure a launched feature's success and impact?

  5. Question 5 of 30

    What key element transforms a simple 'To Do, In Progress, Done' board into a true Kanban system for managing workflow and improving processes?

    Show the answer

    Answer: b · Implementing Work In Progress (WIP) limits on 'In Progress' columns to manage flow.

    The core mechanism of Kanban is managing flow by limiting Work In Progress (WIP). While detailed columns (D) are useful for visualization, it is the WIP limits that prevent overload and expose bottlenecks, thus enabling process improvement.

    Read the full bite: What columns would you set up on a new Kanban board?

  6. Question 6 of 30

    For a new team adopting Kanban, which initial set of columns is most recommended to visualize workflow effectively?

    Show the answer

    Answer: d · To Do, In Progress, Done

    The card emphasizes starting with a simple 'To Do, In Progress, Done' structure to visualize basic workflow and allow for evolution. Options B and C represent overly complex initial setups that impose a rigid process, while option B is too simplistic to effectively visualize flow.

    Read the full bite: What initial columns would you set up on a Kanban board?

  7. Question 7 of 30

    When launching a new Kanban board, which practice best reflects how the columns should be defined?

    Show the answer

    Answer: c · Start with Backlog, To Do, In Progress, and Done, then add columns only after the team spots actual bottlenecks

    Kanban starts simple with four columns representing basic workflow states so the team can visualize flow and evolve based on real bottlenecks. Adding many columns upfront seems thorough but imposes unvalidated process, while mapping columns to individuals treats the board as a personal tracker instead of a shared system view.

    Read the full bite: Describe the initial columns for a new Kanban board and their purpose

  8. Question 8 of 30

    A team's average Lead Time is significantly longer than its average Cycle Time. What does this most likely indicate about their process?

    Show the answer

    Answer: a · Work items are spending a long time in a backlog or queue before the team starts working on them.

    The gap between Lead Time (customer request to delivery) and Cycle Time (work start to finish) represents time an item spends waiting. A short Cycle Time with a long Lead Time means the team is efficient once work begins, but items wait a long time before being started.

    Read the full bite: Explain Lead Time vs. Cycle Time on a Kanban board

  9. Question 9 of 30

    A Kanban team tracks a user story from its initial request to its deployment. Which metric specifically measures the duration from when active development begins until the story is marked as done?

    Show the answer

    Answer: b · Cycle Time

    Cycle Time measures the duration from when active work starts on a task until it is completed. Lead Time, a common distractor, measures the total time from the initial request to final delivery, including any time spent waiting before work begins.

    Read the full bite: Lead Time vs. Cycle Time in Kanban

  10. Question 10 of 30

    A card enters the backlog on Monday, moves to In Progress on Wednesday, and reaches Done on Friday. How do you calculate its Cycle Time?

    Show the answer

    Answer: d · From Wednesday to Friday, using the timestamps when it entered In Progress and reached Done

    Cycle Time is the elapsed time from when work actively begins in an In Progress state until it reaches Done, so you use the Wednesday and Friday timestamps. Option B describes Lead Time because it incorrectly includes backlog wait time before work starts.

    Read the full bite: Lead Time vs Cycle Time in Kanban and measuring Cycle Time

  11. Question 11 of 30

    What is the most critical aspect of implementing Classes of Service, such as "Expedite" or "Standard," in a Kanban system?

    Show the answer

    Answer: c · Defining explicit pull policies that change how items from each class are handled by the system.

    The core of Classes of Service is creating different behavioral rules (pull policies) based on an item's cost of delay, not just relabeling priorities. Simply replacing labels like P0 with 'Expedite' misses the point entirely.

    Read the full bite: How would you implement Classes of Service in Kanban?

  12. Question 12 of 30

    What is the fundamental difference between a Kanban Class of Service and a simple priority level?

    Show the answer

    Answer: d · A Class of Service defines unique pull policies and processing rules, while a priority level indicates relative importance.

    A Class of Service is distinguished by its unique pull policy and explicit rules for how work is handled through the system, based on its risk profile or cost of delay. A simple priority level, in contrast, only indicates relative importance without dictating specific processing behaviors, which is a common misconception the card warns against.

    Read the full bite: How would you implement Classes of Service in Kanban?

  13. Question 13 of 30

    When implementing Classes of Service in Kanban, which practice is essential to manage risk without starving standard work?

    Show the answer

    Answer: c · Establish explicit policies and reserve WIP capacity for each class

    Classes of Service require explicit policies and reserved WIP capacity per class to protect flow and prevent urgent work from starving standard work. Option A is tempting because visualization matters, but color-coding alone without capacity rules is the red flag of treating classes as simple priorities.

    Read the full bite: How would you implement Classes of Service in Kanban?

  14. Question 14 of 30

    On a CFD, the Testing band is widening while the Done line maintains a constant upward slope. What does this indicate and how should you respond?

    Show the answer

    Answer: a · Work in progress is accumulating in Testing because arrivals exceed departures; run a batch-size experiment and track cycle time

    A widening band with a constant Done slope indicates Testing arrivals exceed departures, so throughput is delayed rather than zero. Hiring testers without data is a knee-jerk structural change; instead, you should first run a batch-size experiment and measure cycle time to validate the true constraint.

    Read the full bite: CFD Testing band widens: what does it indicate and what experiments?

  15. Question 15 of 30

    How does upstream Kanban most effectively protect downstream delivery performance?

    Show the answer

    Answer: c · By filtering and refining uncommitted options before they cross the commitment point

    Upstream Kanban improves downstream predictability by filtering noise and refining options through triage before they cross the commitment point, ensuring only ready work enters development. Rigid upfront planning sounds like strong governance but actually violates the system's purpose: it locks in scope too early instead of preserving the ability to defer commitment and discard weak options before they become expensive inventory.

    Read the full bite: Design an Upstream Kanban process for product ideas before development

  16. Question 16 of 30

    What is the most critical function of an Upstream Kanban process that distinguishes it from traditional backlog grooming?

    Show the answer

    Answer: c · Actively filtering and discarding options to manage demand before the team commits to the work.

    The core purpose of Upstream Kanban is to actively filter and discard options to match demand with capability. This is different from backlog grooming, which often just re-prioritizes an ever-growing list.

    Read the full bite: Design and Implement an Upstream Kanban Process

  17. Question 17 of 30

    Which element is most crucial for an Upstream Kanban to effectively manage product ideas, distinguishing it from a simple backlog?

    Show the answer

    Answer: b · Establishing a clear commitment point where options become decided-upon work items.

    The card emphasizes that the Commitment Point is the "critical gate" where an 'option' becomes a 'work item' and that without this clear line, the upstream process is just a messy 'to-do' list. This commitment point is essential for structured filtering and decision-making, distinguishing it from simple backlog management. While visualization (A) is a component, it's not sufficient without the commitment point and triage discipline.

    Read the full bite: Design an Upstream Kanban for Product Ideas

  18. Question 18 of 30

    In a Cumulative Flow Diagram, what does a steadily widening band for a specific workflow state primarily indicate?

    Show the answer

    Answer: d · Work items are entering that stage at a faster rate than they are being completed and moved to the next stage.

    The card explicitly states that "If a band gets wider over time, it means more work is entering that stage than leaving it, signaling a bottleneck." This directly corresponds to option D. Option B is a common misinterpretation, as CFDs are not for tracking individual performance but for identifying systemic issues.

    Read the full bite: Cumulative Flow Diagrams: Spotting Workflow Bottlenecks

  19. Question 19 of 30

    A team's Cumulative Flow Diagram shows the 'In Review' band has been steadily widening for several weeks. What is the most effective first step to address this?

    Show the answer

    Answer: a · Analyze historical data on PR size and review duration to identify potential root causes for the bottleneck.

    The correct approach is to diagnose the problem with data before proposing solutions. Analyzing metrics like PR size helps identify the root cause, whereas implementing a WIP limit or new SLAs without this data is a premature solution that may not address the actual problem.

    Read the full bite: Diagnosing a Widening Code Review Band in a CFD

  20. Question 20 of 30

    A CFD shows the Code Review band widening for several weeks while the Done line rises linearly. What does this pattern primarily indicate?

    Show the answer

    Answer: d · Work is accumulating in Code Review, signaling a bottleneck that should be addressed with system changes before adding headcount.

    A widening band alongside a linear Done line means work is piling up in Code Review, revealing a bottleneck that will increase cycle time. The most tempting distractor confuses queue growth with higher throughput, but the correct response is to apply WIP limits and swarm the queue before considering hiring.

    Read the full bite: What does a widening CFD Code Review band indicate?

  21. Question 21 of 30

    If reducing Kanban WIP limits fails to lower cycle time as predicted by Little's Law, what is the most likely root cause?

    Show the answer

    Answer: c · The system likely violated the stationarity assumption or contains hidden queues

    Little's Law is a conservation identity that only holds for stable systems, so a failed prediction first suggests stationarity was violated or work is trapped in unmeasured queues. Option A is tempting because candidates often confuse throughput with business arrival rate, but lambda in the law must be the actual departure rate, not the demand rate.

    Read the full bite: How would you apply Little's Law to optimize Kanban WIP limits?

  22. Question 22 of 30

    A team's average cycle time is too long. According to Little's Law, what is the most direct lever to pull to decrease it, assuming throughput remains constant?

    Show the answer

    Answer: a · Reduce the number of items being worked on simultaneously.

    Little's Law is Cycle Time = WIP / Throughput. If throughput is constant, the only way to decrease cycle time is to decrease Work in Progress (WIP). Increasing WIP to maximize utilization is a common but flawed approach that actually increases cycle time.

    Read the full bite: How would you apply Little's Law to a Kanban system?

  23. Question 23 of 30

    A Kanban team wants to reduce its average Cycle Time. Given their current stable Throughput, which action is the most direct application of Little's Law to achieve this goal?

    Show the answer

    Answer: a · Decrease the maximum number of items allowed in Work in Progress (WIP).

    Little's Law states that Cycle Time = WIP / Throughput. The card emphasizes that if Throughput is stable, the most direct way to reduce Cycle Time is by decreasing Work in Progress (WIP). While increasing throughput (option B) would also reduce cycle time, the card cautions against assuming arbitrary throughput increases and highlights WIP reduction as the primary actionable lever for cycle time improvement when throughput is stable.

    Read the full bite: Apply Little's Law to a Kanban system to optimize flow

  24. Question 24 of 30

    What is the fundamental nature of the "done" prediction provided by Actionable Agile Metrics?

    Show the answer

    Answer: b · A probabilistic forecast of completion, based on historical flow data and accounting for uncertainty.

    Actionable Agile Metrics provide a probabilistic forecast, acknowledging uncertainty, rather than a single, fragile date, as stated in the card. Option A is a tempting distractor because it mentions using historical data for an average, but the card explicitly warns against "misleading averages" and advocates for understanding the true distribution of delivery times.

    Read the full bite: Actionable Agile Metrics: Predicting 'Done'

  25. Question 25 of 30

    Why does a Kanban team enforce WIP limits rather than accepting more tasks whenever demand increases?

    Show the answer

    Answer: d · To constrain concurrent work and prioritize finishing items over starting new ones

    WIP limits are a flow control mechanism that caps concurrent work so teams finish existing items faster, reduce context switching, and expose bottlenecks. Option C is tempting because idle time feels wasteful, but Kanban optimizes throughput and flow, not individual utilization.

    Read the full bite: What is the primary purpose of a WIP limit in Kanban?

  26. Question 26 of 30

    What is the primary systemic purpose of implementing Work In Progress (WIP) limits in a Kanban system?

    Show the answer

    Answer: d · To optimize the flow of value by creating a pull system and making bottlenecks visible.

    The card emphasizes that WIP limits primarily optimize the flow of value through the system by creating a pull mechanism and exposing bottlenecks. While preventing multitasking (C) is a benefit, it is a consequence for individuals that contributes to the larger systemic goal, not the primary systemic purpose itself.

    Read the full bite: Purpose and Consequences of Kanban WIP Limits

  27. Question 27 of 30

    What is the primary reason for applying a 'Work in Progress' (WIP) limit in a Kanban system?

    Show the answer

    Answer: c · To optimize the flow of value by forcing the completion of existing work before starting new work.

    The primary goal of a WIP limit is to optimize the system's flow, creating a 'pull system' that prioritizes finishing tasks over starting new ones. While preventing burnout is a positive side effect, it's not the main purpose, which is focused on system efficiency (flow) rather than resource efficiency (utilization).

    Read the full bite: What is the purpose of a WIP limit in Kanban?

  28. Question 28 of 30

    If a team increases its Work In Progress (WIP) while its throughput stays the same, what is the most likely consequence according to Little's Law?

    Show the answer

    Answer: b · The average lead time for work items will increase.

    According to Little's Law (Lead Time = WIP / Throughput), if the WIP numerator increases while the throughput denominator stays constant, the resulting lead time must increase. A common misconception is that more parallel work decreases lead time, but this actually creates queues and context-switching, which increases delays.

    Read the full bite: Explain Little's Law and its application in Kanban

  29. Question 29 of 30

    A development team aims to significantly reduce its average lead time for delivering features. According to Little's Law, which strategy is most likely to achieve this goal?

    Show the answer

    Answer: a · Implement strict WIP limits to reduce the amount of work in progress.

    Little's Law states that Lead Time = WIP / Throughput. To reduce lead time, one must either decrease WIP or increase throughput. Implementing strict WIP limits directly reduces the 'WIP' variable, which is often the most immediate and controllable way to significantly shorten lead times. Increasing WIP, as in option D, would actually increase lead time.

    Read the full bite: Explain Little's Law and its application in Kanban

  30. Question 30 of 30

    A Kanban team wants to cut its average lead time without hiring more people. According to Little's Law, which approach is most effective in a stable system?

    Show the answer

    Answer: c · Lower WIP limits and focus on removing blockers from work already in progress

    Little's Law states Lead Time equals WIP divided by Throughput, so lowering WIP while protecting throughput directly reduces lead time. Increasing WIP or multitasking bloats queues without improving throughput, and pushing more work into the system destabilizes flow and lengthens lead time.

    Read the full bite: Explain Little's Law and its practical application in Kanban

Could you explain these out loud?

That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon