This work, Open Guide to Kanban, is an adaptation of the Kanban Guide (May 2025 version) , which is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). The original guide is © 2019-2025 Orderly Disruption Limited, Daniel S. Vacanti, Inc. Changes were made to the original. Licensed under CC BY-SA 4.0 . Portions highlighted in italic are © 2025 Orderly Disruption Limited, licensed under CC BY-SA 4.0. All other content is from © 2019-2025 Orderly Disruption Limited, Daniel S. Vacanti, Inc., also licensed under CC BY-SA 4.0.

Preface

This document aims to provide open and adaptable guidance for Kanban and Flow, drawing on ideas curated from various communities. It aims to serve as a coherent reference for various communities in addition to their own content. Depending on the context, various approaches can complement Kanban, allowing it to accommodate a range of Value delivery and organizational challenges.

The use of the italics font supports the Creative Commons adaptation notice on the cover page; italics are not for emphasis. The use of a capital letter at the start of a word indicates a convention listed in the appendix of this document, e.g., Value is either a potential or realized benefit for a Stakeholder, including meeting the needs of the customer, the end-user, the decision-maker, the organization, and the environment.

Definition of Kanban in the Context of Knowledge Work

Kanban is a strategy for optimizing the Flow of Value through a system. It is a signaling system to call for Work or inventory. It comprises the following three practices working in tandem:

• Defining and Visualizing a workflow.
• Actively managing Items in a workflow.
• Improving Flow.

In their implementation, these Kanban practices are collectively called a Kanban system. Those who participate in the Value delivery of a Kanban system are called Kanban system members.

Why Use Kanban?

Central to the understanding of Kanban is the concept of Flow. In a Kanban system, Flow is the movement of Value through that Kanban system. As most Kanban workflows exist to optimize Value, the strategy of Kanban is to optimize Value by optimizing Flow, which means striving to find the right balance of effectiveness, efficiency, and predictability:

• An effective workflow is one that delivers what stakeholders desire, when they desire it.
• An efficient workflow allocates available capacity optimally to deliver Value.
• A predictable workflow means being able to reasonably forecast Value delivery within an acceptable degree of uncertainty.

The strategy of a Kanban system is to enable Kanban system members to ask the right questions sooner as part of a continuous improvement effort in pursuit of these goals. Kanban system members should aim for a sustainable balance among these three elements. Kanban is also a way to reduce overburden (excessive workload) and to manage demand so that Work is delivered optimally given the available capacity. It is not perfect, but it should foster constant improvement and an optimized Flow of Value.

Side benefits are happier Kanban system members, higher quality, and the ability to adapt to demand. A good Kanban system is self-regulating, i.e., the Kanban system signals and adjusts to issues without intervention.

Because Kanban can Visualize virtually any workflow, its application is not limited to any specific industry or context. Professional Knowledge Workers in finance, utilities, healthcare, and software (to name a few), have benefited from Kanban practices. Kanban in most contexts where Value is delivered.

Kanban Theory

The Kanban system draws on various approaches and understanding including, but not limited to, systems thinking (5), lean principles (4), queuing theory (batch size (6-7) and queue size (1,13-14)), variation (2,11), and quality control (2,8,10). Continually improving a Kanban system based on these approaches and understanding is one way organizations can attempt to optimize the delivery of Value. Many existing Value-oriented approaches share the ideas upon which Kanban is based. Because of these similarities, Kanban can be used to augment those delivery approaches.

Kanban Practices

Defining and Visualizing the Workflow

Optimizing Flow requires defining what Flow of Value means in a given context, the (ideally) smooth movement and delivery of potential or (ideally) realized benefits for Stakeholders. The explicit shared understanding of Flow among Kanban system members within their context is called a Definition of Workflow. Definition of Workflow is a fundamental concept of Kanban. All other elements of this guide depend heavily on how workflow is defined.

To inform optimal workflow operation and facilitate continuous improvement, at a minimum, Kanban system members must create their Definition of Workflow using all of the following elements:

1. A definition of the individual units of Value that are moving through the workflow, referred to as Work Items (or Items).
2. Depending on the Work Item, for at least one coherent ‘started’ and ‘finished’ point pair:
   • One or more defined states that the Work Items Flow through from ‘started’ to ‘finished.’
   • Work Items between the ‘started’ and ‘finished’ points, even if waiting in a Queue or Buffer, are considered:
     • ‘Started but Not Finished Work’ (SNFW) or
     • Work in Progress/Process (WIP).
   • A definition of how WIP will be controlled from ‘started’ to ‘finished.’
   • A set of Explicit policies about how Work Items can Flow through each state from ‘started’ to ‘finished’ defect-free. For example, Kanban system members might have a policy that is explicit about fixing any known defects in an Item before moving it to the next state, so that no known defect is passed to a subsequent process.
   • A Service Level Expectation (SLE): A forecast of how long it should take a Work Item to Flow from ‘started’ to ‘finished.’ Note that there is no guarantee that what happened in the past will happen in the future.
   • A Visualization of the Service Level Expectation on the Kanban board.

