The open-space trail-counter team asks the coach for the "correct" WIP limit. How should the Scrum Master / Team Coach respond?
Select an answer to reveal the explanation.
Short Explanation
There is no official "speed limit of three" stamped on every city trail. A WIP limit is a tool for a problem—too much started work, long queues, thrash. Ask what hurt they are trying to stop before anyone invents a magic number.
Full Explanation
WIP limits are a team flow practice chosen for a purpose, not a universal constant issued by the Scrum Master / Team Coach. When the open-space trail-counter team asks for the "correct" WIP limit, the coach should ask what problem the limit should solve rather than handing out a magic number. That powerful question ties constraints to overload, blocked counters, late field uploads, or thrashing—so the team owns a limit that serves trail-data flow for parks operations.
Issuing a citywide WIP constant of three fails by concept: one number cannot fit every municipal team's context and capacity. Copying the Release Train Engineer's ART-level WIP unchanged onto the team board fails by concept by confusing train portfolio constraints with team kanban design. Removing WIP limits because high-performing teams never constrain work fails by concept: limiting work in process is a core flow practice, not a sign of low performance.
Exam caveat: SASM and SAFe flow guidance treat WIP limits as experiments tuned to the team's bottlenecks; coaches facilitate choice rather than decree. A starting number is fine once the problem is named—the trail-counter team should still inspect and adapt the limit against field outcomes.
Operational check: ask what flow problem they want the limit to address, facilitate a short experiment with an explicit WIP number and review date, visualize blocked counter uploads, adjust based on throughput and aging work, and confirm the team can explain why their limit exists without citing a coach edict.