CONWIP limits the work authorized inside a defined line, while a part-specific Kanban loop authorizes replenishment of a particular item or container. Both need clear boundaries, units and release rules. Neither policy chooses the right product mix or fixes missing material by itself. This fictional event record compares a whole-line job cap with local replenishment signals, keeping good completions, scrap and unused release capacity separate instead of declaring one method universally better.
Identify what each card or limit authorizes.
Reconcile whole-line WIP through completion and scrap.
Check material and priority before filling a free slot.
Write the boundary and authorization unit
Spearman, Woodruff and Hopp’s original CONWIP paper describes a pull alternative that controls work in process across a line. Kanban can take several forms; the comparison here uses a part-specific replenishment loop, as in Lean Enterprise Institute’s Kanban definition.
Our illustrative CONWIP boundary contains released jobs through all queues, processing and rework until a defined terminal event. The cap is 3 open jobs, not 3 pieces or 3 containers. A local Kanban card in the comparison instead authorizes one defined container of one part. Card counts are not comparable without those units.
Follow the cap through a short event record
At time zero, J1,J2 and J3 are open inside the line, so WIP equals the 3-job cap. J4 and J5 wait outside. At minute 5, J1 finishes good and its release authorization returns. Material-ready J4 is selected and released, bringing WIP back to 3.
At minute 7, J2 is recorded as terminal scrap under this example’s explicit policy. It leaves the open-job count, making WIP 2. J5 still lacks material at minute 8, so no new job is released. A free slot does not justify starting unready work.
3+1−1−1−0 =2 open jobs. The two terminal jobs are not two good completions. Rework still inside the boundary remains open.
| Event | Open jobs after event | Good completions cumulative | Scrapped jobs cumulative |
|---|---|---|---|
| Initial J1,J2,J3 | 3 | 0 | 0 |
| J1 good completion | 2 | 1 | 0 |
| Release J4 | 3 | 1 | 0 |
| J2 terminal scrap | 2 | 1 | 1 |
| J5 not material-ready; no release | 2 | 1 | 1 |
Compare that with a part-specific replenishment signal
A Kanban signal for a depleted A container authorizes A replenishment under its defined loop. It does not automatically authorize B because another product is waiting. A whole-line slot can allow a choice among ready jobs according to a separate approved priority rule.
This flexibility can be useful for a changing mix, but it creates a mix-selection question. Releasing the easiest A job while a promised B order waits may preserve the cap and still miss the customer need. A cap controls one dimension; it does not supply the whole planning policy.
Define rework, splits and terminal events explicitly
If jobs split into several tracking units, decide how the cap counts them. If a scrapped job requires replacement, the replacement needs a new release under the stated rule. Do not return a card twice or count a repaired unit as both an open job and a new release.
The downloadable event record uses indivisible jobs and terminal scrap to make the arithmetic checkable. A real line may need a workload-based cap rather than an equal-job cap when routings and effort vary widely. Little’s Law requires compatible boundaries and comparable steady conditions; this short event log does not estimate average lead time.
- Define what is limited
Choose jobs, containers, pieces or workload and the exact start/end boundary.
- Specify authorization and priority
State how capacity returns and how a ready job is selected.
- Record all boundary events
Reconcile releases, good completion, scrap, rework and cancellation without duplicates.
- Test mix and disruption
Compare customer output, lead time and service under realistic conditions before changing the rule.
Choose a policy with the replenishment conditions
Stable repeat demand and clear local replenishment loops may favor part-specific signals. A variable mix may need another release and priority arrangement. These are design considerations, not a universal ranking from the fictional record.
Use Kanban calculation for sizing a physical replenishment loop and production scheduling for job timing. Adding more cards because one station is waiting can simply move the queue elsewhere.
Test the rule rather than its name
Measure accepted customer output, lead-time distribution, shortages, mix and WIP under comparable conditions. Retain the starting state and disturbances. A simulation comparison also needs validation and enough replications for the decision.
Use the download to state the cap, release rule and terminal events before comparing alternatives. Then check what happens when material is late, a job is scrapped or the product mix changes.
A related example from Abolfazl
Follow a physical box and its replenishment signal in opposite directions.
In English, on founder Abolfazl’s personal blog. This is related reading, not an independent technical source.
Practical checklist
- Define the line and terminal boundary.
- Name the authorization unit.
- State the cap or part-specific card rule.
- Check material and qualification before release.
- Specify mix priority separately.
- Reconcile good output and scrap separately.
- Keep internal rework inside the chosen boundary.
- Compare policies using customer outcomes and validated evidence.
FAQ
FAQ
Sources and further reading
Authoritative references used to research and verify this guide.