What does an explicit column policy on a Kanban board pin down?

middleshould knowfreq 46%

answer

Written where the cards are
Entry criteria, not just exit
Short enough to actually read
Checkable yes or no
Blocked carries reason and date

basics

~20 s

An explicit column policy is a short written rule sitting at the column: what makes a card ready to be pulled in, what must be true before it leaves, who may move it, and how a stall gets marked.

solid answer

~40 s

Every team already has rules about how cards move; the only question is whether they are written where the cards are or carried in people's heads. An explicit policy pins down four things: entry - what makes a card ready to be pulled into this column; exit - what must be true before it leaves; who moves it, normally whoever picks it up next; and what happens when it stalls, which means marking the card with the reason and the date, the same day. Two properties make a policy worth writing: it has to be short enough that people actually read it at the column, and checkable, so a reader can say yes or no rather than 'sort of'. Entry criteria are the ones teams skip and the ones that stop cards bouncing backwards.

Every team already has rules about how cards move; the only question is whether they are written where the cards are or carried in people's heads. An explicit policy pins down four things: **entry** - what makes a card ready to be pulled into this column; **exit** - what must be true before it leaves; **who moves it**, normally whoever picks it up next; and **what happens when it stalls**, which means marking the card with the reason and the date, the same day. Two properties make a policy worth writing: it has to be short enough that people actually read it at the column, and checkable, so a reader can say yes or no rather than 'sort of'. Entry criteria are the ones teams skip and the ones that stop cards bouncing backwards.

code

pseudocode · 5 lines

pseudocode

COLUMN  Ready for bench
  ENTRY      the build is flashed onto a rig-compatible image
             and the card links to the steps to run
  PULLED BY  whoever is free at the bench, top card first
  BLOCKED    mark the card with the reason and today's date

go deeper

for a junior

Be ready to say what an explicit policy is: a short written rule about when a card may move, placed at the column so everyone reads the same words. Know that stalled work is marked with a reason and a date.

for a middle

Explain the parts of a policy - entry, exit, who moves the card, what happens when it stalls - and why entry criteria are the ones that stop cards bouncing backwards. Be able to turn a vague team habit into a checkable sentence.

for a senior

Show judgement about credibility. Talk about what a routinely broken rule does to trust in everything else on the board, how you choose between fixing behaviour and rewriting the rule, and why stalled cards stay in the column where the work stopped.

for a principal

Own how rules are made and kept alive across several teams. Be ready to argue that rules a team wrote outlast rules handed down, to resist approval gates dressed up as policy, and to say how you stop written rules drifting into a compliance exercise.

What 'explicit' actually means

A policy on a Kanban board is a short written rule about how cards move, placed where the cards are. Explicit is a physical claim, not a moral one: the rule is visible at the point of use, in a sentence or two, and everyone reading the board reads the same words.

Every team already has these rules. The only question is whether they are written down or carried in heads. Unwritten rules produce three predictable failures: new people learn them by getting them wrong; two long-standing members turn out to have believed different versions; and the rule cannot be argued with, because there is nothing to point at.

The four things a column policy pins down

Entry - what makes a card ready to be pulled into this column. This is the one that gets skipped, and it is the one that stops cards bouncing backwards.
Exit - what has to be true before the card leaves.
Who may move it. Usually whoever picks it up next, which keeps the board a description of reality rather than a queue of requests.
What happens when it cannot proceed - how a stall is marked, and who owns clearing it.

Implicit rule	The same rule written explicitly
It is ready for review when it is basically done	Ready for review: the change builds, the tests covering it pass, and the linked page names what to look at
Somebody will pick it up	Pulled by whoever is free next, top card first
We know what is blocked	Blocked: marked on the card with the reason and the date it started, the same day

Two properties make a policy worth writing. It must be short - a paragraph nobody reads is the same as no policy at all. And it must be checkable: a reader looking at a card should be able to answer yes or no, not 'sort of'.

Blocked work: a fact, not a memory

Marking stalled work is where explicit policy pays for itself fastest.

The mark carries the reason and the date it started, added the day it happens. Without a date, every reader assumes it is recent, and a fortnight goes by.
The card stays in the column where the work stalled. Moving it elsewhere loses the evidence of where blockages cluster, which is the only thing that makes them fixable.
Somebody owns chasing it. A mark with no owner is a complaint rather than a plan.
The team looks at marked cards before anything else, because a stalled card is the cheapest work available: it is already started.

A worked example

A four-person farm-equipment telematics team, working towards a release timed to an annual industry conference, ran a Ready for bench column with no written entry rule. Three of the eight cards that entered it in a fortnight came straight back, because the build had not been flashed onto a rig-compatible image and whoever was at the bench could do nothing with them.

They wrote seventeen words at the column: the image is built and flashed, and the card links to the steps to run. Cards stopped bouncing. Nobody had learned anything new about firmware; a rule that two of the four already carried in their heads simply became something all four could check.

Policies must be revisable, and revised

A policy is a claim about how the team works. When the claim stops being true there are only two honest moves, and doing neither is what destroys a board's credibility.

If the policy is right and the behaviour is wrong, fix the behaviour, and say out loud that this is what is happening.
If the behaviour is right and the policy is stale, change the policy, immediately and visibly.

A rule that is routinely broken and left standing teaches everyone that the words on the board are decorative - and that lesson does not stay confined to the one rule. The board's other statements start being read as approximations too. It is worth asking first why a rule is being routed around: a policy nobody follows is often describing a step that no longer exists.

Anti-patterns

