A useful Kanban board shows where work starts, what counts as finished and which states remain inside the work-in-progress boundary. The original four-task example below uses a limit of two across Doing and Review. It makes the decision to start the next task checkable.
Define the workflow before moving cards
The Kanban Guide describes work in progress as started but unfinished work, calls for explicit workflow policies and WIP control, and links starting new work to a signal of available capacity. The Kanban Guide, May 2025
For this fictional writing workflow, define:
| State | Meaning | Counts toward WIP? |
|---|---|---|
| Ready | Queued work that has not entered Doing | No |
| Doing | Started work, including blocked work | Yes |
| Review | Started work awaiting a review decision | Yes |
| Done | Finished under this example's completed-review evidence rule | No |
The start boundary is entry into Doing. The finish boundary is entry into Done supported by a completed review record. The declared example limit is Doing + Review ≤ 2.
These are original planning policies, not a supplied team's approved workflow. Actual owners, authority, review evidence, materials, dates and service-level expectation remain unconfirmed. This bounded example does not claim a complete guide-compliant system or forecast completion times.
Read the initial board as a four-item ledger
| Item | Initial state | Blocker or evidence |
|---|---|---|
| T1 | Doing | Blocked: approved illustration missing |
| T2 | Review | Awaiting review decision |
| T3 | Ready | Queued; not started |
| T4 | Done | Fictional completed-review reference D4 supplied |
Initial WIP is T1 + T2 = 2, exactly at the limit. T1's blocked flag does not subtract it from WIP. Review also remains active; moving a card from Doing to Review does not free overall capacity under this policy.
Keep Blocked as a text flag on T1 in Doing, not a fifth column that hides the card outside the count. Record the missing illustration reference, required authority and proposed follow-up separately. Actual people, request routes and resolution are TO CONFIRM.
Explain why T3 cannot start yet
Trying to move T3 from Ready into Doing would raise WIP from two to three. The supported result is a capacity hold: “Cannot start T3: Doing + Review is 2 of limit 2.” T3 stays Ready, and the attempted move can be recorded with its reason.
Focus the next review on the active items: clarify the illustration dependency for T1 or obtain the actual review decision for T2. Do not mark either finished to make the count look better.
Moving T1 back to Ready solely to game the count is outside this declared policy. A genuine return or cancellation exception would need the workflow owner's actual decision, reason and retained history. It is not a fabricated finish and should not erase the started-work record.
Trace a capacity change through evidence
In a separate fictional next-state scenario, suppose completed-review decision D2 is supplied and supports T2 moving to Done. The sequence becomes:
| Scenario step | T1 | T2 | T3 | T4 | WIP |
|---|---|---|---|---|---|
| Initial | Doing, blocked | Review | Ready | Done | 2 |
| D2 supports T2's finish | Doing, blocked | Done, D2 | Ready | Done | 1 |
| Start T3 after capacity review | Doing, blocked | Done, D2 | Doing | Done | 2 |
The count falls because T2 crossed the defined finish boundary with supporting review evidence. It rises when T3 crosses the start boundary. T1 remains blocked and counted throughout.
This is a worked scenario, not an actual task transition. Keep actual D2, reviewer, dates and transition records blank until supplied in a real workflow.
Keep the transition reason beside the board
Use a native policy/task ledger and transition log with item ID, prior state, proposed destination, start/finish rule, evidence reference, WIP before/after, actual owner/date and decision reason. Record held attempts too, without changing the item's state.
The local HTML example provides labeled task and destination controls for reviewing a move. A held start must keep T3 in Ready and explain the capacity limit. A proposed Done move without the required review reference must retain the prior state and count. The example models these decisions locally; it does not update actual task records.
Keep actual forecast and throughput fields unavailable without their required history and time basis. A single snapshot supplies the example WIP count; it does not establish work-item age, cycle time, throughput or a promised completion date.
Copy this prompt for the board specification
Prepare an original US-English Kanban workflow policy, four-task ledger, WIP audit and transition-reason log. Do not implement a live/synchronized board, move actual tasks or claim performance improvement or complete guide compliance.
Columns Ready/Doing/Review/Done. Started on entry to Doing; finished only when completed-review evidence supports Done. Doing+Review counts WIP, declared example limit 2. Actual owners/authority/materials/dates/review records/SLE TO CONFIRM.
Initial T1 Doing blocked by missing approved illustration; T2 Review awaiting decision; T3 Ready; T4 Done with fictional reference D4. WIP 2. Blocked is a text flag in Doing, not a fifth column or subtraction. Attempt to start T3 held by limit, state stays Ready. Moving Doing to Review does not reduce WIP. No moving T1 back Ready to game count; genuine return/cancel exception needs actual owner decision/history, not fabricated finish.
Separate fictional scenario: supplied D2 supports T2 Done -> WIP 1; then T3 starts Doing -> WIP 2. Preserve T1's blocked flag and four item identities. Actual transitions/records remain blank. Log item, prior/proposed state, start/finish rule, evidence, WIP before/after, owner/date and reason, including held attempts.
Later prototype needs explicit policies, real local move effects, keyboard move alternative, text blocker and state/evidence gates. Missing review reference cannot move Done; full WIP cannot start new work. No drag-only behavior, persistence, actual synchronization, SLE or throughput forecast from snapshot. Native workflow/task records authoritative; controls/tests later.
Review the capacity decision beside the policy
The local HTML board puts the four states beside the WIP rule, blocked flag and transition reasons. NOS supports saving and rendering prepared HTML. Keep the maintained workflow policy and actual task records authoritative.
Explore NOS to present the prepared board review. Leave the next start tied to genuine capacity, with blocked work still visible in the count.