The Kanban Guide Explained: Flow, WIP Limits and Flow Metrics

The Kanban Guide is a short reference document that defines Kanban, its practices and four flow metrics. This post explains what the guide says about flow, work in progress (WIP) control and flow metrics, using the official kanbanguides.org site. The version we read is the May 2025 edition, which the guide itself labels "Edition 2025.5" and dates 2025-05-01. If you are comparing Kanban with other approaches, our overview of agile project management gives wider context.

A note on scope: we describe the guide as written and clearly label our own suggestions. Anything marked "Our suggestion" is practical advice, not part of the guide.

What the Kanban Guide is

According to the kanbanguides.org home page, the site is the home of The Kanban Guide and the Open Guide to Kanban. The Kanban Guide is listed as the May 2025 edition by John Coleman and Daniel Vacanti, described as "the essential definition, practices, and flow metrics". The Open Guide to Kanban is a separate publication, listed as a July 2025 edition and described as an expanded adaptation for knowledge work. The site says each publication has its own edition history. In this post we cover only The Kanban Guide.

The guide defines Kanban as "a strategy for optimizing the flow of value through a process". It aims to be a unifying reference offering minimal guidance, and it applies across industries and scales. The site also lists earlier versions (2020.7 and 2020.12) in its version menu, so check which edition a team, book or course is using.

The three practices

The guide describes Kanban as made up of three practices:

• Defining and visualizing a workflow. Members create a Definition of Workflow and make it visible, usually on a Kanban board.
• Actively managing items in a workflow. The guide gives examples such as controlling WIP, making sure work items do not age unnecessarily, and unblocking blocked work.
• Improving the workflow. Members continuously improve their workflow, using the Definition of Workflow as the basis.

The people who take part are called Kanban system members, and the guide also refers to stakeholders, meaning an entity, individual or group responsible for, interested in or affected by the inputs, activities and outcomes.

The Definition of Workflow

The Definition of Workflow is the shared, explicit understanding of how work flows. At a minimum, the guide says it includes:

• Work items: the units of value moving through the workflow.
• Start and finish points: when an item counts as started and when it counts as finished.
• States: the stages between started and finished. Items in those states are work in progress.
• WIP control: how the number of work items in the workflow is controlled.
• Explicit policies: how work items can flow through each state.
• A Service Level Expectation: a forecast of how long a work item should take to flow from started to finished.

The guide says the order in which a team adopts these elements is not important, as long as all of them are adopted. Teams may add other elements, such as values or working agreements.

WIP limits: what the guide actually says

The phrase "WIP limits" is common in Kanban conversations, but the guide itself uses different wording. It says that "Kanban system members must explicitly control the number of work items in a workflow from started to finished." The control can be represented on a board in any way members consider appropriate. The guide adds that, ideally, the system would operate neither above nor below the agreed control, and that any acceptable exceptions to controlling WIP should be made explicit as part of the Definition of Workflow.

The guide also links WIP control to a pull system: members should start work on an item only when there is a clear signal that there is capacity. In other words, new work is pulled in when there is room, rather than pushed in because it has arrived.

Our suggestion: if your team talks about a "WIP limit of five", treat that as one way of expressing the guide's requirement to control WIP, and write down what happens when someone wants to exceed it. The guide asks for exceptions to be explicit, so an undocumented exception is a gap in the Definition of Workflow.

The four flow metrics

The guide lists four flow metrics. The definitions below are as the guide states them.

Two points are worth noticing. First, Work Item Age applies to items still in progress, while Cycle Time applies only once an item is finished. Second, the guide says teams may rename the metrics and add their own context-specific measures, but that in and of themselves the metrics are meaningless unless they can inform one or more of the three Kanban practices.

Service Level Expectation

The Service Level Expectation (SLE) has two parts: a period of elapsed time and a probability for that period. The guide gives this example: "85% of work items will be finished in eight days or less." It should be based on historical cycle time and shown on the Definition of Workflow. The guide accepts a best guess until enough data exists.

The Kanban board

The guide states that the visualization of a Definition of Workflow is a Kanban board, and that the board should make the minimum elements transparent. It gives no specific layout: there are no specific guidelines for how a visualization should look.

An illustrative example

This is an illustrative example with made-up round numbers, not real data. Imagine a small finance operations team handling supplier query tickets. They define a ticket as started when someone picks it up and finished when the supplier has a reply. Their board has three states: Investigating, Awaiting information, and Replying.

• On Monday there are 6 tickets started but not finished, so WIP is 6.
• During the week 10 tickets are finished, so Throughput is 10 per week.
• One ticket was picked up 7 days ago and is still open, so its Work Item Age is 7 days.
• A ticket picked up on a Tuesday and replied to on the following Monday has a Cycle Time of 6 days.

If, over several months, 85% of finished tickets had a Cycle Time of 5 days or less, the team could state an SLE of "85% of tickets will be finished in 5 days or less" and use Work Item Age to spot tickets at risk of breaching it. Those numbers are fictional; the pattern is what matters.

Getting started: our suggestions

• Write the Definition of Workflow first. Agree what "started" and "finished" mean before drawing a board.
• Record start and finish dates for every item. All four metrics can be derived from those two dates and the list of items in progress.
• Review items by age. A short standing conversation about the oldest items in progress tends to surface blockers.
• Use the metrics to improve, not to rank people. The guide ties metrics to the practices, so use them to ask how work flows.

For finance and change teams, our article on agile finance transformation projects looks at how iterative approaches apply to finance work. The Kanban Guide is a reference document rather than a qualification syllabus, so if you are weighing formal credentials, see our guide to project management qualifications in Dublin.

What this guide does not cover

We read The Kanban Guide (2025.5) and the kanbanguides.org home page. This guide does not draw on the Open Guide to Kanban or on Scrum-related Kanban guidance, so it makes no statement about how Kanban is combined with Scrum. Check the current guide for any later editions.

Learnsignal's offices are off Baggot Street in Dublin, and we offer in-person training from there. For current details, see our CPD pages.

Frequently asked questions

Does the Kanban Guide require WIP limits?

The guide does not use the term "WIP limits" in the passages we read. It requires that members explicitly control the number of work items in a workflow from started to finished, and says the control can be represented in any way members deem appropriate.

What are the four Kanban flow metrics?

WIP, Throughput, Work Item Age and Cycle Time. The guide defines each in a single sentence, and says teams may rename them or add context-specific measures.

What is a Service Level Expectation?

It is a forecast of how long a work item should take to flow from started to finished, expressed as a period of elapsed time and a probability. The guide's own example is "85% of work items will be finished in eight days or less."

Does a Kanban board have to look a certain way?

No. The guide says a Kanban board is the visualization of a Definition of Workflow and that there are no specific guidelines for how it should look, provided the minimum elements are transparent.

The Kanban Guide is short enough to read in one sitting. Read the current edition yourself, then agree your own Definition of Workflow.