Make Policies Explicit
Originally published April 2025
One of the most powerful yet often overlooked Kanban practices is “Make Policies Explicit.” This principle is about surfacing and agreeing on the working rules (i.e. policies) that guide how work flows through your system—rules that are often informal, assumed, or inconsistently applied.
Every team has policies, whether they realize it or not. These are the criteria that determine when work can start, how it's prioritized, what “done” means, and how exceptions are handled. The problem is that when these policies are unwritten, they live only in people’s heads—leading to miscommunication, uneven decisions, and limited ability to improve.
Making policies explicit means writing them down, discussing them openly, and ensuring they’re understood and visible to everyone involved. This might include setting clear definitions of when work is considered "ready" or "done," outlining how work is selected or prioritized, and establishing guidelines for how items move through the workflow. For example, below are the policies a team I was working with created to use so they knew when a work item could be pulled from the “Development” step into their “Test” step.
Is Development Really Done?
– Code is finished and self-checked
– Peer review is complete and feedback handled
– Unit tests are written and passing
– Code is committed to the right branch
Have We Shared What Testers Need?
– Test data is ready
– Instructions or notes are attached
– Deployment details (if needed) are included
Are There Any Critical Bugs?
– No major defects remain
– Minor issues are clearly documented
Did We Double-Check the Acceptance Criteria?
– Every acceptance item is met and marked done
– Nothing is left open or assumed
Another particularly important example of explicit policy is classes of service (COS). These are predefined categories that describe how work items should be treated. Here’s a helpful analogy: think of the different ways the post office can “treat” your package when it’s being shipped (each with a different fee, of course). They can offer to send it overnight delivery, two to three-day delivery, first-class, etc. Selecting overnight delivery will tell the postal system what it needs to do to ensure the package is delivered overnight, vs. one of the other delivery options. How you go about treating work items in your Kanban system is very similar. Typical classes of service in Kanban systems are standard work, fixed-date items, expedited items, or intangible (maintenance or tech debt). Each carries with it its own expectations about urgency, scheduling, and flow rules. By making classes of service explicit, teams can align on how to respond to different types of work, reduce ambiguity, and make prioritization easier and fairer.
When policies are clear and visible, several benefits follow. Teams operate with greater confidence and consistency. Work moves more smoothly because everyone knows what’s expected. Self-organization strengthens, and policies provide a clear starting point for learning and making improvements over time. This isn’t about bureaucracy or rigid control. It’s about clarity. And with clarity, teams can adapt, improve, and deliver value more predictably.
If you’re just starting, begin with the basics: define when a work item is considered ready, what conditions must be met to move it forward between each step of your workflow, and how exceptions like expedited items are handled. Use your Kanban board to visualize these policies, and revisit them regularly.
By making policies explicit—including your classes of service—you build a more resilient, responsive, and thoughtful delivery system.