Kanban — Method, Principles, and WIP Limits

Kanban is a visual workflow management system built for the effective handling of bottlenecks. A quick exam tip worth internalizing up front: although a Kanban board, a task board, and a Scrum board have small practical differences, PMI expects you to treat them as equivalent for exam purposes — all three visualize work moving through a set of states, typically something like To Do, Plan, Develop, Test, Deploy, and Done, with cards color-coded by type (user story, defect, task, feature).

Kanban is built around five principles. The first three are the original core: Visualize the Workflow (make the work and the states it moves through genuinely visible to everyone — not just the tasks, but how they flow), Limit Work In Progress (cap how much the team is actively working on at once, covered in depth below), and Manage Flow (actively watch how smoothly work moves through the system and intervene when it doesn't). Two more were added later: Make Process Policies Explicit (write down the actual rules for how work moves between states — what "done" means for each column, who can pull what, when — instead of leaving them as unwritten team folklore), and Improve Collaboratively (change the process as a team, based on evidence, instead of one person unilaterally deciding what the new process should be).

Kanban's key aspects, taken together: it manages work by balancing demand against capacity, visualizes both the work items and the workflow itself, helps identify things that aren't actually adding value, is based on a pull system rather than a push system, and improves how bottlenecks get handled at the system level rather than team members individually firefighting them.

Kanban's goals follow directly from that: identify potential bottlenecks, fix the bottlenecks once found, control the entire value chain rather than just one stage of it, and practice what's called Management By Sight — answering, at a glance, five questions: What's going on? What needs to be done? What problems exist? What progress is being made? What are the roadblocks?

Limit Work In Progress — deserves its own close look, since it's the principle PMI tests most heavily. Work In Progress is anything that's been picked up from the backlog but hasn't yet reached the Done state — in other words, the number of tasks the team is currently, actively working on. It's a direct indicator of the team's actual capacity to deliver, and it can be set either for the whole workflow or for each individual column separately (for instance, a tighter limit on Test than on Development, if testing is the team's narrower bottleneck).

Setting a sensible WIP limit means asking a few concrete questions: how many people are actually on the team, are they cross-functional enough to pick up different kinds of tasks, and realistically, how many things can the team work on at one time without everything slowing down together? The underlying goal never changes: deliver valuable software to the customer in the shortest possible time — a WIP limit is a means to that end, not a constraint for its own sake.

A quick illustration of why WIP limits need to account for each stage's actual capacity, not just an even split: say four work items need 5, 3, 2, and 4 hours of development time respectively, but only 1.5, 1, 1, and 1.5 hours of testing time. Development can clearly produce work faster than Test can absorb it — if the team lets WIP build up evenly across both stages, work piles up in front of Test regardless of how fast Development runs. A WIP limit tuned to each stage's real throughput, not a single number applied everywhere, is what actually keeps the system moving smoothly instead of just moving the bottleneck around.

The advantages of limiting WIP: it helps the team maintain a steady pace without exceeding its actual work capacity, nobody gets overwhelmed because the team only starts as much work as it can realistically finish, and it enhances productivity by reducing the number of open items competing for attention at once — a smooth workflow that prevents overload, rather than one that looks busy everywhere and finishes nothing. And the limit itself isn't sacred: if the team frequently finds itself hitting a point where the current WIP limit clearly isn't working, that's the signal to review it and adapt, not a reason to quietly ignore it.

Study focus: when a question frames "Kanban board," "task board," and "Scrum board" as if choosing between them matters, remember PMI's own guidance — for this exam, treat them as the same thing, and focus instead on what principle (visualize, limit WIP, manage flow, explicit policies, collaborative improvement) the question is actually testing.