Separate requests, commitments and work in progress. A visible limit supports entry decisions; scheduling still requires checking actual dependencies and capacity.
Define what counts as open work
Choose a unit recognizable at its start and finish: a catalogue review, a session with its deliverable or a design ready for approval. If one card represents a three-month project and another a brief correction, card counts alone do not describe workload. Record approximate size or split outcomes when useful.
Atlassian describes WIP limits as restrictions on the amount of work in progress. That idea provides a reference for this editorial exercise; the appropriate number needs testing in your operation. Team size alone does not establish a universal limit.
Draw states that support decisions
| State | Meaning | Review question |
|---|---|---|
| Requested | No execution commitment yet | Is there enough information to evaluate? |
| Ready to start | Scope and inputs confirmed | Is capacity available to start? |
| In progress | Production or review is underway | What enables completion? |
| Finished | Meets the agreed criterion | Was it delivered and recorded? |
Mark blockers on the card and retain the start of the wait. A deliverable awaiting approval remains open even when it does not occupy every hour. Moving it to an invisible list can hide work that returns when the response arrives.
Try a concrete entry rule
In a fictional example, a studio has two reviews in production and one awaiting information. It chooses to try a limit of three open jobs across production and review. A fourth request arrives. The board does not say “accept and start today”: it prompts a decision to wait, agree another date or finish a delivery first.
Three is an illustrative choice rather than a capacity recommendation. Note what counts toward the limit and who can authorize an exception. If urgent work arrives, record which commitment moves and tell affected people. Do not raise the number merely to make the overload signal disappear.
Inspect waiting before starting more
For each blocker, write what is missing, who can resolve it and which action is within your control. “Customer” is too broad; “approval of the product list sent Monday is missing” supports a concrete conversation. If another person can help, share necessary context through a handoff record.
Distinguish working time from elapsed time. A two-hour task can take several calendar days when external responses are needed. A board displays states; it does not automatically turn a historical average into a promised date. Review the case before confirming another job’s deadline.
Explain capacity without sharing a private board
A fictional response could say: “I can review the materials this week and then confirm a start date. Work starts when scope is agreed and inputs are complete.” Adapt this to your real process. Receiving an enquiry and reserving capacity need different states.
A scope review helps when open work expands. Workday planning helps recognize available hours. Here the decision concerns what enters the system, rather than filling every calendar block.
Review the limit with a case record
During the trial, retain dated entries, completions, blockers and exceptions. Ask what waited and why. Inputs may be missing before starting, units may be too large or a review may have become the bottleneck. Change the rule for an explicit reason.
Starting fewer things is an operational decision, not a guarantee of delivering more. Compare similar situations and record changes in scope or availability. The useful first-review result is an understandable entry rule and a visible list of outstanding commitments.
Follow the evidence.
Sources checked October 19, 2026. Illustrative scenarios and numbers are fictional. The records and exercises are original editorial proposals, without attributed customer results or provider tests. Our editorial standards.
