What this is showing — and why "33% rework" doesn't mean "33% slower"
This is a single-station queueing model with feedback. Items arrive at rate λ, the team works at rate μ, and a fraction d of completed items come back to be reworked.
Arrivals head straight for Production. The balk turnout only sends an item up to the Product Backlog when Production is at capacity — or when the backlog already holds someone (strict FIFO, no line-jumping). The team pulls waiting work into Process at the switch, where two lines merge: items pulled down from the backlog, and defects climbing back up from the Defect Queue for another full pass. The rework policy sets the switch. Because every defect must be served again, rework doesn't add arrivals — it multiplies passes: the team's total service demand is λ / (1 − d) passes per day (new items plus the repeat passes defects buy). Utilization is ρ = demand / μ. As ρ approaches 1, queues grow without bound — the bottleneck collapses.
- λ=9, μ=10, d=0 → ρ = 0.90 (comfortable)
- λ=9, μ=10, d=0.10 → ρ = 1.00 (on the edge)
- λ=9, μ=10, d=0.33 → ρ = 1.34 (system can't keep up — queues grow forever)
Arrival mode: Poisson (the default) makes the daily count random with mean λ: some days 6, some days 13 — like real demand. At high utilization those bursts queue up even with zero defects: variance × utilization = queues, its own lesson. Switch to deterministic for exactly λ items every day — the cleanest way to isolate what rework alone does.
† Sustainable rate = min(λ, μ·(1−d)) — the most the team can ship per day in steady state. If λ is low enough that arrivals are the bottleneck, this equals λ. If rework is eating capacity, it's lower. The drag stat compares actual rolling throughput to this number.
Symbols inside the dots (1…9, 0, A…Z, a…z) are item IDs — lets you track an individual unit of work through the system. A white ring around a dot means it has been reworked at least once.