The order in which these elements are implemented is not important as long as they are all implemented. Kanban system members often require additional Definition of Workflow elements, such as values, principles, and working agreements, depending on the circumstances of the Kanban system members. There are resources in the appendix of this guide and elsewhere to help decide on appropriate options.

Kanban system members also often require more than one Definition of Workflow. Those multiple Definitions of Workflow could be for multiple groups of Kanban system members, different levels of the organization, etc. While this guide prescribes no minimum or maximum number of Definitions of Workflow, it encourages establishing a Definition of Workflow wherever the Kanban system members require connecting Flow to Value.

Enabling Flow is the act of fostering a smooth and balanced system to create Value. The Definition of Workflow should ensure that the system is balanced to optimize the Flow of Value. Kanban system members accomplish this by improving how they validate that Value was delivered, and eliminating Work that fails to deliver Value.

The Visualization of one or more Definitions of Workflow is described as a Kanban board. There are no specific guidelines for how a Visualization should look. Consideration should be given to all aspects of a Definition of Workflow (e.g., Work Items, policies) along with any other context-specific factors that may affect how Value Flows.

In a software team, Kanban might Visualize feature development from idea to deployment. In a marketing team, it might track a campaign from design to launch.

Kanban system members are limited only by their imagination regarding how they make Flow visible and how they foster purposeful and intentional interactions with the right people at the right time. It is recommended to Visualize each step in a workflow to prevent waste from remaining hidden.

Actively Managing Items in a Workflow

Items in the workflow must be actively managed. Active management of Items in a workflow can take several forms, including, but not limited to, the following:

• Control ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP).
• Ensure Work Items do not age unnecessarily, using the Service Level Expectation as a reference.
• Resolve impediments that are causing blocked Work or blocked processes.

A common practice is for Kanban system members to review the active Items on a regular basis. This review can occur continuously or at regular intervals. Kanban system members must explicitly control the number of Work Items in a workflow from ‘started’ to ‘finished,’ directly or indirectly. That control can be represented on a Kanban board in any way that Kanban system members deem appropriate.

The use of WIP limits (16) in Kanban for Knowledge Work typically indicates that demand can exceed the team’s capacity, so WIP limits (16) are used to regulate and balance the Flow of Work Items and prevent overload.

In contrast, a Toyota just-in-time (JIT) pull system prevents demand from exceeding supply, as subsequent requests will not be serviced until the previous one has been fulfilled—a self-limiting or self-regulating system designed to synchronize production with actual customer demand and minimize inventory in a stable, predictable manufacturing environment.

Making only what is needed just-in-time is the cornerstone of the Toyota Production System. The Kanban system in the Toyota Production System pulls exactly what is needed when it is needed.

For Knowledge Work, Kanban system members should start Work on (select) an Item only when there is a clear signal that there is capacity to do so. When WIP drops below the control set in the Definition of Workflow, that can be a signal to select new work. Kanban system members should refrain from selecting more Work into a given part of the workflow beyond the relevant WIP control(s) or selecting Work greater than their capacity. When needed, the Work should be split into smaller yet still potentially valuable Items.

There is no requirement to have a repository of Work Items that are not yet Work In Progress/Process, often referred to as a backlog. A backlog is emergent and can include various stages or aspects of Work preparation. If there is one, there is no need for it to be in a list format or sequenced.

Ideally, Work should enter the Kanban system guided by policies rather than being assigned to an individual. In the pursuit of managing idle work, not idle people:

• The Kanban system members should self-organize around the Work and Definition of Workflow.
• Kanban system members should ‘start’ Work when they are ready to work on it, bringing in new Work based on how it is being prioritized.
• Kanban system members––and others outside the Kanban system––should explicitly prevent Work from being pushed to Kanban system members.
• Beware of re-prioritization of ‘Started but Not Finished Work’ (SNFW) or
  Work In Progress/Process (WIP), as it causes those Items to age (sit idle)
  and leads to longer or less predictable Elapsed Times from ‘Started’ to ‘Finished.’

Rightsizing, an optional but recommended practice, refers to assessing whether Work Items fit the Service Level Expectation, or are too big for the Service Level Expectation and therefore require splitting into smaller but still potentially valuable Work Items.

Rightsizing, in a Knowledge Work context, is based on the assumption that Work Items need to be at or under a maximum size (according to the Kanban system members) but do not necessarily need to be the same size. If a Work Item is so large that it can’t be completed within a reasonable time (e.g., it would break the Service Level Expectation), even after starting it, Kanban system members should consider splitting it into smaller Items that each have the potential to deliver Value. Equally, Work Items can be merged.

