Snow-desk operators fear that choosing Kanban means they can never say no to new requests. What should the SM/TC include in the method?
Select an answer to reveal the explanation.
Short Explanation
Kanban is not a snow-desk that swallows every plow request at once. WIP limits and policies are how the team says 'not yet' without chaos. Unlimited intake is how the street disappears under the drift.
Full Explanation
A snow-desk or citizen-request Kanban team needs WIP limits and explicit policies so pull is managed, not an infinite hopper. Kanban is not a desk that swallows every plow request at once. Limits and policies are how the team says "not yet" in a way that protects flow and makes overload visible for residents waiting on service.
An always-open intake column with no limits fails because unlimited intake guarantees overload and invisible queues elsewhere. A promise to start every request the same day it arrives fails because start-rate promises without finish-rate capacity create thrashing. A people-manager override that assigns extra WIP when the mayor calls fails because unmanaged expedites destroy the policy system.
Exam caveat: classes of service may handle true emergencies, but overrides without policy are not Kanban discipline. Operational check: set explicit WIP limits on in-progress states, write pull/entry/exit policies, train the snow-desk team to stop and discuss before breaking limits, and escalate true emergencies through an explicit expedite class rather than silent overload. Citizen snow and service desks earn trust when policies make capacity honest instead of promising infinite starts that never finish.