What it is and why it matters
Visualizing is the first practice of the Kanban Method because none of the others work without it. You cannot limit WIP in a step that does not appear on the board, or measure the time of an item when nobody knows when it started. The goal of the board is not to look nice or tidy. It is to reflect how work really flows, including the uncomfortable parts: the queues, the rework loops and the stalled items.
A good test is to ask whether an outsider, looking at the board for one minute, can answer three questions: what is in progress, where work is waiting and what is blocked. If they cannot, the board is still a task list with columns.
Key concepts
Work steps and queues
Columns should represent the knowledge discovery activities the item goes through, such as analysis, development and validation, not people or departments. Next to the active steps, draw the queues: places where the item waits while nobody works on it. A common practice is to split a column into “In progress” and “Ready for next step”.
This split looks like a detail, but it changes how the board reads. Picture a data team where the “Validation” column always holds eight items and seems overloaded. Once the queue is separated, it becomes clear that six of those eight are just waiting for the business area to reply. The problem is not validation capacity, it is waiting on a third party. Visible queues are also the basis for calculating flow efficiency.
Commitment point and delivery point
The commitment point is the place on the board where a request stops being an option and becomes a commitment: from there on, the team agrees to deliver and the customer agrees to receive. Before it, the item can be discarded at no significant cost. The delivery point is where the item is considered delivered to the customer, which does not always match “done for the team”.
These two points define the service’s lead time and give meaning to the metrics. If the commitment point is unclear, the team measures times that mix ideas under evaluation with promised work, and any forecast loses value. The commitment point challenge puts you in front of this decision.
Work item types
Different items behave differently. A production defect, a small improvement and a new feature do not have the same size, the same risk or the same customer. Distinguish the types by color, by icon or by swimlane, and measure each type separately when the time difference is large. Work item types describe the nature of the work; classes of service, covered in domain 5, describe how it is treated in relation to the risk of delay.
Blockers
A blocked item is one that nobody can move forward for an identified reason: waiting for access, waiting for a decision, waiting for another team. Mark the blocker on the card itself and record the reason and the start date. After a few weeks, group the reasons. This grouping usually shows that a few causes account for most of the lost time, and that is where experiments are worth running.
Visible policies
Explicit policies are the system’s rules written where everyone can see them: the WIP limit for each step, the criteria for an item to leave “Analysis”, who can pull an urgent item, what to do when an item stays blocked for more than two days. Policies that live in people’s heads lead to repeated arguments; policies on the board can be questioned, tested and changed.
Swimlanes
Horizontal swimlanes separate flows that share the same steps but receive different treatment. The most common uses are a lane for urgent items, or lanes by work item type or by customer. Use them sparingly: each extra lane splits attention and can hide the total WIP.
Discovery and delivery
Many teams visualize only delivery and leave discovery, the part where they decide what is worth doing, in spreadsheets or in someone’s head. Visualizing discovery to the left of the commitment point shows how many options exist, how long they wait and how many are discarded. Discarding options is healthy; discarding work that has already been committed is waste.
Common mistakes
- Columns per person. The board starts measuring individual utilization, not flow.
- Idealized board. Drawing the process that should exist, rather than the current one, hides the problems the team needs to see.
- “Done” column as the delivery point without agreement. If the customer has not received it, the item has not been delivered.
- Blocker without a reason or a date. Without these two pieces of data, the blocker never becomes learning.
If you want to start from a tested structure, adapt one of the Kanban board templates to your real flow.
How this shows up on the exam
You receive a description of a board or a flow and must decide where the commitment point goes, which column should be split into in progress and queue, or which policy would settle a recurring argument. You will also see situations where the board hides a problem, such as items stalled in a waiting column that does not exist, and you must point out the design change that would reveal it.
Frequently asked questions
How many columns should a Kanban board have?
As many as the real knowledge discovery steps in your flow, with the relevant queues between them. For most teams, that is between four and eight columns. More than that may indicate the board is detailing tasks instead of steps.
What is the difference between the commitment point and the start of work?
The commitment point is the moment the team accepts to deliver the item. The start of work is when someone begins working on it. In many systems they coincide, but not always: an item can be committed and wait in a “Ready to start” queue before it is pulled.
Are blocked and waiting the same thing?
No. A waiting item sits in a queue, waiting for the team’s own capacity. A blocked item cannot move forward because of an identified impediment, even if someone is available. Both increase delivery time, but they call for different actions.
Should I visualize discovery work?
Yes, when it consumes significant time and capacity. Visualizing discovery before the commitment point helps control how many options are under evaluation and keeps requests that are still uncertain from entering the delivery flow.
