The Kanban
Playbook

Think of an SLE as a two-part forecast: a range of time and a probability. For example, a team might forecast that 85% of their work items will finish within 10 days or less. That forecast is only useful if your system is behaving consistently. Consistency comes from controlling WIP, finishing work before starting new work, and collecting enough completed data to trust your numbers. This is what Little's Law describes: the relationship between how much work is in progress, how fast work finishes, and how long each item takes. When those three things are in balance, your system is stable and your SLE is reliable.

When teams say certain work just takes longer by nature, that is often a signal worth examining. Long Cycle Times on certain work types can reflect system problems: too much WIP, unresolved blockers, third-party dependencies that have not been challenged, or handoffs that have never been questioned. Adding a separate SLE for that work accepts those conditions rather than improving them. Most teams that create multiple SLEs end up collapsing back to one once they actually stabilize their system. The segmentation was solving the wrong problem.

When you create a separate SLE for each type of work, each type now has to behave like its own stable, balanced system. That means enough completed items of each type to produce reliable data, and consistent flow behavior within each group. Most teams do not have that. Creating different flow rules for different work types is also what leads to Classes of Service, which add policy complexity and tend to hurt overall predictability rather than help it.

Multiple SLEs should only be considered when you are genuinely certain you have done everything possible to improve flow, removed system impediments and dependencies, and the data clearly shows two distinct and stable distributions.

• You can tell a customer with confidence what percentage of work will finish within a given timeframe.
• SLE violations are occasional and expected, not a regular occurrence.
• Your Cycle Time Scatterplot shows a recognizable and stable pattern.
• Cycle Time variability is decreasing over time, not holding steady or growing.
• If you do have multiple SLEs, each one is backed by at least 10 to 20 completed items of that type, and each group shows stable, independent flow behavior.

The team has a single, reliable forecast they can share with customers. Work Item Age stays within expected ranges. Violations became conversation starters, not exceptions to design around. The SLE is a useful tool, not a workaround.

Each metric tells you something different about your system. WIP is how many items are currently active. Work Item Age is how long each of those active items has been in progress. Cycle Time is how long finished items took from start to finish. Throughput is how many items you are completing per unit of time.

WIP and Work Item Age work together to show you the current state of your system. WIP tells you how much is active and is the one metric you can directly control. Controlling WIP is the primary lever for improving Cycle Time and stabilizing Throughput. Work Item Age tells you how long each of those active items has been waiting or in progress. Because it only applies to work still in progress, it tells you which items are at risk before they become problems. It is the only metric that tells you what is happening right now.

Cycle Time and Throughput tell you how the system has been performing. Cycle Time shows you how long finished work actually took. Throughput shows you how consistently work is completing. Without Cycle Time data, you cannot set a meaningful Service Level Expectation (SLE). Without Throughput data, you cannot reliably tell your customer when items could be done or how many items we might get done.

• You can answer immediately: how many items are in progress right now? (WIP)
• You can identify the oldest active item and how long it has been in progress. (Work Item Age)
• You have a scatterplot of completed items with Cycle Times recorded in days.
• You are recording daily Throughput, including zero-completion days.
• When asked for a delivery forecast, you have data to work from instead of a guess.

Early data is imperfect. It is still far more useful than no data. Using historical data when it exists lets you skip the cold-start period and begin improving from week one.

In most systems, demand is greater than available capacity.

Without a clear view of how work flows, it is difficult to see where delays and constraints occur or how to improve them. We often respond by starting more work or adding more processes, which makes the system slower.

Kanban helps you see your system as it actually operates. By visualizing work and using flow metrics, you create a model of how work gets done, where it gets stuck, and how to improve flow.

Every system is different. The type of work, the level of demand, and the available capacity will vary. Because of this, copying practices from another team rarely leads to better outcomes. Kanban provides a way to understand and improve your system based on its own conditions. There are no prescribed solutions, only a clear way to observe, learn, and improve.

• You can see all of the work that is planned, in-progress, and completed.
• Work in Progress (WIP) is limited, and work is moving through the workflow without unnecessary delays.
• You can see where work is slowing down. Aging work items are visible and discussed.
• Work is completing more consistently. Cycle times are becoming more stable.
• You can make data-informed probabilistic forecasts for when work will be done based on actual system performance.

Many Kanban implementations stall not because teams did something wrong, but because leadership did not understand what they agreed to. When leaders treat Kanban as a visualization exercise, teams get better boards but face the same problems as before. Work still piles up. Priorities still shift without warning. People still get pulled in too many directions. Over time, teams stop believing the system can change and morale drops.

