KMP common mistakes
KMP · Understand the traps and how to avoid them.
Treating WIP limits as per-column caps that are set once and never revisited, so the candidate answers questions about reducing lead time by saying 'raise the limit to increase throughput'.
Many candidates come from Scrum or project-management backgrounds where capacity is a number you assign per person, and they map that onto Kanban columns without grasping that the WIP limit is a pull-control on the whole workflow, not a staffing quota.
What to do instead
Study the difference between WIP limits as policy constraints on a system versus capacity per individual. Practise identifying which column is the constraint and how lowering a limit exposes bottlenecks before it 'increases throughput'. When a scenario asks about improving flow, the correct move is usually to reduce WIP at the constraint, not raise it.
Drawing a value stream map with columns for every handoff (e.g., 'dev done', 'QA queue', 'QA in progress', 'waiting for deploy') and calling each one a workflow state, producing a board with 12+ columns and no explicit policies.
Candidates confuse 'everything that happens' with 'workflow states worth visualising'. They think more granularity equals more control, and they forget that each column needs a defined entry/exit policy and a WIP limit to be a Kanban system.
What to do instead
Learn the rule that a column should represent a distinct state with a different policy and, ideally, a different owner or skill set. Merge queue-and-in-progress states unless the wait is a real constraint you intend to manage. Always pair each column with an explicit policy statement (definition of 'ready to pull' and 'done').
Confusing the Kanban Method's core practices with the Kanban board mechanics, so when asked 'what are the practices of the Kanban Method' the candidate lists 'columns, cards, WIP limits, swimlanes' instead of the actual practice set.
The board is the most visible artefact, so candidates memorise the visual elements and never internalise the underlying method (visualise the workflow, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively and evolve experimentally).
What to do instead
Memorise the six core practices as a named list and be able to give a one-line example of each. Distinguish 'practices' from 'board elements' in every practice question; if the answer options are board features, the question is probably about mechanics, not the method.
Answering questions about classes of service (expedite, fixed date, standard, intangible) by assigning every urgent item to 'expedite' and giving expedite items no WIP limit at all.
Candidates equate 'urgent' with 'expedite' and miss that expedite is a policy with a hard cap (often one card at a time) precisely because unbounded expediting destroys the flow it is meant to protect.
What to do instead
Learn each class of service with its selection rule and its WIP treatment: expedite is typically capped at a small number and may bypass limits but must be tracked; fixed-date items are sequenced by date; standard items are pulled FIFO by cost of delay; intangible items fill remaining capacity. Practise classifying scenarios by cost-of-delay profile rather than by emotional urgency.
When asked to design a system for a team with no existing process, the candidate immediately prescribes a full STATIK-style rollout with a target design, rather than starting from the current state.
Candidates want to demonstrate knowledge of the 'ideal' Kanban system and skip the method's principle of starting with what you do now and evolving experimentally. They also conflate STATIK (a specific workshop approach) with the whole of system design.
What to do instead
Internalise the change-management principles: start with what you do now, agree to pursue change incrementally, respect current roles and responsibilities, encourage leadership at all levels. In design questions, first map the current workflow as-is, then identify the first improvement experiment. Mention STATIK only when the question is explicitly about a structured design workshop.
Explaining Little's Law as 'throughput equals WIP divided by lead time' but then applying it backwards in a scenario, e.g., claiming that to reduce lead time you must increase WIP.
Candidates memorise the formula symbolically without understanding which variable is the dependent one. They also forget that Little's Law holds only for a stable system over a long period, so they apply it to a single day's data.
What to do instead
Practise the algebraic rearrangement three ways and rehearse the intuition: at constant throughput, more WIP means longer lead time. Work numerical scenarios where you are given two of the three values. Note the stability assumption explicitly when a question gives volatile or short-window data.
Treating a cumulative flow diagram as a burndown chart: reading the top line as 'work completed' and concluding that a widening band means the team is working harder, rather than diagnosing the widening band as WIP or queue growth.
Candidates are familiar with burndowns from other frameworks and transfer the wrong reading. They also do not know which band corresponds to which workflow state or how to read vertical distance (WIP) versus horizontal distance (lead time).
What to do instead
Learn to read the CFD in three directions: vertical thickness of a band = WIP in that state; horizontal distance between the arrival curve and the done curve = approximate lead time; slope of the top line = arrival rate versus departure rate. Practise diagnosing 'band widening near the end' as a downstream bottleneck or review queue.
Proposing 'add more people' or 'work overtime' as the improvement for a bottleneck shown in flow metrics, instead of addressing the policy or WIP that created the queue.
Candidates default to resource-based thinking and do not connect the systems-thinking lens to Kanban improvement. They miss that the exam expects improvements to come from policy changes, WIP reduction, and feedback loops before capacity changes.
What to do instead
Build a mental hierarchy of interventions: make policies explicit, reduce WIP at the constraint, rebalance work across states, then consider capacity. In scenario questions, look for the answer that changes a rule or flow rather than one that adds resources. Be ready to explain why adding capacity to a non-constraint worsens the queue.
Describing feedback loops only as the daily stand-up, ignoring the fuller set (e.g., replenishment, operations review, risk review, service delivery review, strategy review) and their different cadences and purposes.
Candidates map Kanban onto familiar ceremony names and assume one daily meeting covers all feedback needs. They do not distinguish operational cadence from delivery cadence from strategic cadence.
What to do instead
Learn the feedback-loop set with each loop's question and typical cadence: what work to pull next (replenishment), how the work is flowing day to day (daily), how well service is delivered (service delivery review), what risks and blockers exist (risk review), how the system is performing and changing (operations review), and where the organisation is going (strategy review). Match each scenario to the loop that answers its question.
When asked how to improve a system, the candidate prescribes a large redesign or a new tool, rather than framing improvement as a small, measurable experiment with a hypothesis and a review date.
Candidates want to show comprehensive knowledge and equate thoroughness with big change. They also underweight the method's principle of evolving experimentally and improving collaboratively, which the exam tests through scenario judgement.
What to do instead
Use an experiment template in your answers: current condition, hypothesis, the single change, the metric that will show effect, and when it will be reviewed. Prefer the smallest change that tests the hypothesis. Explicitly involve the people doing the work in designing the experiment, and name the feedback loop where results will be reviewed.