Make Policies Explicit: Write Down Your Workflow's Rules

THE MENTAL MODEL: Every team has rules, but they are often unwritten, existing only in people's heads. Making policies explicit is the practice of surfacing these implicit rules, discussing them as a team, and writing them down for everyone to see. This transforms your workflow from a set of individual assumptions into a shared, objective, and improvable system. It's about creating a playbook, not a rulebook.

HOW IT WORKS: The team collaboratively identifies and defines the rules that govern how work moves through their system. These policies are then written down and made visible, often directly on the Kanban board itself. For example, you might add a note to a column on your board stating its "Definition of Done" or its "Pull Criteria". Policies can cover Work In Progress (WIP) limits, what qualifies a task for an "expedite" lane, how to signal a blocked item, or the specific steps required before work can move from development to testing. The key is that the policy is agreed upon and visible to all.

WHEN TO USE IT: This is a foundational practice in Kanban and should be used in any Kanban system. It is especially critical when a team is newly formed, experiencing process friction, or has high turnover, as it makes the "way we work here" clear to everyone. It's also vital for scaling, as it allows different teams to understand each other's processes. If you hear phrases like "I thought we always..." or "Oh, I didn't know that was required," it's a sign you need more explicit policies.

WHEN NOT TO USE IT: While the practice is universal, you should avoid creating policies for the sake of bureaucracy. Don't define complex rules for a process you don't yet understand. Start with a few simple, critical policies and add more as the need arises from real-world situations. The goal is clarity, not constraint. A policy that is never referenced or that hinders more than it helps should be re-evaluated or removed.

ONE CANONICAL EXAMPLE: A software team has a "Ready for QA" column. Frequently, QA engineers pull work only to find it's missing test data or deployment notes, causing delays. The team makes their policies explicit. They add a visible note to the "Ready for QA" column that reads: "PULL CRITERIA: 1. Unit tests pass. 2. A link to test data is in the ticket. 3. Deployment notes are complete." Now, developers know exactly what is required before moving a card, and QA engineers can confidently pull work knowing it is truly ready, reducing rework and frustration.