Kanban is a strategy for improving how value moves through your organization. It only works when leaders actively manage the demand coming into the system. Teams use their flow data to understand their capacity. Leaders use that same data to throttle how much new work enters. Without that partnership, teams are left managing a system they do not fully control.

Leaders also have to accept a different relationship with forecasting. Kanban uses historical flow data to answer the questions stakeholders actually care about. Instead of "we will deliver this by that date," the answer becomes "there is an 85% chance these 100 work items will be done on or before January 23rd." That shift feels uncertain to leaders used to committed dates. In practice, it builds more stakeholder trust than a promise that was never grounded in data.

• Leaders ask "What does the data tell us?" before making priority decisions.
• WIP limits are treated as system policies, not suggestions. When they are exceeded, it triggers a conversation about trade-offs, not pressure to work faster.
• Forecasts are based on Throughput data, not estimates or story points.
• Leaders use flow metrics to identify where the system needs attention, not to evaluate individual team members.
• When new work is requested, leaders ask what currently in-progress work should be paused or stopped before agreeing to start something new.
• Over time, Cycle Time becomes more stable, Throughput becomes more consistent, and fewer items are aging past their SLE. The system is improving because leadership is engaging with the data.

Throughput became more consistent within two quarters because leadership actively managed demand coming into the system. Monte Carlo forecasts became more reliable as the data stabilized. Expedite requests dropped significantly. Leaders spent less time reacting to escalations and more time addressing system-level conditions.

Putting prescriptive rules around what teams should look like ignores the reality that many different types of groups successfully use Kanban.

Kanban Systems succeed or fail based on how people work together to manage flow. When ownership of flow is unclear, teams tend to optimize individual work, allow work items to age, and unintentionally introduce delays and risk into the system.

• The daily review of flow is a collaborative planning conversation involving all system members.
• Issues with flow are raised by any member of the system, not just a lead or manager.
• Improvements to flow are suggested and tested by all system members.
• People show interest in all the work, not just the items assigned to them.
• Team members regularly offer help, ask for help, and surface blockers.

The Kanban Guide requires you to define a Definition of Workflow (DoW). That definition includes the states work moves through from started to finished. States are containers. Activities are what happen inside them. Work enters a state at a point in time and exits when it is ready to move forward. That is what makes flow visible and measurable.

Understanding the activities your work goes through helps you design states that make sense. It does not mean every activity becomes a column. If you skip this step, you will likely end up with too many states, states that overlap, or states that do not reflect how work actually moves.

A board without well-designed states cannot help you manage flow. Work will pile up in places that do not match what is actually happening. Work Item Age will be hard to interpret. WIP will be difficult to control because the boundaries between states will be unclear to the people doing the work.

• The team can describe the activities that happen at each stage of their work without debate or confusion.
• The exercise surfaces activities that were previously invisible, such as waiting, rework, or informal handoffs.
• You can identify which activities serve a similar purpose and could reasonably be grouped together.
• You have enough shared understanding to make conscious decisions about state design rather than guessing.

The team finishes the exercise with a shared understanding of how work actually moves. They have named the activities, found the groupings, and identified work that was previously invisible. They are ready to design a Workflow grounded in what they observed rather than what seemed logical at first glance.

Your Workflow states are the backbone of your Kanban System. Flow metrics and forecasting all depend on how you define them. Get the states wrong and your board cannot help you identify and address flow issues.

There are two ways to get this wrong, and they hurt in opposite directions.

The first is too broad. When everything sits in one "Doing" bucket, you lose the ability to see where work is encountering issues with flow. Is it stuck early in the journey? Late? Waiting on something? You cannot tell. You might see a work item aging on your board, but you have no context for why. Every conversation has to start with reestablishing where it actually is and what is happening to it.

The second is too many. The most common mistake is listing every activity and turning each one into a column. Designing, coding, reviewing, testing, and deploying all become separate states. This feels thorough. What it actually does is create a waterfall relay race. Work moves from person to person, each waiting for the prior step to finish. Every column boundary is a handoff. Every handoff is a place where work queues invisibly. The board shows everyone busy while cycle time climbs.

Every column you add is an opportunity for more WIP to accumulate. More columns do not mean more visibility.

The goal is not fewer states or more states, and it is not a pretty board. It is the right states with the right visuals to give you a clear picture of your work flowing at a glance.

• Columns are not named after or owned by a role or individual.
• States describe where a work item is in its journey, not the exact activity being done to it.
• Collaboration happens within states. Conversations are about the work, not about which role takes it to the next column.
• Work is pulled into the next state when there is WIP availability, not pushed when someone finishes their activity.

