Making Policies Explicit

In the last unit you ran experiments to improve flow, but the rules those experiments produced lived in people's heads. One person "knew" a card wasn't ready for review; another didn't. That gap is exactly what this unit closes. The Kanban principle here is blunt: a rule that isn't written down isn't a policy, it's a habit, and habits vary by whoever happens to be holding the card.

Making policies explicit means taking the unspoken rules your team already half-follows and posting them where work happens, on the board itself. Your coaching move is small and concrete: when a recurring argument flares up, don't mediate it case by case, capture the resolution as one short line on the column it belongs to. Explicit policies don't add bureaucracy; they move the disagreement out of the rework and onto the board, where anyone can point at it.

• Dan: This card bounced back from review twice this week. Why?
• Nova: Because "ready for review" means something different to each of us. Milo ships it once it compiles; Jessica wants the tests passing first.
• Dan: So nobody's wrong, there just isn't a rule.
• Nova: Right. Let's write one line on the column: enters review only with tests green and a description attached. Now the disagreement is settled once, not every card.
• Dan: And anyone can check it instead of arguing.

Notice the policy doesn't make people agree by force; it turns a repeating argument into a single checkable condition.

The most useful policies sit on column boundaries. A pull criterion is the explicit condition a card must meet before it can be pulled into the next stage. The word "pull" matters: downstream work pulls from upstream when it has capacity, rather than upstream pushing work forward. Without stated criteria, "pull" quietly degrades into "grab whatever looks ready," and half-finished work slips downstream where it costs far more to fix.

Write each transition as a short, checkable line tied to the boundary, an exit condition for the column it leaves and an entry condition for the one it enters. The test of a good pull criterion is simple: two different people reading the same card reach the same answer. Vague ones like "looks good" or "mostly done" fail that test. Concrete ones like "acceptance criteria attached, no open questions, build green" pass it, and that is what stops work from bouncing.

Stakeholders will keep asking "when will this be done?" and you need an honest answer that isn't a guess. A Service Level Expectation (SLE) gives you one. It's a percentile-based statement drawn from your real cycle-time history, for example "85% of standard items finish within nine days of being started." That's an expectation with a confidence level, not a promised date.

Building it is straightforward: pull the cycle times of recently completed items, find the percentile, and state it plainly. When someone presses for a date, answer with the SLE plus where this specific item sits in the queue. Resist the single-date guarantee, because a probabilistic expectation grounded in your own data holds up, and a round number pulled from optimism does not.

Not all work deserves the same rules, which is why Kanban uses classes of service. Standard work is the default, governed by your SLE. Expedite work jumps the queue and may break a WIP limit, reserved for genuine emergencies. Fixed-date work must land by a hard external deadline, so it gets pulled early enough to hit it. Intangible work matters but has no urgency, like technical debt, and fills slack when it appears.

Each class gets its own pull rule and priority, and your essential coaching move is to make the cost of expedite visible: every expedited item pushes standard work back, so cap it at one at a time. Once that trade-off is explicit, "urgent" stops being everyone's default setting.

The thread of this unit: explicit policies convert invisible, person-dependent judgment into shared, checkable rules the board itself enforces. With that in mind, the next step is to sharpen your eye for the boundary that matters most. Before your next standup, read one column boundary aloud and ask the team what exactly must be true to cross it; you'll often find the rule was never actually agreed. Then you'll sort a set of work scenarios against sound versus sloppy pull criteria, training yourself to spot which conditions truly hold the line and which quietly let half-done work through.