Capacity management often requires more than WIP control. Controlling WIP helps Flow and often improves the collective focus, commitment, and collaboration of the Kanban system members. Any acceptable exceptions to controlling WIP should be explicitly stated as part of the Definition of Workflow.

Improving Flow

Given an explicit Definition of Workflow, it is the Kanban system members’ responsibility to continuously improve their Flow by achieving a better balance of effectiveness, efficiency, and predictability. Continual study of the system can guide potential improvements. Kanban system members often review the Definition of Workflow to discuss and adopt needed changes.

Improvements are often just-in-time. Improvements are not limited by their size or scope. Sometimes, improvement is beyond the control or influence of Kanban system members. Purposeful and intentional interactions, cultivating change, and removing Blockers at all levels are key to improvement.

Better still, people who demonstrate leadership, also known as leaders, Go See, Listen, and really understand to collect the facts to inform decision-making. This is known as Genchi Genbutsu. Leaders do Genchi Genbutsu so often that the truth emerges. Knowledge of what to do is one thing, but purposeful, relentless, iterative, compassionate action toward improvement (incl. shorter feedback loops) is another.

Kanban favors evolutionary change, but it does not prohibit larger, structural changes, informed by evidence and a clear understanding of the system. Changes should be purposeful and context-driven.

Inform Flow Optimization with Appropriate Measures or Metrics

• Blocked Elapsed Time for Finished Items (BETFI): The cumulative time for a single ‘finished’ Work Item (or a selection of ‘finished’ Items) spends in a blocked condition from ‘started’ to ‘finished,’ but not in a Queue or Buffer state. [measure for a single Item, metric for multiple Items]

• Cumulative Queueing or Buffer Time (CQBT): The cumulative time a ‘finished’ single Work Item (or a selection of ‘finished’ Items) spends in Queueing or Buffer states from ‘started’ to ‘finished.’ [measure for a single Work Item, metric for multiple Work Items]
• Elapsed Time from ‘Started’ to ‘Finished’ (ETSF): The (typically rounded-up) number of elapsed time units (often calendar days) from when a single Work Item ‘started’ to when a Work Item ‘finished.’ Only ‘finished’ Items get ETSFs. [measure]
• Flow Distribution: The Visualization and analysis of Work Item types ‘finished’ or ‘completed’ over time, enabling active management to ensure a healthy balance of effort. [metric]

• Flow Efficiency: The ratio of active working time to the total time an Item or a selection of Items spends in the workflow, including waiting times, between the ‘started’ and ‘finished’ points on a Definition of Workflow. It is expressed as a percentage. It can be misleading, as time spent in active states may not be actual active time. ((ETSF-(CQBT+other non-value-adding time))/ETSF) 100. [metric] Example of other non-value-adding time: Blocked Elapsed Time for Finished Items
• Number of Blockers: The number of impediments, partial or complete, at a given point in time (usually current datetime), to the Flow of Work Items from ‘started’ to ‘finished.’ [measure]
• Process Cycle Efficiency: Measures the Work efficiency of a system or its parts. It is calculated by dividing Value-adding time by Time to Market and then multiplying by 100 to get a percentage. This means Kanban system members have to measure all Value-adding and all non-Value-adding time (including, but not limited to, waiting time). ((T2M-(CQBT+other non-value-adding time))/T2M) 100. [metric]
• Service Level Expectation: A forecast of how long it should take a Work Item to Flow from ‘started’ to ‘finished.’ The Service Level Expectation itself has two parts: a period of elapsed time and a probability associated with that period (e.g., ‘85% of Work Items will be ‘finished’ in eight days or less’). It is based on a selection of Elapsed Time from ‘Started’ to ‘Finished’ from all history, a subset of history, or if data does not exist or is insufficient, an educated guess. [metric]
• ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP) or Flow Load: The number of Work Items ‘started’ but not ‘finished’. [measure]
• Throughput: The number of Work Items ‘finished’ per unit of time. The measurement of throughput is the exact count of Work Items, not revenue. [metric]
• Time to Market, also known as Customer Lead Time: The (typically rounded-up) number of elapsed time units (often calendar days/weeks) from when a Stakeholder’s order for a single Work Item was received to when the Work Item was delivered to the Stakeholder. It is one example of an ETSF. [measure for a single Work Item, metric for a product or service]
• Total Work Item Age (TWIA) or Total Elapsed Time for ‘Started’ but Not ‘Finished’ Items (TETSNFI) : The total elapsed time from when all in-progress (‘started’ but not ‘finished’) Work Items ‘started’ to a specified datetime, usually the current datetime. [metric]
• Work Item Age (WIA) or Elapsed Time for ‘Started’ but Not ‘Finished’ Items(ETSNFI) : The (typically rounded-up) number of elapsed time units (often calendar days) from the datetime a single ‘not finished’ Work Item ‘started’ to a specified datetime, usually the current datetime. By acting on relatively older Items, feedback loops can be shortened, and Flow improves. [measure]