Once the team starts using the board, they notice a consistent pattern of items aging when moving from Developing to Validating. Because the board now shows them where the issue is occurring, they can address it as a system problem rather than chasing it item by item. Conversations about work items become more pointed. The team no longer spends time reestablishing context before they can even ask the right question.

Your board is a model of your system. If active work is hidden, you cannot measure it, manage it, or make decisions based on it.

Invisible work still consumes capacity. When work is off the board, WIP is understated, Cycle Time data is incomplete, and your ability to spot workflow issues is compromised from day one.

The initialization decision also affects your flow metrics going forward. If start dates are unknown for pre-existing items, your Work Item Age data has gaps. If those items complete without accurate aging data, your Cycle Time distribution is unreliable — and so is any forecast you build from it.

Starting with a partial or inaccurate board doesn't just delay feedback. It makes your early data unreliable.

• All active work items appear on the board before any new work is pulled.
• WIP counts match what people are actually working on when you walk the board in a standup or review.
• Team members stop referencing work that "isn't on the board yet."
• Items added at initialization have a recorded start date, or are explicitly flagged as having an unknown start date.
• Aging items surface within the first week and trigger a conversation — not a surprise.

The team surfaces a workflow issue in their review stage within the first week. They reduce WIP deliberately rather than by accident. Cycle Time data from day one is marked accurately — known start dates are recorded, unknown ones are flagged — so the team knows exactly how much to trust their early forecasts.

If you put the wrong things on your board, you cannot measure or manage flow accurately. What you visualize determines what you can act on.

Work items need to balance two qualities. Value-focused: each item should deliver something your customer can use or respond to. Without that, you are tracking activity, not value delivery. Your board becomes a task list rather than a system for managing flow. Right-sized: each item should be able to move through your Workflow within your SLE. Size is not about effort or complexity. It is about whether the item can flow through your system without becoming an outlier.

When these qualities are missing, two problems emerge. Work items that are too large stay in progress too long. They accumulate dependencies, delay feedback, and block other work behind them. The longer an item stays active, the higher the probability it will miss its SLE.

Work items that are too small without independent value are just as problematic. A database layer, an API endpoint, or a completed design file may be necessary work, but your customer cannot use them or respond to them on their own. Tracking these as work items artificially deflates your Cycle Time data and makes your SLE an unreliable forecast. When a real work item flows through your system, it looks like an anomaly. You lose the ability to make predictable forecasts.

Both conditions make your system harder to manage and your forecasts harder to trust.

• Work items consistently complete within your SLE.
• Cycle Time variation decreases and fewer items fall outside your expected range.
• Work Item Age stays within expected ranges without frequent escalation.
• Completed items produce a deployable result or a concrete feedback signal.
• Your board reflects work that is actively flowing, not activities that support work.

Work moves through the Workflow consistently. The team releases value after each item, gathers real feedback, and can respond to new priorities without disrupting everything in flight. Cycle Time data reflects actual value delivery and the SLE becomes a reliable forecasting tool.

High WIP is one of the main causes of poor flow.

Teams can look busy all day and still finish very little. When too many items are in progress, attention is split. Work moves in short bursts and then waits while something else is done. That accumulated waiting time, combined with task switching, increases Cycle Time and reduces predictability.

High WIP can also hide problems with flow in the system. It appears that work is moving because lots of items are in progress, but in actuality very little is finishing.

Too little WIP can also create problems. When there isn't enough work in progress, available capacity goes unused and Throughput may decrease. The system becomes uneven, with gaps of inactivity followed by spikes of work. That variability makes flow less stable.

Controlling WIP is about operating at a level where work moves steadily without creating unnecessary delay.

• Cycle Time stabilizes and may begin to decrease.
• Variability in Cycle Time narrows over time.
• Throughput becomes steadier instead of spiking and dropping.
• Fewer items sit idle or blocked for extended periods.
• New work is started based on available capacity rather than urgency alone.
• As performance becomes less volatile, forecasting becomes more reliable because it is based on stable historical data.
• Controlling WIP does not guarantee these outcomes. But without controlling WIP, sustained stability and reliable forecasting are unlikely.

Cycle Time stabilizes around 9 days. Throughput becomes steadier. Forecasting improves. The change was not more effort — it was controlling how much work entered the system.

• Traffic Simulator: Microsimulation of Traffic Flow — shows how excess WIP creates congestion.
• Henrik Kniberg — Multiple WIP vs. One-Piece Flow — demonstrates how limiting WIP reduces completion time and improves flow.
• I Love Lucy — "Job Switching" Clip — a simple illustration of how increasing workload leads to overload and breakdown.

