Kanban Pull Policies: Entry and Exit Criteria per Column

Kanban pull policies define entry and exit criteria for each column, so everyone knows when work may be pulled forward, by whom, and in what order.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Kanban pull policies are the written rules for how work moves across the board. The core of them is a set of kanban entry and exit criteria for each column: what must be true before an item may be pulled into a stage, and what must be true before it counts as finished there. Around those sit a few related kanban workflow rules, such as how the board is replenished, which item to pull first, and how expedited work is handled. Making these rules explicit is one of the six general practices of the Kanban Method, described on the Kanban method page.

Kanban University's guide lists typical policies: replenishing the board (when, how much, by whom), the definition of when an activity is complete and the item may move on, which it calls "pull criteria," WIP limits, policies for different classes of service, and meeting times (Official Guide to The Kanban Method). The Kanban Guide makes "explicit policies about how work items can flow through each state from started to finished" part of the minimum Definition of Workflow (The Kanban Guide). Both treat policies as something the people doing the work agree on and can change.

Kanban column policies solve a familiar problem. When criteria are left unspoken, each person applies their own. One developer considers a feature done when the code is merged, another when it is tested, and the tester discovers the gap. Items bounce back, reviews take longer than they should, and arguments about quality become arguments about people. A short written criterion replaces those debates with a check anyone can apply.

Policies also make the system learnable. A new team member can read how work flows instead of absorbing it over weeks. Kanban University notes that policies are not work instructions that remove judgement; they "enable self-organization" by making the shared rules visible. The aim is a few sharp rules that people actually use.

How It Works

Each column gets two sets of criteria. Exit criteria describe what finished means for the stage, such as "code reviewed by one other developer and tests passing." Entry criteria describe what an item needs before it may start the stage, such as "acceptance criteria written and dependencies confirmed." Often the exit criteria of one column and the entry criteria of the next are the same check seen from two sides, so write them together at each handoff.

Pulling depends on both criteria and capacity. An item may move forward when it meets the exit criteria of its current column, the next column meets its own entry criteria, and the next column is below its WIP limit. The person with capacity in the downstream stage pulls; nobody pushes work into a full column. This is what the Kanban Guide means by starting work only when there is "a clear signal that there is capacity to do so."

Selection rules decide which item to pull when several qualify. Common rules are oldest first, highest class of service first, or fixed-date items by their due date. Kanban University describes four common class-of-service archetypes: expedite, fixed date, intangible and standard, each with its own treatment. Daniel Vacanti's book Actionable Agile Metrics for Predictability treats pull policies in a chapter of their own, as part of its wider discussion of predictability.

Good policies share a few qualities. Kanban University says they should be sparse, simple, well-defined, visible, always applied and readily changeable by those providing the service. Sparse matters most: a column with a long checklist gets skimmed, while two or three clear criteria get checked. Visible means posted on or beside the board, where the pull decision happens.

Policies change as the system changes. Rework, items bouncing between columns, and cards aging in one stage often point at a weak or missing criterion. The team reviews the evidence in its regular cadences and adjusts the wording, then watches whether the problem recurs.

Step-by-Step Guide

Step 1: List the handoffs on your board

Walk the board from left to right and mark every place an item passes from one stage or person to another. Include the move from options into committed work and the final move to delivery. These handoffs are where criteria matter most, because the person upstream and the person downstream may expect different things.

Step 2: Collect the unwritten rules

Ask the people on each side of every handoff what they expect to receive and what they believe they deliver. Note where the answers differ. Look at recent items that bounced back and record why. These disagreements are your first draft of criteria.

Step 3: Write exit criteria for each column

For each column, write two or three checks that mean the work is finished there. Make each one observable, such as "reviewed and approved in the pull request," so anyone can confirm it. Leave out wishes that nobody checks.

Step 4: Write entry criteria for each column

For each column, write what must be true before work may start: information present, dependencies resolved, an owner available. Align entry criteria with the previous column's exit criteria so the handoff is one agreement. Add the capacity check: the column must be below its WIP limit.

Step 5: Add replenishment and selection rules

Decide who may move items from options into committed work, how often and how many. Write the order in which ready items are pulled and how each class of service is treated. Define the expedite path and its limit, so urgent work has a legitimate route.

Step 6: Review the draft with the team

Read the policies aloud with everyone who works the board and test them against a few recent items. Remove criteria nobody would check and sharpen vague ones. Agree that everyone applies the policies as written until the next review.

Step 7: Post the policies where pulls happen

Put a one-line summary at the top of each column and the full text beside the board or in the board tool. Kanban University recommends placing policies in a clearly noticeable area, preferably next to the board. Make sure the version on the board is the only version.

Step 8: Revise from flow data

Track items that were sent back, items that aged in one column, and disputes at the daily meeting. At each review, change the criterion that caused the most trouble and note why. Keep a short change log so the team remembers why each rule exists.

Best Practices

• Keep each column to a few criteria. Kanban University asks for sparse, simple policies, and a long checklist tends to be skimmed.
• Write criteria that can be observed. "Tests pass in the pipeline" can be checked; "code is high quality" invites argument.
• Pair each exit with the next entry. Writing both sides of a handoff together removes the gap where items bounce back.
• Make exceptions part of the policy. The Kanban Guide asks for acceptable exceptions to WIP control to be explicit, and the same applies to skipping a criterion.
• Let the people doing the work own the wording. Policies imposed from outside are followed only while someone is watching.
• Review policies on a regular cadence. The rules should change when the evidence says they are not working.

Common Mistakes

• Writing a process manual: Long documents are not read at the moment of pulling. Keep the board summary to a line per column and link to detail if needed.
• Criteria nobody can verify: Vague criteria such as "ready" or "done properly" restore the ambiguity policies were meant to remove. Rewrite them as checks.
• Skipping the capacity condition: An item that meets every criterion still should not move into a full column. Include the WIP limit in every entry policy.
• Policies that live only in a wiki: If the criteria are not visible at the board, people pull from memory. Post them where the decision happens.
• Never revising the rules: Workflows change, and stale criteria get ignored. Revise policies in your regular reviews using the items that bounced or aged.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Kanban

Related Skills

• Designing Kanban Boards
• Setting WIP Limits
• Running Kanban Cadences
• Measuring Kanban Flow Metrics
• Managing Projects with Kanban
• Comparing Kanban and Scrum
• Choosing Kanban Software

Sources

• The Official Guide to The Kanban Method (PDF)
• The Kanban Guide
• Daniel S. Vacanti: Actionable Agile Metrics for Predictability

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.