The Flow metrics and measures apply to the appropriate ‘started’ and ‘finished’ points established by the Kanban system members in their Definition of Workflow. If there are multiple sets of ‘started’ and ‘finished’ points, some flow metrics and measures are often applied to each ‘started’ and ‘finished’ pair.

If Kanban system members are unsure where to start, this guide suggests:

Time to Market, and for each coherent ‘started’ and ‘finished’ pair:

• A Service Level Expectation (required for at least one ‘started’ and ‘finished’ pair),
• Work Item Age or Elapsed Time for ‘Started’ but Not ‘Finished’ Items (ETSNFI),
• Elapsed Time from ‘Started’ to ‘Finished’ (ETSF), and
• Throughput.

Provided that Kanban system members use Flow metrics and measures as described in this guide, and they are appropriate for the context, they can refer to any of them by other names. It is up to the Kanban system members to decide how best to use these Flow metrics and measures, such as Visualizing them in charts or assessing variation. A proactive focus on outcomes, impact, and Value is recommended.

Outcomes, Impact, and Value

Kanban system members should regularly look for evidence of outcomes/impact, e.g.:

• Customer outcomes could focus on delivering measurable Value to customers, e.g., reduced Failure Demand, customer long-term cost reduction, or addressed customer jobs (18).
• User outcomes could address specific changes in user behavior that solve problems or improve experiences, e.g., ‘completing’ Work Items more effectively at the lowest costs, or better usability.
• Product Stakeholder outcomes could connect these behavioral changes to product performance metrics, such as trends in product customer adoption, retention, and convergence, as well as trends in feature adoption, decision-maker and user metrics, and product Time to Market.
• Business Stakeholder Impact, e.g., compliance, business long-term cost reduction, business results, trends in market share, customer satisfaction across all products, etc.
• Outcomes for Kanban system members such as improved capability, considering for example, psychological flow (15), frequency of release, tooling, skills, technical debt, user experience (UX) debt, customer experience (CX) debt, human-centered-design debt, technical domain capability, market domain capability, business domain capability, and a climate/culture for net improvement.

Any of the above approaches can be useful. Also, consider the following:

• Failure Demand (17): Demand caused by a failure to do something or do something right for the customer. It is a signal for potential improvement. It highlights where capacity is being wasted due to previous failures, poor Work, or bad decisions. For example, a customer support team may receive repeated calls due to unclear billing instructions. [metric]
• Time to Validated Value, also known as Time to Value or Time to Outcome: The rounded-up number of elapsed time units (often calendar days/weeks) from when a Stakeholder’s order for a Work Item was received to when Value was validated. It is one example of an ETSF focusing on valuable and measurable outcomes. [measure]
• Value Validated: A Work Item that reaches the ‘finished’ point and delivers the intended Value to the Stakeholder (including, but not limited to, customer or user), meeting explicit policies, e.g., quality or experience standards. Often includes evidence and observations.
• Value Invalidated: A Work Item that reaches the ‘finished’ point or is evaluated but fails to deliver the intended Value, not meeting expectations defined in the Definition of Workflow, often requiring rework or rejection, informed by evidence and observations. Consider the context.

By measuring these kinds of outcomes, impacts, Value metrics, and Value measures, Kanban system members ensure they’re not just delivering Work quickly (outputs), but delivering real Value and improvements (outcomes and impacts) to Stakeholders, including but not limited to customers and users.

Clarity and understanding of Work Items should happen just-in-time to avoid waste. Avoid excessive focus on outputs and insufficient focus on outcomes. Kanban system members should proactively, intentionally, purposefully, and regularly review the metrics or measures and continually improve them.

Endnote

Only the Kanban Practices, the minimum criteria Definition of Workflow, and a selection of metrics or measures are mandatory; everything else is optional. Consider the context. Kanban system members should foster the humane Flow of Value.

Feedback from results (‘result feedback’) refers to the data that comes back after changes are made, whether it’s quantitative or qualitative information about outcomes, impacts, or even shifts in the market environment. This feedback can influence Stakeholder Value outcomes, as well as the inputs, effort, resources, or costs involved going forward. (Note: People are not ‘resources.’).

In practice, Kanban is a journey of ongoing learning and adaptation. By starting with these core practices and continuously improving, Kanban system members can sustainably achieve better Flow of Value. Kanban system members should start simple and evolve their Kanban system as they learn.