Kanban aims to optimize the flow of value by balancing three factors: effectiveness, efficiency, and predictability. How you structure your WIP control affects all three.

Taking on more work might keep people busy in the short term. But without a deliberate policy, you have no way to see when your system is overloaded, no trigger for a conversation, and no foundation for improvement. These tradeoffs exist whether you manage them or not. A written policy makes them visible and gives your team something to act on.

Different approaches to WIP control create different tradeoffs. Understanding your options helps you choose the right structure for your context and adjust it over time.

• Work moves through your Workflow without long waits between workflow states.
• You can see where work items are stuck and how long they have been there.
• Stuck items get attention quickly rather than aging in place.
• Cycle Time stabilizes and variability narrows over time.
• Throughput becomes steadier rather than spiking and dropping.
• Conversations about flow problems are happening sooner, not after things are already late.

There is no single correct structure for WIP control. Here are the most common approaches and what to watch for with each.

Per-column limits set a maximum number of items allowed in each active workflow state. This is the most visible approach and makes bottlenecks easy to spot. The risk is that teams start gaming the numbers by removing items from columns rather than finishing them, or by raising limits whenever the constraint feels uncomfortable.

Per-person limits cap how many items any one person can have active at a time. This can reduce multitasking. However, it can also reinforce a "my work" mindset where people only pay attention to the items assigned to them. When that happens, work sitting idle in other workflow states gets ignored because it does not feel like their responsibility. Flow across the whole system suffers.

Board-level limits set a ceiling on the total number of items in progress across the entire board. This is simpler to manage but carries its own risk. If items pile up in one workflow state and the board limit is still technically being met, flow can stall in that state while the rest of the board sits empty. The limit stops being a signal and starts being a ceiling that hides the real problem. One way to address this, especially when a team is first working to reduce their overall WIP, is to use both column limits and a board limit at the same time. The column limits keep work distributed across workflow states and promote flow. The board limit keeps the overall volume in check. Together they create more opportunities for the team to have conversations about where work is moving and where it is not.

Portfolio-level limits apply the same logic to higher-level work. You might set a policy that your system will only run one large initiative at a time alongside no more than five smaller ones. This is still WIP control. It operates at a different level of the organization. The same principles from the Kanban Guide apply at every level of work breakdown.

SLE-based pull policies use Work Item Age as the trigger instead of a count. If an item's age approaches the SLE threshold, the team does not start new work. They focus effort on the aging item instead. This connects WIP control directly to customer commitments and predictability.

None of these approaches are mutually exclusive. Many teams use a combination. What matters is that the policy is explicit, written down, and understood by everyone in the system.

Without an SLE, there is no shared definition of what on-time delivery looks like. Work can age indefinitely without triggering any response. You cannot give your customer a data-backed forecast of when something will be done. You cannot identify which active items are at risk.

The SLE gives you all three: a shared forecast, a monitoring threshold, and a daily decision-making tool.

Work Item Age is the metric that makes the SLE actionable. Once you have an SLE, the percentile lines on your Aging WIP chart become intervention triggers. Every time an item crosses a percentile line, its probability of violating the SLE increases. Each line is a signal to have a conversation. Waiting until an item breaches the SLE to act is too late.

Actively managing items against the SLE also reduces variability in your system. A wider spread between your percentile lines means more variability and a less reliable forecast. When you intervene early and prevent unnecessary aging, your Cycle Times become more consistent. That consistency makes your SLE a more accurate and trustworthy forecast over time.

• The SLE is posted on your Kanban board where everyone can see it.
• The team can answer "Is this item at risk?" by looking at the Aging WIP chart, not by asking around.
• Each percentile line crossed triggers a conversation about that item. The conversations get more urgent as the item ages further.
• The spread between your percentile lines narrows over time as you actively manage aging items and reduce unnecessary variability in the system.
• The SLE is revisited when a significant process change occurs, such as adjusting WIP limits, removing a column, or changing a flow policy.

The SLE transforms daily review from a status report into an active flow management conversation. The board tells the team where to focus. Customers receive honest, data-backed forecasts instead of guesses. Variability decreases because problems are surfaced and resolved before they become violations.

Think about your Kanban board. Your start and finish points are not columns. They are the lines between columns, like a start line and a finish line in a race. When an item crosses your start line, the clock starts. When it crosses your finish line, the clock stops. Everything between those two lines is Work in Progress, and the elapsed time is Cycle Time.

