EXIN Kanban Foundation common mistakes
EXIN Kanban Foundation · Understand the traps and how to avoid them.
Treating WIP limits as targets or minimums, so a column with a limit of 3 is kept filled with 3 items and new work is pulled as soon as a slot frees, even when the downstream column is not ready.
Candidates carry over a 'keep everyone busy' mental model from traditional project management and read the limit number as capacity to be used rather than a ceiling that exposes flow problems.
What to do instead
State explicitly that a WIP limit is a maximum, not a quota; work is pulled only when the downstream step has capacity and the item is ready. Practise explaining that an empty slot is acceptable and that lowering limits is how the team improves flow.
Describing Kanban as requiring fixed-length iterations, sprint planning, or a timeboxed cadence as a mandatory element, and confusing it with Scrum.
Many candidates have studied Scrum first and assume every agile method uses sprints; the word 'cadence' in Kanban material reinforces the confusion.
What to do instead
Memorise the distinction: Kanban is continuous flow with no mandatory iterations. Cadence in Kanban refers to regular replenishment and review meetings and to the rhythm of releases, not to timeboxed development sprints. If iterations are used, they are an optional overlay, not part of the method's definition.
Listing the Kanban practices but omitting one or more of them, most often 'make policies explicit' or 'implement feedback loops', and presenting 'visualise the workflow' and 'limit WIP' as the whole method.
The first two practices are the most memorable and the most discussed, so the remaining four get less rehearsal.
What to do instead
Memorise the full set as a fixed list of six: visualise the workflow, limit work in progress, manage flow, make policies explicit, implement feedback loops, improve collaboratively and evolve experimentally. Recite them in order and attach one concrete example to each so none can drop out under exam pressure.
Confusing cycle time with lead time, or defining both from the wrong start and end points, for example measuring cycle time from customer request to delivery.
Both measure elapsed time for work items and the terms are used loosely in industry writing; candidates rely on intuition rather than a precise definition.
What to do instead
Fix the definitions: lead time runs from the moment the customer requests or the item enters the system to the moment it is delivered; cycle time runs from when work actually starts on the item to when it is done. On a board, lead time is measured from the first column (including the waiting/queue column) and cycle time from the column where committed work begins. Draw a simple board and mark both intervals until the mapping is automatic.
Describing a cumulative flow diagram incorrectly, such as reading the vertical axis as time, treating a widening band as improvement, or failing to recognise that a growing horizontal gap between two bands indicates rising WIP and longer lead time.
Candidates learn the diagram's shape visually but never learn what each axis and each band boundary represents, so they cannot interpret the slope of the arrival and departure lines.
What to do instead
Learn the anatomy: horizontal axis is time, vertical axis is cumulative count of work items, each band is a workflow state, the top line is arrivals and the bottom line is departures. The vertical distance between two adjacent boundaries is the WIP in that state; a widening vertical gap means WIP is growing. The horizontal distance between the arrival and departure lines approximates lead time. Practise interpreting three described shapes: stable, WIP ballooning, and a bottleneck band thickening.
Treating the Kanban board as a status-reporting dashboard that is updated after the fact, rather than as the team's working model that is updated as work moves and used to make decisions.
Candidates equate visualisation with reporting to management and miss the purpose of making work and its policies visible to the people doing the work.
What to do instead
Explain that the board is the single source of truth for the team, updated in real time as items move, and that its purpose is to support pull decisions, surface blockers, and make policies visible. Reporting is a by-product, not the goal. When answering scenario questions, choose the option where the team uses the board to decide what to pull next over the option where the board informs stakeholders.
Confusing classes of service with priority levels, or failing to identify expedite as the class that bypasses WIP limits (usually with an explicit, limited policy) while fixed-date and standard items do not.
Classes of service are a small part of the syllabus and candidates treat them as a ranking scheme rather than as policies for handling different risk and cost-of-delay profiles.
What to do instead
Learn each class by its policy consequence: expedite items are pulled immediately and may exceed WIP limits, typically limited to one at a time and tracked separately; fixed-date items are sequenced to meet a deadline; standard items follow normal pull rules; intangible items are low-cost-of-delay work done when capacity allows. Match each class to what it changes on the board, not to a number.
Describing a pull system as push with a limit, for example saying the upstream team 'assigns' work to the next column or that a manager prioritises the queue on the team's behalf, and missing that the downstream step signals capacity.
Most candidates have worked in push systems and unconsciously reproduce them; the mechanics of pull signals are abstract and rarely observed in practice.
What to do instead
State the mechanism precisely: the downstream step, when it has free capacity under its WIP limit, pulls the next eligible item according to an explicit policy; upstream does not push. Rehearse one concrete example, such as a tester pulling from 'ready for test' only when below the test WIP limit, and use it to answer any pull-versus-push question.
Answering improvement questions with 'hold a retrospective and agree actions' or 'run a Kaizen event' without linking to the Kanban-specific mechanisms of feedback loops, explicit policies, and the evolutionary, experimental approach of small changes measured against flow metrics.
Generic agile vocabulary is easy to produce and feels safe, so candidates substitute it for the method-specific answer the question is testing.
What to do instead
Anchor improvement answers in the sixth practice: improve collaboratively and evolve experimentally. Mention making a policy change explicit, running it as a small experiment, and evaluating it with flow metrics such as cycle time, throughput, and WIP. Name the feedback loops at the cadence levels the method describes rather than only a retrospective.
Treating Kanban as applicable only to operations or support work, or as requiring a specific tool, team size, or role structure such as a Kanban master.
Candidates over-generalise from the method's origins in support and maintenance and from tool marketing, and they assume every agile method defines named roles.
What to do instead
Remember that Kanban is a strategy for managing and improving flow that can overlay any existing process, including creative, administrative, and software work, and that it prescribes no roles. Service delivery roles such as service request manager and service delivery manager are described in Kanban literature as optional accountabilities, not mandatory positions. Reject options that make a tool, role, or team size a precondition.