Creating Explicit Pull Policies and Workflow Rules: How to Use Kanban Effectively
This skill teaches you how to define clear entry and exit criteria for each Kanban column so work flows forward predictably, reducing confusion about when items are ready to move and who is responsible for pulling them.
Define explicit entry and exit criteria for each column on your Kanban board. For every workflow stage, write down what must be true before an item can enter (entry criteria) and what must be finished before it can leave (exit criteria). Post these rules visibly on the board so any team member can decide whether to pull work forward without asking for permission or clarification. Start simple, then refine criteria based on where items stall or get sent back.
Outcome: Your team operates with a written set of pull policies that eliminate ambiguity about when work can move between stages. Items stop getting pulled prematurely, rework drops significantly, and every team member can make autonomous pull decisions without interrupting colleagues or waiting for manager approval.
Prerequisites
- A functioning Kanban board with defined workflow columns (see designing-kanban-boards)
- Basic understanding of WIP limits and why they matter (see setting-wip-limits)
- Familiarity with how work currently moves through your team's process, including common handoff points and blockers
Overview
Pull policies are the operating rules that govern how work moves through a Kanban board. Without them, a board is just a collection of sticky notes. With them, the board becomes a self-regulating system where any team member can look at an item, check it against the criteria, and confidently decide whether to pull it into the next column. The specific problem pull policies solve is ambiguity at handoff points. In most teams, work gets stuck not because people are slow, but because nobody is sure whether something is "ready enough" to move forward. A developer wonders if the design is finalized. A QA engineer wonders if the feature is actually complete or still being tweaked. A product manager wonders if the spec has enough detail to begin development. Each moment of uncertainty creates a micro-delay, and those delays compound across every item on the board.
This skill sits at the heart of the Kanban method, right between designing your board and setting WIP limits. The board gives you the visual structure. WIP limits control how much work is in flight. Pull policies control the quality and readiness of work as it transitions between stages. Together, they create smooth, predictable flow. Without pull policies, WIP limits alone cannot prevent partially done or defective items from clogging downstream stages.
The concrete artifact you produce is a pull policy document: a written set of entry criteria and exit criteria for every column on your board, posted visibly alongside the board itself (whether physical or digital). A good pull policy document is short, specific, and testable. Each criterion should be a yes/no question that anyone on the team can answer without subjective judgment. For example, "Does the user story have acceptance criteria written?" is testable. "Is the story well-defined?" is not. When you finish this skill, you will have a living document that reduces rework, speeds up cycle time, and gives every team member the authority to make pull decisions independently.
How It Works
Pull policies work because they replace implicit, tribal knowledge with explicit, shared agreements. In any workflow, there is a gap between what someone thinks is "done" in their stage and what the next person needs to begin their work. This gap is where rework, miscommunication, and bottlenecks are born. Pull policies close that gap by making both sides agree on a concrete checklist.
The mental model is a series of gates. Each column on your board has a gate at its entrance and a gate at its exit. The exit gate of one column is effectively the entry gate of the next. When you write pull policies, you are defining what it takes to pass through each gate. This is different from a push system, where upstream stages shove work downstream regardless of readiness. In a pull system, the downstream person or team only pulls when they have capacity (governed by WIP limits) and when the item meets the entry criteria (governed by pull policies). This combination of capacity and readiness is what makes Kanban flow smooth.
The criteria themselves measure two things: completeness and quality. Completeness criteria check whether all the required inputs are present. Does the item have a description, acceptance criteria, assets, data, or whatever the next stage needs? Quality criteria check whether those inputs meet a minimum standard. Are the acceptance criteria specific enough to test against? Are the design files in the correct format? Is the code passing automated tests? The balance between these two dimensions matters. Overloading criteria with quality checks slows flow to a crawl and creates a perfectionism bottleneck. Underspecifying quality checks lets defective work through and creates rework downstream.
Pull policies also encode the team's learning over time. When an item gets pulled forward and then bounced back because something was missing, that missing thing becomes a candidate for a new criterion. When a criterion never catches anything, it may be unnecessary overhead and can be removed. This is why pull policies are living documents, not carved in stone. The cadences and feedback loops in Kanban, especially the replenishment meeting and the service delivery review, are natural moments to revisit and refine your policies.
One subtle but powerful effect of pull policies is that they distribute decision-making authority. Without explicit policies, pulling decisions default to the most senior person or the loudest voice. With explicit policies, a junior team member can look at the criteria, confirm they are met, and pull the item forward with full confidence. This reduces management overhead and speeds up the entire system because decisions no longer wait in someone's approval queue.
Step-by-Step
Step 1: Map your current workflow stages
Before writing any policies, document what actually happens at each stage of your workflow. Walk through your Kanban board column by column and write down what work looks like when it enters each stage, what activities happen during that stage, and what the output looks like when it leaves. Interview team members who work in each stage, because their understanding of "done" often differs from each other and from what is written anywhere. Pay close attention to implicit handoffs: moments where work informally moves between people within a single column.
These hidden transitions are often where the biggest ambiguity lives. The output of this step is a simple table with one row per column and three columns: what comes in, what happens, what goes out.
Tip: If your team has been running for more than a few weeks, look at your last 10-15 completed items and trace each one through the board. Note where items got stuck, got sent back, or sat waiting. These friction points reveal exactly where your pull policies need the most precision.
Step 2: Identify handoff points and transition boundaries
Using the workflow map from step 1, mark every point where work changes hands between people, roles, or functional areas. These are your transition boundaries, the places where pull policies will have the most impact. Common examples include the transition from product definition to development, from development to code review, from code review to QA, and from QA to deployment. Also identify any transitions that happen within a single column, such as when a designer hands off to a copywriter within a "Design" column.
Each transition boundary will get its own pair of exit criteria (for the upstream stage) and entry criteria (for the downstream stage). Rank the boundaries by pain level: which transitions cause the most rework, confusion, or delay? Start writing detailed policies for the highest-pain transitions first.
Tip: If two stages are owned by the same person, you still need a pull policy at the boundary. Self-transitions are where people cut corners because they assume they know what is needed. Making the criteria explicit even for solo transitions catches quality issues early.
Step 3: Draft exit criteria for each column
For each column on your board, write a short checklist of things that must be true before an item can leave that column. Each criterion should be phrased as a yes/no question that any team member can answer without ambiguity. Good exit criteria are observable and testable: "All acceptance criteria have passing automated tests" is good, while "Code is high quality" is not actionable. Aim for 3-7 criteria per column.
Fewer than three usually means you are being too vague. More than seven usually means you are trying to enforce perfection and will create a bottleneck. Write the criteria in the order they are typically completed, so the checklist reads as a natural workflow within the column. For the first draft, err on the side of fewer criteria.
You can always add more based on feedback.
Tip: A useful litmus test: if a new team member joined tomorrow, could they read this checklist and know exactly whether an item is ready to leave the column? If the answer is no, the criteria need to be more specific.
Step 4: Draft entry criteria for each column
Entry criteria describe what must be true for an item to be eligible to be pulled into a column. These often mirror the exit criteria of the previous column, but not always. " Entry criteria serve a different purpose than exit criteria. Exit criteria ensure quality of output.
Entry criteria ensure readiness of input. For example, a "Development" column might have entry criteria like: "User story has acceptance criteria written. Design mockups are attached and approved. No open questions flagged in comments.
" Write these as yes/no questions, just like exit criteria. Keep them to 3-5 items per column.
Tip: The entry criterion "WIP limit is not reached" should appear on every column that has a WIP limit. This is the mechanism that connects your pull policies to your WIP limits and prevents the system from being overloaded even when items meet all quality criteria.
Step 5: Validate criteria with the team
Share the draft criteria with every person who works in or between the stages. Do this in a dedicated session, not as an async document review, because the conversation surfaces disagreements that comments cannot. " Expect disagreement, especially between upstream and downstream roles. The developer may think the acceptance criteria are always clear enough, while the QA engineer may have a long list of times they were not.
Resolve each disagreement by looking at data: how often does this specific gap cause rework or delays? If it happens more than once in ten items, it likely warrants a criterion. Document the final agreed criteria and get explicit verbal or written agreement from each team member.
Tip: If the team cannot agree on a criterion, run a two-week experiment. Add the criterion, track whether it catches real issues, and revisit. Data resolves policy debates faster than opinions.
Step 6: Format and post the policies visibly
Write the finalized criteria in a format that is immediately visible to anyone looking at the board. For physical boards, print the criteria on cards and pin them at the top of each column or at the boundary between columns. For digital boards, use the column description field, a pinned card at the top of each column, or a linked document that is one click away. , "Ready for Dev → In Dev"), followed by the checklist.
Avoid long paragraphs. Each criterion should be one line. If your tool supports checklists on cards, consider creating a template card with the criteria as checklist items that gets duplicated for each new work item, so team members physically check off each criterion before pulling.
Tip: Color-code or visually distinguish the policy cards from regular work items. If policies blend into the board, team members will stop noticing them within a week.
Step 7: Run the first pull cycle with the new policies
Before the policies become background noise, run at least one deliberate pull cycle where the team explicitly uses them. At the next standup or replenishment meeting, walk through 2-3 items that are candidates for pulling forward. For each item, read the entry criteria out loud and confirm each one. If an item fails a criterion, do not pull it.
Instead, note what is missing and assign an action to close the gap. This deliberate practice builds the habit and surfaces any criteria that are too strict, too loose, or confusing. It also normalizes the idea that blocking a pull is a feature, not a failure. Track which criteria block pulls and which pass easily.
After the first cycle, you will already see patterns.
Tip: Do not skip this step by assuming the team will "just start using" the policies. Without a deliberate first cycle, adoption is inconsistent and the policies become shelf documents within days.
Step 8: Refine policies based on flow data
After two to four weeks of operating with the new policies, review their effectiveness using your flow metrics. Look for three signals. First, items that pass all criteria but still get sent back. This means a criterion is missing.
Add it. Second, criteria that never block anything. This might mean the team has internalized the practice and the criterion is no longer needed, or it might mean the criterion is too vague to catch real issues. Investigate before removing.
Third, items that sit waiting at a boundary because they cannot pass a criterion. If this happens frequently, the criterion might be too strict, or the upstream process might need improvement. Bring the data to a Kanban cadence meeting and decide as a team which criteria to add, remove, or modify. Update the posted policies immediately after the meeting.
Tip: Track the "bounce-back rate" for each transition: what percentage of items pulled into a column get sent back to the previous column. A healthy system has a bounce-back rate below 10%. If you are above that, your exit criteria for the upstream column are not catching enough issues.
Examples
Example: Small startup product team (5 people)
A five-person startup team builds a B2B SaaS product. The board has four columns: Backlog, In Progress, Review, Done. There is no dedicated QA role. Developers review each other's work. The main pain point is that items move from In Progress to Review without being fully testable, causing long review cycles and frequent bounce-backs.
The team maps their workflow and identifies the In Progress to Review transition as the highest-pain boundary. They interview each developer and find three recurring issues: pull requests submitted without tests, pull requests referencing design specs that have changed, and pull requests with database migrations that have not been tested locally. They draft exit criteria for In Progress: "All new code paths have at least one unit test. PR description links to the current design spec (not a stale version).
" Entry criteria for Review include: "Reviewer has capacity (Review column WIP limit not reached). " They print these on a card pinned above the Review column in their digital tool. In the first week, three PRs are blocked from entering Review. Two are missing tests, one has a failing migration.
8 days. After three weeks, they add a fourth criterion: "No TODO comments remain in changed files," based on a pattern of unfinished work slipping through.
Example: Enterprise product team with cross-functional handoffs
A 20-person enterprise team spans product management, UX design, frontend development, backend development, and QA. Their board has seven columns: Backlog, Refinement, Design, Frontend Dev, Backend Dev, QA, and Done. Items frequently stall at the Design to Dev transition because designers produce mockups that lack interaction specifications, and at the Dev to QA transition because features are deployed to staging without test data.
The team runs a 90-minute workshop with representatives from each function. They focus on the two highest-pain transitions. For Design exit criteria, they agree on: "Mockups include all states (default, hover, active, error, empty, loading). Interaction notes describe what happens on click, hover, and keyboard navigation.
Assets are exported in the correct format and uploaded to the shared library. " For Dev exit criteria (both frontend and backend): "Feature is deployed to staging environment. Test data has been seeded for all acceptance criteria scenarios. Release notes describe how to access and test the feature.
" Entry criteria for QA include: "QA column WIP limit is not reached. " The team posts these in their project management tool's column descriptions and creates a template checklist that is automatically added to every new card. In the first sprint-equivalent period, the Design to Dev bounce-back rate drops from 35% to 8%. The Dev to QA bounce-back rate drops from 25% to 5%.
The QA lead reports saving roughly four hours per week previously spent chasing missing test data.
Example: Content marketing team (B2C)
A content marketing team of eight produces blog posts, social media content, and email campaigns. Their Kanban board has five columns: Ideas, Drafting, Editing, Approval, Published. The biggest problem is that drafts arrive in Editing without source links, proper formatting, or images, forcing editors to send pieces back repeatedly.
The content lead facilitates a 45-minute meeting with two writers, two editors, and the marketing director. They focus on the Drafting to Editing transition. Exit criteria for Drafting: "Post is written in the template format with H2 subheadings every 300 words. All statistics and claims have inline source links.
Featured image and at least two in-body images are selected and placed. Meta title and meta description are filled in. " Entry criteria for Editing: "Editor has capacity (Editing WIP limit of 3 not reached). " They add a self-review checklist as a card template, so writers must check each criterion before moving the card.
In the first two weeks, editors send back zero posts for missing sources (previously 40% of posts were bounced). One writer flags that the "two in-body images" criterion is too strict for short posts under 500 words. 1 days.
Example: DevOps platform team with automated gates
A platform engineering team of 12 manages infrastructure for a large e-commerce company. Their board has columns: Backlog, Design, Implementation, Peer Review, Staging, Production. They want to automate as many pull policy checks as possible to reduce manual overhead and enforce consistency across a team that works across multiple time zones.
The team maps their workflow and identifies that most manual pull decisions happen at three boundaries: Design to Implementation, Peer Review to Staging, and Staging to Production. They draft criteria for each. For Design exit: "Architecture decision record (ADR) is written and linked. Threat model section is completed.
" These remain manual checks. For Peer Review to Staging: "PR has at least two approvals. All CI checks pass (lint, unit tests, integration tests). " These are automated via their CI/CD pipeline.
The card cannot move to Staging until the pipeline status shows green and the review tool shows no open threads. For Staging to Production: "Staging deployment has run for at least 24 hours without alerts. Canary metrics (error rate, latency p99) are within baseline thresholds. " The canary metric check is automated via monitoring tool integration, while the rollback plan is a manual checklist item.
After implementation, the team finds that the 24-hour staging window catches issues that previously reached production. Production incident rate drops by 40% in the first quarter. They also discover that the ADR criterion is rarely blocking because the team has internalized the habit, so they reduce it from a blocking criterion to a recommended practice after six months.
Best Practices
Write every criterion as a binary yes/no question that requires no subjective judgment. "Are all acceptance criteria written as testable statements?" works. "Is the story well-defined?" does not. Subjective criteria lead to inconsistent application, which means some items pass through that should not, and team members lose trust in the system.
Keep the total number of criteria between 3 and 7 per column boundary. Fewer than three usually means the criteria are too vague to catch real issues. More than seven creates a compliance burden that slows the team down and incentivizes people to skip the checklist entirely. If you find yourself writing more than seven, you likely need to split the column into two stages with separate policies.
Include a WIP limit criterion in every column's entry criteria. Pull policies and WIP limits are two sides of the same coin: policies control quality at the gate, while WIP limits control quantity. Without the WIP limit criterion, teams will pull items that meet quality criteria even when the column is already overloaded, defeating the purpose of the limit.
Review and update policies at a regular cadence, ideally every two to four weeks during a service delivery review or retrospective. Policies that never change either mean your process is perfect (unlikely) or that nobody is paying attention to whether the policies actually match reality. Stale policies become decoration.
Make pull policies visible at the point of decision, not buried in a wiki or process document. The moment a team member decides whether to pull an item, the criteria should be in their line of sight. For digital boards, this means the column description or a pinned card. For physical boards, this means a printed card at the top of the column.
If the criteria require navigating away from the board, adoption will drop sharply.
Differentiate between "must have" and "should have" criteria when you have mixed-priority items. Some items, like urgent bug fixes, may legitimately need a faster path with fewer criteria. Define an explicit fast-track policy with a reduced checklist rather than letting people informally skip criteria. This preserves the system's integrity while accommodating real urgency.
Involve both upstream and downstream roles when writing criteria for a transition. The upstream person knows what they can realistically deliver. The downstream person knows what they actually need to start work. Policies written by only one side will either be too loose (upstream bias) or too strict (downstream bias), and the excluded side will resist following them.
Common Mistakes
Writing vague, subjective criteria like 'code is clean' or 'design is approved'
Correction
Vague criteria get interpreted differently by every team member, so they do not actually enforce anything. You will see this when items pass the criteria according to one person but get bounced back by another. The fix is to decompose subjective criteria into observable checks. Replace "code is clean" with specific items: "Code passes linting with zero warnings.
All new functions have unit tests. " Replace "design is approved" with "Design file is marked as final in [tool]. " If you cannot state a criterion as a yes/no question with a single correct answer, it is too vague.
Creating so many criteria that the checklist becomes a bottleneck
Correction
This typically happens when the team tries to prevent every possible defect through the pull policy, turning it into a comprehensive quality gate. The signal is a growing queue of items waiting at column boundaries, not because work is slow, but because checking criteria takes too long. Pull policies should catch the most common and most costly issues, not every possible issue. Limit yourself to 3-7 criteria per transition and rely on other quality practices (code review, testing, pair work) for deeper checks.
If you have more than seven criteria, it usually means your column represents two distinct stages that should be split.
Defining policies once and never updating them
Correction
Teams often invest significant effort in the initial policy creation and then treat the result as permanent. Over months, the actual workflow evolves, new tools are adopted, team composition changes, and the criteria drift out of alignment with reality. The symptom is that team members start routinely ignoring certain criteria or adding informal exceptions that are not documented. Schedule a policy review every two to four weeks as part of your regular Kanban cadences.
Before each review, pull data on bounce-back rates and blocked pulls to identify which criteria are working and which are not.
Treating pull policies as rules imposed by management rather than team agreements
Correction
When policies are handed down from above, team members follow them reluctantly or find workarounds. The symptom is passive compliance: people check the boxes without actually verifying the criteria, or they mark items as meeting criteria when they clearly do not. Pull policies must be co-created by the people who use them. Run a collaborative workshop to draft criteria, resolve disagreements with data, and get explicit agreement from every team member.
When someone on the team proposes a criterion, they own it. When a manager imposes it, nobody does.
Applying the same pull policies to all item types regardless of size or urgency
Correction
A critical production bug and a cosmetic UI tweak should not pass through the same gate with the same checklist. When they do, either urgent items get delayed by unnecessary criteria, or the team learns to skip criteria for urgent items, which then bleeds into skipping criteria for everything. Define two or three item classes (standard, expedite, fixed-date) with tailored pull policies for each. The expedite class should have a shorter, focused checklist that preserves essential quality checks while removing non-critical ones.
Document the conditions under which each class applies so the decision is not arbitrary.
Confusing pull policies with Definition of Done
Correction
A Definition of Done describes what 'done' means for the entire workflow, typically the final column. Pull policies describe what must be true at every transition, not just the final one. Teams that conflate the two end up with exit criteria only on the last column and no policies governing intermediate transitions. This leaves the middle of the board as a free-for-all where items move based on gut feel.
Write separate pull policies for every column boundary. Your Definition of Done can serve as the exit criteria for the final column, but intermediate columns need their own specific criteria.
Other Skills in This Method
Managing Projects with Kanban
How to apply Kanban principles to plan, execute, and deliver projects using pull-based scheduling and continuous delivery instead of fixed sprints.
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Setting and Enforcing Work-in-Progress Limits
How to determine optimal WIP limits for each workflow stage to reduce bottlenecks, improve flow, and prevent team overload.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Measuring Kanban Flow Metrics
How to track and interpret lead time, cycle time, throughput, and cumulative flow diagrams to continuously improve delivery performance.
Comparing Kanban and Scrum for Your Team
How to assess the differences between Kanban's continuous flow and Scrum's sprint-based approach to choose or combine the right method for your context.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.
Frequently Asked Questions
How do I create pull policies when my team has never used them before?
Start with the single transition that causes the most rework or confusion. Map what goes wrong at that boundary by reviewing your last 10-15 completed items and noting where items were bounced back or delayed. Draft 3-5 simple yes/no criteria based on those patterns. Run a team workshop to validate and adjust, then try the criteria for two weeks before expanding to other transitions. Starting small builds the habit without overwhelming the team.
How long should it take to check pull criteria for a single item?
Checking should take under two minutes per item per transition. If it consistently takes longer, your criteria are either too numerous (trim to 3-7), too complex (decompose into simpler checks), or require information that is hard to find (make it more accessible). The goal is a quick scan, not a deep audit. Deep quality checks should happen during the work itself, not at the gate.
Should I create pull policies before or after setting WIP limits?
Ideally, set [WIP limits](/skills/setting-wip-limits) first because they create the capacity constraint that makes pull policies meaningful. Without WIP limits, teams can pull unlimited items regardless of criteria, which undermines the system. However, if your biggest pain point is quality at handoffs rather than overload, starting with pull policies is reasonable. Just plan to add the WIP limit criterion ("column WIP limit not reached") to your entry criteria soon after.
How do I handle items that meet most criteria but fail one non-critical criterion?
Define which criteria are blocking (must pass) and which are advisory (should pass). Blocking criteria represent things that will definitely cause rework or failure downstream. Advisory criteria represent best practices that improve quality but are not strictly necessary. If you find the team routinely waiving the same criterion, it is either too strict and should be relaxed, or it points to a systemic upstream problem that needs fixing.
Can pull policies work with automated tools and CI/CD pipelines?
Yes, and automation is the strongest way to enforce them consistently. Any criterion that can be expressed as a programmatic check (tests passing, linting clean, required fields filled, approvals obtained) should be automated so the card literally cannot move until the check passes. Reserve manual criteria for subjective or context-dependent checks that require human judgment. Most teams find that 30-50% of their criteria can be automated.
Why does my team keep skipping pull policy criteria?
Three common causes. First, the criteria are not visible at the point of decision, so people forget they exist. Post them directly on the board. Second, the criteria feel like bureaucratic overhead because they were imposed rather than co-created. Re-involve the team in drafting them. Third, urgency pressure leads people to skip checks "just this once," which becomes habit. Define an explicit expedite policy with a reduced checklist for genuinely urgent items so the standard criteria remain intact for everything else.
How do pull policies interact with Kanban flow metrics?
Pull policies directly affect your [flow metrics](/skills/measuring-kanban-flow-metrics). Well-defined criteria reduce cycle time by preventing rework loops that inflate time-in-stage. They reduce blocked items by ensuring work entering a column is actually ready to be worked on. They improve throughput predictability because items pass through stages more consistently. Track bounce-back rate (items sent back to the previous column) as a leading indicator of pull policy effectiveness. A dropping bounce-back rate means your criteria are catching issues before they cause downstream delays.