Your SLE is built from that Cycle Time data. It tells customers how long it should take for a single item to flow from started to finished. If your start line sits at ticket creation, your SLE includes all the time an item spends waiting before anyone starts working on it. If your start line sits where someone actually picks the item up, your SLE reflects active delivery time only. Both are valid. They answer different questions. The problem is choosing one without realizing what you are actually measuring, then communicating that SLE to a customer who assumed something different.

Customers think in elapsed calendar time. If you tell a customer their item will be done in 10 days, they expect it in 10 calendar days from today, not 10 days after the team picks it up two weeks from now. Your definitions determine what that clock is measuring. Be intentional about it.

• Every team member answers "when does work start?" the same way, every time.
• Your start and finish lines are visible on the board. Someone new can identify exactly where the clock starts and stops without asking.
• Your SLE language matches what you are measuring. If the start line is at ticket creation, your team knows the SLE includes wait time and communicates that to customers.
• Cycle Time data on your Scatterplot reflects a distribution that matches your team's actual experience of how long delivery takes.

The team has an SLE that reflects what it claims to measure. Customers receive a forecast they can hold the team accountable to. Conversations about slow delivery become conversations about the right thing: where in the system work is actually slowing down.

Large items hide more WIP than your board shows. One item that could have been five smaller ones is still five items worth of work in progress. You just cannot see it. That invisible WIP inflates your actual Cycle Time and shows up as outliers in your data. Customers feel it too. Delivery takes longer than expected, and your Cycle Time data looks unhealthy. You are left trying to explain why things are slow when the real answer is buried inside one oversized item.

Small items create the opposite illusion. Work closes quickly and your Cycle Time looks great. But if nothing on your board delivers something a customer can actually use, feedback never arrives. Customers are still waiting for something of value, even while your metrics suggest the system is healthy. Both situations produce the same outcome: unhappy customers. They just look completely different in your data.

Until your items are right-sized, your SLE is not reliable either. It is calculated from your Cycle Time history. If that history is full of oversized items that dragged on for weeks or tiny tasks that closed in hours, your SLE reflects that noise, not your system's real performance. Right-sizing is what makes your metrics trustworthy.

• Items complete within your SLE more often.
• Fewer items sit on the board for a long time without moving.
• Cycle Time becomes more consistent.
• Completed items deliver something a customer can use or respond to.

A team pulls in a work item: "Build and launch the new customer onboarding experience." Before it starts, someone checks the SLE. Their data shows 85% of items finish in 10 days or less. There is no realistic chance this item finishes in 10 days. The team decides to split it. Here are four ways to find the splits:

The item has four acceptance criteria. Each one can be built, delivered, and tested on its own. Each becomes its own work item. This matters beyond just size. Every acceptance criteria you bundle into a single item adds compounding risk. If each AC has an 80% chance of moving through the system cleanly, a single item with three ACs has only a 51% chance of completing without getting stuck. Splitting by acceptance criteria reduces that risk directly.

Look at the item title. "Build and launch" is two things. Look inside the description too. Words like "and," "or," "when," and "if" are signals. Slashes, commas, and dashes often hide the same problem. "Users can create an account and set notification preferences" is two items.

The item says "build the onboarding experience." What experience? For which users? Getting specific reveals what is actually hiding inside. "New user onboarding" could become: first login screen, welcome checklist, email confirmation. Each is concrete. Each can flow on its own.

What is the simplest version that delivers something real? Start there. Can you get users through the front door before you build everything behind it? Deliver the smallest useful thing, learn from it, then build the next piece. You are not reducing scope. You are sequencing it so value flows sooner.

Each resulting item is reviewed against the SLE before it starts. Work flows. The team delivers something useful sooner instead of waiting weeks for one large item to finish.

• American Psychological Association. (2006). Multitasking: Switching costs. American Psychological Association.
• Little, J. D. C. (1961). A proof for the queuing formula L = λW. Operations Research, 9(3), 383–387.
• Vacanti, D. S. (2015). Actionable Agile Metrics for Predictability. ActionableAgile.
• Vacanti, D. S., Singh, P., & Johnson, C. (2022). The Kanban Pocket Guide. Leanpub.
• Vacanti, D. S. (2025). The Kanban Guide. Orderly Disruption Limited. Retrieved from https://www.prokanban.org/the-kanban-guide

Written by Liz Rettig, PKT.

With contributions from: Dan Puckett, PKT  ·  Agnieszka Reginek, PKT  ·  Akos Szilagyi, PKT  ·  José Coignard, PKT  ·  Colleen Johnson, PKT.

PKT = ProKanban.org Kanban Trainer. All contributors are certified practitioners with ProKanban.org.