History of Kanban

The present state of Kanban can be traced to the Toyota Production System (and its antecedents) and the work of people such as Taiichi Ohno (9). The collective set of practices for Knowledge Work, now commonly referred to as Kanban (12), mainly originated on a team at Corbis in 2006. Those practices quickly spread to encompass a large and diverse international community that has continued to enhance and evolve the approach.

Acknowledgments

People acknowledged here do not necessarily agree with what is written in this document, and that is ok. Nevertheless, the Open Guide to Kanban owes a massive debt of gratitude to:

• All who helped to develop Kanban, including those who preferred not to be named
• Kanban Guide July 2020 or December 2020 version reviewers: Jean-Paul Bayley, Jose Casal, Colleen Johnson, Todd Miller, Eric Naiburg, Steve Porter, Ryan Ripley, Dave West, Julia Wester, Yuval Yeret, and Deborah Zanke
• Kanban Guide May 2025 version reviewers: Magdalena Firlit, Tom Gilb, Colleen Johnson, Christian Neverdal, Prateek Singh, Steve Tendon, and Julia Wester
• Open Guide to Kanban reviewers: Jim Benson, Andy Carmichael, Jose Casal, Magdalena Firlit, Michael Forni, Martin Hinshelwood, Christian Neverdal, Nader Talai, Steve Tendon, and Nigel Thurlow
• Influences: Russell L. Ackoff, Jim Benson, Andy Carmichael, Emily Coleman, John Cutler, W. Edwards Deming, Dominica DeGrandis, Tom Gilb, Joseph M. Juran, Siegfried Kaltenecker, Henrik Kniberg, Klaus Leopold, John Little, Troy Magennis, Taiichi Ohno, Donald G. Reinersten, Sam L. Savage, Walter Shewhart, Nader Talai, Steve Tendon, Nigel Thurlow, and Donald J. Wheeler.

Appendix

Controlling Work In Progress/Process = Controlling ‘Started but not Finished Work’

Control of ‘Started but not Finished Work’, also referred to as WIP control, can be represented on a Kanban board in any way that Kanban system members deem appropriate, including, but not limited to, painter’s tape spots, Total Work Item Age or Total Elapsed Time for ‘Started’ but Not Finished Items (TETSNFI), queue controls, WIP control numbers, or WIP control ranges.

There are also some optional non-Kanban options, supported by some communities, such as CONWIP(16), Simplified DBR (16), or DBR(16):

• CONWIP (Constant Work In Progress/Process) (16): CONWIP is a pull system that maintains a fixed total ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP) limit across the entire workflow, ‘starting’ new Work only when a ‘finished’ or ‘completed’ Item exits, regulating Flow with a single system-wide constraint. Example: A software support team allows only 15 open tickets at any time; when a ticket is resolved, a new one can be ‘started.’ Not everyone supports it.
• DBR (3,16): An advanced approach that manages the Flow Constraint with Buffers before the Flow Constraint and at system outputs, maximizing Throughput while protecting against variability in complex systems. Example: In a product development group, UX review (primary Flow Constraint) sets the pace (drum) with a Buffer of designs before it, a secondary Buffer before legal approval prevents overload, and new Work is released only when both Buffers have capacity. Not everyone supports it.
• Flow Constraint (16): The bottleneck with the least capacity in the Definition of Workflow. There can be multiple bottlenecks (all with less capacity than what is required by the demand), and the Flow Constraint is the most limited one. It restricts the Kanban system’s overall Throughput, determining the pace at which Value is delivered. Example: In a software development team, if the testing takes the longest and limits the release of features, testing is the Flow Constraint that sets the system’s pace. In Knowledge Work, bottlenecks often exhibit turbulent behaviour and can move around the workflow in unpredictable ways. But sometimes bottlenecks are stubborn.
• Simplified DBR (Drum-Buffer-Rope) (3,16): A simplified scheduling method where the Kanban system’s Throughput sets the workflow pace, and Throughput acts as a replenishment signal like in CONWIP. Suppose there is a Kanban system using Simplified Drum-Buffer-Rope, and the Definition of Workflow is designed to handle up to 15 Items, with 12 actively in progress/process (drum) and a Buffer of 3 Items ready to start, ensuring Work continues smoothly if any of the 12 Items face issues by pulling from the Buffer, maintaining Flow with, for example, 13 in progress/process and 2 in reserve. The rope signals replenishment when an Item is delivered, keeping the total within the 15-Item limit, and the system prioritizes rebuilding the Buffer quickly if it is depleted, proactively resolving issues to sustain Flow. Not everyone supports it.

If Kanban system members need to prioritize a Work Item to ‘start’

Here are some optional non-Kanban techniques that some but not all communities support:

• Class of Service (21): An archetype for one or a selection of Work Items, such as, standard, (real and therefore not arbitrary) fixed date, expedite, or intangible. The choice of class of service may reflect perceived relative Value, Risk, or Cost of Delay. It is more useful as an input for deciding which Item(s) to ‘start’ next when capacity allows than reprioritizing Work Items In Progress/Process (which is not good for Flow). Prone to overloading the Kanban system when misapplied, e.g., an ‘expedite lane’ might eventually get superseded by a ‘super-expedite lane,’ and then things start to get silly. Prone to unbalanced Flow even when not misapplied.
• Cost of Delay (per unit of time) (7): The rate of Value loss per unit time for one or more Items, not to be confused with Delay Cost. It is often useful as input for deciding which Item(s) to ‘start’ next when capacity allows, rather than reprioritizing Work Items In Progress/Process (which is not good for Flow). Like most prioritization inputs, it is often based on educated guesses. It can also be real after the fact. For example, the Cost of Delay for a Work Item is $10,000 per week. Kanban system members should tread carefully before considering this approach.
• Data-informed Rightsizing (24-25): Sometimes more effective than other options, as Kanban system members rarely know the effort or Value in advance. It allows for more opportunism.
• Delay Cost (total) (7): The total cumulative loss over a period of time from a specific delay period for one or more Items. It can be actual or forecasted, and it’s important to be clear which one is being referred to. For example, if the Cost of Delay for a Work Item is $10,000 per week and it is delayed by 3 weeks, the Delay Cost is $30,000.
• Impact Estimation Table (IET) (22): Evaluate options against Stakeholder expectations or limits.
• Opportunity Cost: The Value or benefit lost by choosing to work on one or more Work Items over other potentially valuable Work Items due to limited capacity. It reflects the trade-offs made when prioritizing within capacity in a Kanban system, where focusing on one or more Work Items means forgoing others that could have also delivered Value. Kanban system members often use metrics like Cost of Delay or Delay Cost to quantify opportunity cost. Since Value and, hence, Opportunity Cost range from being difficult to predict to being unpredictable, Kanban system members should tread carefully before attempting this approach.
• Random: Can be more effective than other options, as the effort or Value is not known upfront.
• Real Options (23): Defer commitments until sufficient information is available, treating decisions as valuable, expiring options to maximize flexibility and manage Risk.
• Risk: Do the riskiest Item first. Risk can include the likelihood that Value cannot be harvested.
• Shortest Job First (24-25): Select the Work Item with the lowest perceived effort, prioritizing rightsized Work Items over other Work Items. This can lead to shorter feedback loops and quicker outcomes. But, it can also lead to a delayed ‘start’ on a larger, riskier Work Item.
• Slack (19): Slack is leaving unused capacity in the system to cope with demand surges, unplanned work, or the emergence of unseen circumstances. In a Kanban for Knowledge Work context, it is a deliberate allocation or policy of spare capacity or time within the Definition of Workflow to absorb variability, handle unexpected disruptions, or enable continuous improvement without compromising the Kanban system’s Throughput. Example: Kanban system members might maintain a Slack by limiting their ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP) to 80% of capacity, allowing time to address urgent requests or refine processes without delaying planned work. Slack is a key concept in Lean.
• Value divided by Effort: Estimated Value (usually an educated guess) divided by Estimated Effort (usually an educated guess). Actual Effort and Value tend to be random. Kanban system members should tread carefully before considering this approach. Optionally, consider Risk.

Conventions Used in the Context of Knowledge Workd

• Buffer (16): A buffer is a WIP-limited (or ‘Started but Not Finished Work’ limited) area that holds Work temporarily to smooth Flow and prevent overload, and also functions as a WIP controlled queue. Not to be confused with Slack. Not everyone supports Buffer; more columns can lead to a higher amount of ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP).
• Definition of Workflow: The explicit shared understanding of Flow among Kanban system members within their context, including but not limited to, the explicit set of agreements and policies that describe how Work Items are selected, progressed, and ‘finished’ through the workflow’s distinct stages.
• Explicit policy: An explicit policy in a Kanban system is a clearly defined and visible rule or guideline that makes assumptions about workflow—such as when Work Items ‘start’ or move—transparent to Kanban system members. These policies should be Visualized on the Kanban board and be easily accessible, ensuring all Kanban system members understand and follow the same process. By making policies explicit, Kanban system members reduce ambiguity, align actions, and support the optimized Flow of Value.
• ‘Finished’ (or ‘Completed’): When the Elapsed Time from ‘Started’ to ‘Finished’ clock stops for a ‘started’ and ‘finished’ pair in a Definition of Workflow.
• Flow: The (ideally smooth) movement and delivery of Work Items through the Definition of Workflow. A balanced Kanban system sustains Throughput. In an ideal world, Work that entered the system (Knowledge Work), would flow like a river, never stopping, finding the path of least resistance until reaching the customer. Not to be confused with the Definition of Workflow (DoW). In Kanban, Flow > utilization.
• kanban: A kanban​ (signboard in Japanese) is a Visual cue that triggers one to select, ‘start,’ or move a Work Item. Nothing should be produced or moved without a kanban signal.
• Kanban or Kanban system: The holistic set of concepts in this guide. Kanban is rooted in the idea of a signaling system (a way to call for Work or inventory in a production system).
  When this guide says Kanban, assume a Kanban system.