Policies in a document nobody opens. Written is not the same as explicit; it has to be at the column, where the decision is made.
Policies written as aspirations ('we always test thoroughly') rather than as checks a reader can apply to the card in front of them.
A policy per item type per column, until reading the board becomes a research task.
Approval gates dressed as policy - a named person who must bless every move. That is a queue with a person in it, and if it is real it belongs on the board as a queue.
Policies imposed on the team rather than agreed by it. People follow rules they wrote and route around rules handed to them.

## What 'explicit' actually means A policy on a Kanban board is a **short written rule about how cards move**, placed where the cards are. Explicit is a physical claim, not a moral one: the rule is visible at the point of use, in a sentence or two, and everyone reading the board reads the same words. Every team already has these rules. The only question is whether they are written down or carried in heads. Unwritten rules produce three predictable failures: new people learn them by getting them wrong; two long-standing members turn out to have believed different versions; and the rule cannot be argued with, because there is nothing to point at. ## The four things a column policy pins down 1. **Entry - what makes a card ready to be pulled into this column.** This is the one that gets skipped, and it is the one that stops cards bouncing backwards. 2. **Exit - what has to be true before the card leaves.** 3. **Who may move it.** Usually whoever picks it up next, which keeps the board a description of reality rather than a queue of requests. 4. **What happens when it cannot proceed** - how a stall is marked, and who owns clearing it. | Implicit rule | The same rule written explicitly | | --- | --- | | It is ready for review when it is basically done | Ready for review: the change builds, the tests covering it pass, and the linked page names what to look at | | Somebody will pick it up | Pulled by whoever is free next, top card first | | We know what is blocked | Blocked: marked on the card with the reason and the date it started, the same day | Two properties make a policy worth writing. It must be **short** - a paragraph nobody reads is the same as no policy at all. And it must be **checkable**: a reader looking at a card should be able to answer yes or no, not 'sort of'. ## Blocked work: a fact, not a memory Marking stalled work is where explicit policy pays for itself fastest. - The mark carries **the reason and the date it started**, added the day it happens. Without a date, every reader assumes it is recent, and a fortnight goes by. - The card **stays in the column where the work stalled**. Moving it elsewhere loses the evidence of where blockages cluster, which is the only thing that makes them fixable. - **Somebody owns chasing it.** A mark with no owner is a complaint rather than a plan. - The team looks at marked cards **before** anything else, because a stalled card is the cheapest work available: it is already started. ## A worked example A four-person farm-equipment telematics team, working towards a release timed to an annual industry conference, ran a `Ready for bench` column with no written entry rule. Three of the eight cards that entered it in a fortnight came straight back, because the build had not been flashed onto a rig-compatible image and whoever was at the bench could do nothing with them. They wrote seventeen words at the column: the image is built and flashed, and the card links to the steps to run. Cards stopped bouncing. Nobody had learned anything new about firmware; a rule that two of the four already carried in their heads simply became something all four could check. ## Policies must be revisable, and revised A policy is a claim about how the team works. When the claim stops being true there are only two honest moves, and doing neither is what destroys a board's credibility. - If the policy is right and the behaviour is wrong, **fix the behaviour**, and say out loud that this is what is happening. - If the behaviour is right and the policy is stale, **change the policy**, immediately and visibly. A rule that is routinely broken and left standing teaches everyone that the words on the board are decorative - and that lesson does not stay confined to the one rule. The board's other statements start being read as approximations too. It is worth asking first *why* a rule is being routed around: a policy nobody follows is often describing a step that no longer exists. ## Anti-patterns - **Policies in a document nobody opens.** Written is not the same as explicit; it has to be at the column, where the decision is made. - **Policies written as aspirations** ('we always test thoroughly') rather than as checks a reader can apply to the card in front of them. - **A policy per item type per column**, until reading the board becomes a research task. - **Approval gates dressed as policy** - a named person who must bless every move. That is a queue with a person in it, and if it is real it belongs on the board as a queue. - **Policies imposed on the team rather than agreed by it.** People follow rules they wrote and route around rules handed to them.

Where should a column's policy physically live?
At the column, on the board, in a sentence or two. A policy in a searchable document is written but not explicit: nobody consults it at the moment they pull a card, which is the only moment it can change a decision. If it is too long to sit at the column, it is too long for anyone to follow.
A policy has been ignored by the team for a month. What now?
Pick one of two honest moves: fix the behaviour, or change the policy. Leaving a broken rule standing teaches everyone that the words on the board are decorative, and that scepticism spreads to the statements that are true. Ask first why it is being routed around, because a rule nobody follows usually describes a step that no longer exists.
Who should write the policies?
The people who work the columns. Rules handed down get routed around quietly; rules a team wrote get argued about openly, which is what you want. A lead's job is to insist that the rules exist, are visible at the column and are checkable - not to author them and hand them over.

A column policy is the sign on the door rather than the rule in the staff handbook: it works because it is where you need it, at the moment you need it.

saying these in an interview costs you the question

Keeps the rules in people's heads and calls that agreement
Writes policies as aspirations rather than checkable conditions
Stores policies in a document nobody opens at the board
Marks work blocked with no reason or start date
Moves blocked cards out of the column where work stalled
Leaves a routinely broken policy standing on the board

What does an explicit column policy on a Kanban board pin down?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What 'explicit' actually means

The four things a column policy pins down

Blocked work: a fact, not a memory

A worked example

Policies must be revisable, and revised

Anti-patterns

▾common follow-ups3 questions

▾analogy~10 s

▾red flags6 flags

What 'explicit' actually means

The four things a column policy pins down

Blocked work: a fact, not a memory

A worked example

Policies must be revisable, and revised

Anti-patterns

answer

go deeper