• Kanban Board: A Visual representation of one or more Definitions of Workflow.
• Knowledge Work: The creation, application, or management of information through cognitive processes to solve (often) complex problems, make decisions, or innovate, typically requiring expertise, judgment, and collaboration. Often, Knowledge Work & associated waste are invisible.
• Iterative: Work Items are worked in repeated cycles, with each cycle involving revisiting and refining the same Work based on feedback, testing, or new insights. Kanban is not inherently unsuited to creative iterative work, but it may require thoughtful consideration or adaptation.
• JIT: Toyota Just-in-Time––Producing only what is needed, when it’s needed, in the amount needed to minimize waste and optimize efficiency.
• Measure: A measure is a raw, unit-specific data point representing a single quantity, such as ‘number of Work Items completed this week’ or ‘time to complete a Work Item,’ serving as a foundational input for tracking Flow performance. Example: Kanban system members record a measure of 10 Work Items completed to date.
• Metric: A metric is a quantifiable calculation derived from one or more measures to provide context for workflow performance, such as ‘average Throughput’ or ‘Throughput per week.’ Example: Kanban system members calculate a metric of 4 days average Elapsed Time ‘Started’ to ‘Finished’ by dividing the total time to complete 10 Work Items by the number of Work Items.
• Pull: Work is selected (whether ‘started’ or ‘not started’ on the Definition of Workflow) only when there is capacity, chosen by Kanban system members, and prevents overload, ideally signaled by a customer, directly or indirectly.
• Push: Work is assigned onto Kanban system members or into the Kanban system without considering the current capacity or readiness of Kanban system members to ‘start’ the Work.
• Queue: A queue in Kanban is a waiting area for Work Items, often without strict limits, but it can serve as a Buffer if Work In Progress/Process (WIP) limits (16) or ‘Started but Not Finished Work’ (SNFW) limits are present.
• Risk: The chance that something bad could happen.
• Stable system: Put simply, a system that can consistently meet the demand placed upon it. There are more accurate descriptions (7,8,20). Knowledge Work tends to produce a higher range of Work Item sizes than manufacturing work. Unequal sizes do not necessarily lead to higher variation of elapsed times (due to waiting time often being the most significant factor, etc.) or Throughput but can do so (due to external dependencies, etc.). The view in this guide is that approaches designed for manufacturing do not necessarily lack utility in Knowledge Work.
• Stakeholder: An entity, individual, or group responsible for, interested in, or affected by the inputs, activities, and outcomes of the Kanban system. Includes but is not limited to customer, decision-maker, or user.
• ‘Started’: When elapsed time clocks ‘start’ for a ‘started’ and ‘finished’ pair in a Definition of Workflow.
• ‘started’ and ‘finished’ pair: Each of one or many ‘started’ points on a Definition of Workflow should have a matching ‘finished’ point on the same Definition of Workflow.
• Takt: The word Takt (English ’tact’) is derived from the German word meaning rhythm, cadence, or cycle. Takt is related to keeping time in music. Modern usage of Takt is typically in a manufacturing context. Takt is a foundational measurement in the Toyota Product System and Lean Thinking, used to calculate the capacity required to meet demand in a stable system. Throughput, unlike Takt, which sets the expectation for the ideal pace based on demand, measures actual output per unit of time. Takt also helps achieve a balanced system to meet demand consistently by enabling Kanban system members to determine the capacity needed at each stage of a process. Calculating Takt is challenging in Knowledge Work, as it requires understanding demand in high-variation environments. Not always ideal for Knowledge Work.
• Work: Refers to one or more Work Items, ‘started’, ‘not started’, ‘finished,’ or ‘not finished.’
• Work Item: A Work Item, also referred to as an Item, holds the potential for Value.​ Various terms can be used to describe the different levels of granularity of a Work Item, as long as it has potential for Value. Work Items that do not have potential for Stakeholder Value are potentially wasteful, e.g., people focus on ‘finishing’ subtasks across multiple Work Items rather than focusing on ‘finishing’ one Item at a time. Controlling ‘Started but Not Finished Work’ (SNFW) or Work In Progress/Process (WIP) for potentially wasteful Items often reduces the collaborative effort and focus to deliver potential Value sooner. Consider the context.
• Work Item Type: A categorization for a Work Item. Examples include but are not limited to brands, customers, features, bugs, project work, user experience (UX) research, customer experience (CX) research, human-centered design, operational work, problem statements, hypotheses, other research, and experiments. Useful for sense-making.
• Validated Value: Value confirmed with evidence or observations (ideally both), formally or informally, by Stakeholders; often after one or more rounds of result feedback (and rework), by internal and external Stakeholders. Not everyone supports it.
• Value: Either a potential or realized benefit for a Stakeholder. Examples include meeting the needs of the customer, the end-user, the decision-maker, the organization, and the environment.
• Visualize, visualization: Any method to convey ideas effectively, including conceptual clarification, not necessarily only visual.

References

References are placed here to inform readers of opportunities for further study. They do not necessarily support the text in this guide:

1. _Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383–387. https://doi.org/10.1287/opre.9.3.383 . _
2. Deming, W. E. (1986). Out of the crisis. MIT Press. (Peer-reviewed through its academic adoption in quality management.)
3. Goldratt, E. M. (1990). Theory of Constraints. North River Press. (Peer-reviewed through academic adoption in operations research.)
4. Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. Simon & Schuster.
5. Ackoff, R. L. (1999). Ackoff’s Best: His Classic Writings on Management. NY: John Wiley & Sons.
6. Hopp, W. J. and Spearman, M. L. (2004) ‘To pull or not to pull: what is the question?’, Manufacturing & Service Operations Management, 6(2), pp. 133–148. https://doi.org/10.1287/msom.1030.0028 .
7. Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing
8. Shewhart, W. A. (1931). Economic Control of Quality of Manufactured Product. NY: D. Van Nostrand Company.
9. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
10. Juran, J. M. (1992). Juran on Quality by Design: The New Steps for Planning Quality into Goods and Services. New York: The Free Press.
11. Wheeler, D. J. (1993). Understanding Variation: The Key to Managing Chaos. Knoxville, TN: SPC Press.
12. _Wikipedia (2025) ‘Kanban (development)’. Available at: https://en.wikipedia.org/wiki/Kanban_(development) (Accessed: 22 June 2025)._
13. _Kingman, J. F. C. (1961) ‘The single server queue in heavy traffic’, Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), pp. 902–904. doi: 10.1017/S0305004100035783, and the stable URL is https://www.cambridge.org/core/journals/mathematical-proceedings-of-the-cambridge-philosophical-society/article/single-server-queue-in-heavy-traffic/81C55BC00A68FE6D5385638AA0B0AF37 . _
14. Roser, C. (2018) ‘The Kingman Formula – Variation, Utilization, and Lead Time’, AllAboutLean.com, 2 March. Available at: https://www.allaboutlean.com/kingman-formula/ (Accessed: 22 June 2025)
15. Csíkszentmihályi, M. (1990) Flow: The Psychology of Optimal Experience. NY: Harper & Row
16. Tendon, S. and Müller, W. (2015). Hyper-Productive Knowledge Work Performance: The TameFlow Approach and Its Application to Scrum and Kanban. Plantation, FL: J. Ross Publishing.
17. Seddon, J. (2019). Failure demand | Vanguard. [online] Vanguard-method.net. Available at: https://vanguard-method.net/library/systems-principles/failure-demand/ [Accessed 22 Mar. 2019]
18. Christensen, C.M., Hall, T., Dillon, K. and Duncan, D.S., 2016. Know your customers’ ‘jobs to be done’. Harvard Business Review, 94(9), pp.54-62.
19. DeMarco, T. (2001). Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Broadway Books.
20. Leopold, K. (2017) Little’s law and system stability – an interview with Daniel Vacanti. Leanability. Available at: https://www.leanability.com/en/blog/2017/08/littles-law-and-system-stability [Accessed 28 June 2025].
21. Kanban University (2021) The Official Guide to The Kanban Method [Online]. Available at: https://kanban.university/new-to-kanban-get-the-official-guide-to-the-kanban-method/ (Accessed: 29 June 2025).
22. Gilb, T. (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford: Elsevier Butterworth-Heinemann. Also available at: https://bit.ly/TomGilbCompEng
23. Maassen, O., Matts, C. and Geary, C. (2013) Commitment: A novel about managing project risk. The Netherlands: Happy About.
24. Vacanti, D. S. (2015) Actionable Agile Metrics for Predictability: An Introduction. United States: ActionableAgile Press.
25. Vacanti, D. S. (2023) Actionable Agile Metrics for Predictability Volume II: Advanced Topics. United States: ActionableAgile Press.