Kanban Method: Kanban Method – Tutorial (about 60 minutes)

The Kanban Method is a way of managing knowledge work by making the work visible, limiting how much is in progress at any one time, and improving the flow of value to customers in small, agreed steps. It is used by software and IT operations teams, but also by marketing, legal, HR, product, finance and support groups, and it scales from a single team to a network of services across a whole company. After this tutorial you will be able to explain why Kanban works, describe its principles and general practices, design a first kanban board with WIP limits and explicit policies, read the basic flow metrics, and recognise the most common ways teams misapply it.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The Kanban Method is not a formal standard, so it has no numbered edition and no ISO or national status. Its owner body is Kanban University (formerly Lean Kanban University), the organisation founded around the work of David J. Anderson. Kanban University publishes The Official Guide to The Kanban Method free of charge at kanban.university; the version distributed as of the verification date carries no edition number (its English PDF was posted in 2023). The method's foundational texts are Anderson's 2010 book Kanban: Successful Evolutionary Change for Your Technology Business and the 2016 booklet Essential Kanban Condensed by Anderson and Andy Carmichael. A separate document with a similar name, The Kanban Guide by John Coleman, Daniel Vacanti and co-authors (current edition 2025.5, May 2025, at kanbanguides.org), gives a different, deliberately minimal definition of Kanban; this tutorial teaches the Kanban University method and points out where the two differ. Verified 2026-10-29.

Who it is for: engineers, operations and support staff, analysts, team leads, product, project and delivery managers, and quality, security or compliance professionals who are new to Kanban or who already use a "Kanban board" and want to understand the method behind it. No previous agile or Lean experience is assumed.

Prerequisites: none. It helps if you have experienced a team that was always busy yet rarely seemed to finish anything, because that is exactly the problem Kanban addresses.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain the origins of Kanban in the Toyota Production System and why Anderson adapted it for knowledge work.
You will be able to describe the change management principles, the service delivery principles and the six general practices of the Kanban Method.
You will be able to define the core vocabulary: kanban system, work item, WIP limit, pull, commitment and delivery points, class of service, lead time and delivery rate.
You will be able to design a first kanban system using the STATIK approach, including board columns, WIP limits, explicit policies and cadences.
You will be able to interpret basic flow metrics, apply Little's Law and use lead time history to make probabilistic forecasts.
You will be able to distinguish personal Kanban credentials from organisational claims and use the Kanban Maturity Model to plan improvement.
You will be able to relate the Kanban Method to Lean, Scrum, the Vacanti–Coleman Kanban Guide, ITIL and DevOps measurement.

Lesson 1 – Origins, purpose and scope

The problem Kanban addresses

Picture a small IT team that receives requests from five departments. Every request seems urgent, so the team starts each one as soon as it arrives. After a few months, forty items are "in progress", people switch between six tasks a day, nobody can say when anything will be finished, and the department heads escalate to the CIO. Each person is fully busy, yet customers wait longer than ever. This is the everyday face of a push system: work is pushed into the team whenever someone asks, regardless of whether there is capacity to finish it.

Kanban starts from a simple observation. In knowledge work, most of the time an item spends in the system is spent waiting: waiting for a reviewer, for a decision, for a test environment, for someone to come back from another task. Starting more work does not make anything finish sooner; it creates more queues, more context switching and more half-finished items that deliver no value. If you limit the amount of work in progress and only start something new when something else has finished, items move through faster and more predictably. That is the core idea, and almost everything else in the method supports it.

From Toyota to knowledge work

The word kanban is Japanese and is usually translated as "signboard" or "visual card". In the Toyota Production System, developed from the 1940s onwards under Taiichi Ohno, kanban cards signal that a downstream process has used up parts and needs more. A supplier process produces only when it receives such a signal. Because the number of cards in circulation is fixed, the amount of inventory between processes is capped. This is the original pull system: work is drawn in by available capacity rather than pushed in by a schedule.

David J. Anderson adapted these ideas to software and IT work in the mid-2000s. An often-cited early case was a sustaining-engineering team at Microsoft around 2004, where limiting work in progress and pulling new requests only when capacity freed up sharply improved delivery times. A later implementation at Corbis, a digital-image company, in 2006–2007 added the visual board, explicit policies and regular review meetings that people now associate with Kanban. Anderson's 2010 book described the approach as a method for evolutionary change, and a community, conferences and a training organisation grew around it. That organisation is now called Kanban University.

Purpose and scope

Kanban University describes the Kanban Method as a way to define, manage and improve services that deliver knowledge work, meaning work whose main product is information, decisions, designs, software or advice rather than physical goods. Three ideas define its scope:

It is applied on top of whatever process you have today. It does not replace your roles, job titles or lifecycle with new ones on day one; instead it makes the current process visible and then improves it.
It is service-oriented. The unit of analysis is a service that takes requests from customers and delivers something of value back. An organisation is seen as a network of interdependent services.
It is about evolutionary change. Rather than a large, planned transformation, improvement happens through many small, agreed changes, each tested against evidence.

Kanban therefore suits teams with mixed and unpredictable demand, such as operations, support, maintenance, platform engineering, content production or shared services, where fixed-length planning cycles fit poorly. It is equally usable by product development teams, and many teams combine it with other frameworks. What it is not is a project-management standard with a fixed set of phases, nor a prescriptive framework with mandatory roles and meetings.

Two documents called "Kanban guide"

Newcomers often find two official-sounding guides and wonder which is "the" Kanban. Kanban University's Official Guide to The Kanban Method describes the full method taught in this course: principles, general practices, values, cadences and an approach for introducing Kanban. The Kanban Guide from kanbanguides.org, first published in 2020 and updated as edition 2025.5 in May 2025, defines Kanban more narrowly as a strategy for optimising the flow of value through three practices and four flow metrics. The two communities share most core ideas, such as visualising work and controlling work in progress, but they differ in vocabulary and emphasis. Lesson 7 compares them.

Lesson 2 – Key concepts and vocabulary

Kanban uses a small number of terms very precisely. Learning them now will make the later lessons much easier.

Kanban (lower case) – a signal card or visual token that represents a work item and, when capacity is limited, also signals that new work may be pulled.
Kanban system – the combination of a board, cards, WIP limits, explicit policies, metrics and meetings that together manage a service's work. A board alone is not yet a kanban system.
Service – one or more people who take requests from customers and deliver a result, such as "database changes" or "contract review". Kanban looks at work through the lens of services.
Work item – a unit of customer-recognisable work that flows through the system, such as a feature, a change request, an incident or a document. Different work item types can share one board.
Work in progress (WIP) – the number of work items that have been committed to but not yet delivered, either in the whole system or in one part of it, at a given moment.
WIP limit – an explicit upper bound on the number of items allowed in a column, lane, person or the whole system at once. It creates the capacity signal that makes a system pull rather than push.
Pull – the act of taking new work only when there is free capacity, as shown by the system being below its WIP limit. The opposite is push, where work is assigned regardless of capacity.
Commitment point – the place in the workflow where an option becomes a commitment: the service agrees to deliver it and the customer agrees to accept it. Before this point items are just ideas or options that may be discarded.
Delivery point – the place where an item is considered delivered to the customer. The time between the commitment point and the delivery point is what Kanban calls lead time.
Lead time – the elapsed time a single item takes from the commitment point to the delivery point. (The Vacanti–Coleman guide calls the comparable measure cycle time, from its own start point to its finish point.)
Delivery rate – the number of items delivered per unit of time, such as twelve requests per week. Many people call this throughput.
Work item age – how long an unfinished item has been in progress so far. Ageing items are an early warning that something is stuck.
Blocker – anything that prevents an item from progressing, such as a missing decision or an unavailable environment. Blockers are usually marked on the card so that they can be swarmed and analysed later.
Class of service – a policy-defined category that decides how an item is selected and treated in the system, based on its urgency and cost of delay. Classic examples are expedite, fixed date, standard and intangible.
Explicit policy – a written, visible rule about how the system works, for example what "ready for test" means, how WIP limits apply or who may replenish the queue.
Cadence – a regular meeting or review that provides a feedback loop, such as a daily Kanban meeting or a monthly operations review.
Cumulative flow diagram (CFD) – a stacked-area chart that plots, day by day, the count of items sitting in every workflow state. Bands that widen indicate growing queues.
Service level expectation (SLE) – a forecast of how long an item is likely to take, expressed with a probability, such as "85% of standard requests finish within 10 days".

Two further words are worth separating. Kanban with a capital K refers to the method. kanban with a lower-case k refers to the cards or signals inside a system. When people say "we use Kanban" they may mean anything from a sticky-note board to a full system of WIP limits, metrics and reviews; part of your job as a practitioner is to find out which.

Lesson 3 – Structure of the method

The Kanban Method has no clauses or chapters to comply with. Instead it is organised as a small set of principles, a set of general practices that put them into action, and a collection of values, agendas and specific practices that guide how you introduce and deepen it. Figure 1 shows how these parts fit together.

Figure 1 – The building blocks of the Kanban Method: values and agendas, two groups of principles, six general practices that put them into action, and specific practices for applying them.

The change management principles

These three principles explain how Kanban changes an organisation, and they are what most clearly distinguishes it from frameworks that begin with a reorganisation.

Start with what you do now. Respect the current process, roles and responsibilities. Visualise how work really flows today and use that as the starting point, because people resist changes imposed on them but engage with improving something they recognise as their own.
Agree to pursue improvement through evolutionary change. Everyone involved commits to keep improving, but in small steps that can be tried, measured and reversed if they do not help. This keeps risk low and resistance manageable.
Encourage acts of leadership at all levels. Improvement ideas can come from anyone, not just managers. A tester who proposes a new pull criterion or an analyst who points out a recurring blocker is showing leadership.

The service delivery principles

These three principles explain what the system should be optimised for.

Understand and focus on the customer's needs and expectations. Quality, timeliness and predictability are judged from the customer's point of view, not by how busy the service looks.
Manage the work and let people self-organise around it. Managers focus on the flow of work items rather than on keeping individuals busy; people decide among themselves how best to move the work forward.
Regularly review the network of services and its policies. Because services depend on one another, improving one team in isolation can just move the bottleneck. Periodic reviews look across the network to improve outcomes for the end customer.

The six general practices

The general practices turn the principles into action. You do not need all six on day one, and each can be applied at different depths.

Visualize. Make the work, the workflow steps, the queues and the blockers visible, usually on a board with columns and cards. Visualisation turns invisible knowledge work into something a group can discuss.
Limit work in progress. Set WIP limits so that new work is only started when capacity becomes free. This is what turns a visual board into a pull system, and it is the practice that most directly shortens lead times.
Manage flow. Watch how items move, find where they wait or get blocked, and act to keep them moving smoothly. The goal is fast, predictable delivery rather than maximum individual utilisation.
Make policies explicit. Write down the rules of the system, such as entry and exit criteria for each column, WIP limits, how classes of service are handled and when replenishment happens. Explicit rules let people self-organise and make it possible to discuss changing them.
Implement feedback loops. Use regular meetings and reviews, plus the board and metrics, to compare what is happening with what was expected and to decide on adjustments.
Improve collaboratively, evolve experimentally. Use shared models of how work behaves (queues, variability, cost of delay) to propose changes, try them as experiments and keep the ones that the evidence supports.

Values and agendas

Kanban literature, notably Mike Burrows's Kanban from the Inside (2014) and Essential Kanban Condensed, names nine values behind the method: transparency, balance, collaboration, customer focus, flow, leadership, understanding, agreement and respect. They are a reminder that the mechanics only work in a culture where problems can be made visible without blame.

Kanban University also describes three agendas, or reasons an organisation adopts Kanban. The sustainability agenda is about finding a sustainable pace and relieving overburden. The service orientation agenda is about performance and customer satisfaction. The survivability agenda is about staying competitive and adaptable over the long term. Knowing which agenda matters most to leaders helps you decide where to start.

Specific practices

Beyond the general practices, the method offers specific techniques: STATIK (an approach for introducing Kanban, covered in Lesson 4), board design patterns, WIP-limit strategies, classes of service, a set of cadences, and metrics such as lead time distributions and cumulative flow diagrams. Over time Kanban University has also added models for larger organisations, such as Enterprise Services Planning and the Kanban Maturity Model (Lesson 5).

Anatomy of a kanban system

Figure 2 shows a simple kanban system. On a real board the states run left to right; the diagram lists them top to bottom so it is easy to read on a phone. Ideas wait as options until they are pulled past the commitment point; from then on the clock runs until the delivery point.

Figure 2 – A basic kanban system: options are pulled past the commitment point into WIP-limited states and leave at the delivery point; lead time is measured between the two points.

Notice the "waiting for review" column. Many boards show only activities, which hides the queues where items spend most of their time. Showing buffers and waiting states explicitly is one of the most useful things a first board can do.

Lesson 4 – How it works in practice

Introducing Kanban with STATIK

STATIK stands for Systems Thinking Approach To Introducing Kanban. It is a guided sequence of steps, usually run as workshops with the people who do the work and those who request it, that leads to a first kanban system designed for the actual service. The Official Guide presents six steps; longer versions in the Kanban literature add an opening step about understanding what makes the service fit for purpose and a closing step about socialising the design and agreeing how to roll it out. Figure 3 shows the sequence.

Figure 3 – The STATIK sequence: from what frustrates customers and staff, through demand, capability and workflow, to a designed system that keeps evolving.

Identify sources of dissatisfaction. Ask customers what frustrates them about the service (late delivery, unpredictability, quality) and ask staff what frustrates them (overburden, constant interruptions, unclear priorities). These become the problems the system must solve.
Analyze demand. List the types of work that arrive, where they come from, how often, and with what urgency. A service that receives incidents, small changes and large projects needs to treat them differently.
Analyze capability. Look at recent history: how many items of each type were delivered and how long they took. Even rough data shows how predictable the service is today.
Model the workflow. Map the knowledge-discovery steps that work goes through today, including the places where it waits. These become the board's columns.
Identify classes of service. Agree how urgent or date-driven items are treated differently from standard work, and write those policies down.
Design the kanban system. Decide the board layout, WIP limits, commitment and delivery points, replenishment rules, metrics and meetings.

Designing the board

A good first board mirrors reality, not an ideal. Columns come from the workflow you modelled, and each activity column is often split into "in progress" and "done" sub-columns so that items finished in one step but not yet pulled into the next are visible as a queue. Horizontal swimlanes can separate work item types or classes of service. Cards carry a short title, the work item type, the date the item was committed, and markers for blockers. Digital tools are common, but a physical board works perfectly well for a co-located team.

Setting WIP limits

There is no formula that produces the "right" WIP limit. Teams usually start from the current amount of work in progress, then lower it in steps while watching lead time and the number of idle people. A common starting heuristic is a limit close to the number of people who work in a column, sometimes slightly lower to encourage pairing and swarming. Limits can be set per column, per lane, per person or for the whole system (a CONWIP limit). What matters is that the limit is explicit, respected and adjusted based on evidence. When a column is at its limit, people do not start new work there; they help finish or unblock items downstream. This is the source of the Kanban saying "stop starting, start finishing".

Classes of service

Not all work has the same urgency. Anderson's 2010 book describes four widely used classes of service:

Expedite – very urgent items with a high cost of delay, such as a production outage. A policy often allows one expedite item at a time, even above the WIP limit, and people may drop other work to handle it.
Fixed date – items whose value drops sharply after a known date, such as a regulatory deadline. They are started early enough to finish in time.
Standard – the bulk of the work, usually handled in arrival or priority order within the WIP limits.
Intangible – work whose value is real but not urgent today, such as paying down technical debt. It is often given a small share of capacity so it is not forgotten.

Classes of service only help if the policies are explicit and if the expedite lane is genuinely rare. If a third of the work is "expedite", the class has lost its meaning.

Cadences: the feedback loops

Kanban University describes a network of seven cadences that together form the feedback loops of a mature implementation. Figure 4 shows how they relate, from daily coordination to strategy.

Figure 4 – The seven Kanban cadences: strategy and operations reviews steer the network of services, while service-level meetings coordinate daily work and feed data back up.

Kanban Meeting (often daily, about 15 minutes) – the team walks the board, typically from right to left, asking what blocks items closest to delivery and what can be finished today. It is about the flow of work, not a round of individual status reports.
Replenishment Meeting (often weekly) – decides which options are pulled past the commitment point when space frees up.
Delivery Planning Meeting (per delivery) – plans hand-over of finished work to customers.
Service Delivery Review (often every two weeks) – compares the service's performance with customer expectations, using metrics, and agrees improvements.
Operations Review (often monthly) – looks across the network of services for dependencies and shared problems.
Risk Review (often monthly) – examines blockers and risks to delivery, looking for patterns.
Strategy Review (often quarterly) – checks whether the services still match what the market and the business need.

The frequencies are suggestions, not rules. The Official Guide recommends building cadences up gradually and reusing meetings the organisation already holds wherever they serve a similar purpose. A small team may start with only a daily Kanban meeting, a replenishment meeting and a regular review.

Metrics and Little's Law

Kanban measures flow rather than effort. The basic metrics are WIP, lead time, delivery rate and, for unfinished items, age. Several charts help interpret them:

A run chart plots the lead time of each completed item in delivery order, showing trends and outliers.
A lead time distribution (histogram) shows how often items took a given number of days. Improving flow tends to narrow the distribution, which means more predictable delivery, and shift it to the left, which means faster delivery.
A cumulative flow diagram shows the count of items in each state over time. A band that keeps widening reveals a growing queue; flat bands show that nothing is moving.
Flow efficiency compares the time items are actively worked on with their total lead time. In knowledge work it is often surprisingly low, because items spend most of their lives waiting.

These metrics are connected by Little's Law, a result from queueing theory published by John Little in 1961. For a stable system observed over a period, average lead time equals average WIP divided by average delivery rate. If a service has an average of 30 items in progress and delivers 10 per week, the average item takes about 3 weeks. If it halves WIP to 15 while keeping the same delivery rate, average lead time falls to about 1.5 weeks. Little's Law describes averages over time; it is not a tool for forecasting a single item, and it only holds when the system is reasonably stable. But it explains, in one line, why limiting WIP shortens lead times.

Forecasting without estimates

Because Kanban collects lead time data for every item, forecasts can be based on history instead of guesses. A service might observe that 85% of its standard items were delivered within 12 days and use that as its service level expectation. For a batch of items, teams use historical delivery rates, often with a Monte Carlo simulation, to state a range of likely completion dates with probabilities. This is more honest than a single promised date, and it improves automatically as flow becomes more predictable.

Lesson 5 – Assessment, certification and compliance

No organisational certification

Because the Kanban Method is a management method, not a requirements standard, there is no audit that certifies an organisation as "compliant with Kanban", no accreditation body and no certificate an auditor can issue to a company. Customers or regulators who ask whether a supplier "uses Kanban" are asking about practice, not about a formal conformity claim. If a contract or tender asks for it, the honest evidence is the kanban system itself: boards, explicit policies, metrics and records of reviews.

Personal credentials

Kanban University trains and credentials individuals through accredited trainers. As of the verification date its catalogue includes, among others:

Team Kanban Practitioner (TKP) – a one-day entry-level course for team members.
Kanban Management Professional (KMP) – earned by completing Kanban System Design (KSD) and then either Kanban Systems Improvement (KSI) or Kanban for Design and Innovation (KDI).
Kanban Coaching Professional (KCP) – for coaches leading Kanban initiatives; it builds on the KMP, covers the Kanban Maturity Model and coaching, and includes an exam.
Accredited Kanban Trainer (AKT) and Accredited Kanban Consultant (AKC) – for those who teach the courses or lead transformations professionally.

Most Kanban University credentials are awarded for completing training rather than for passing an exam. Other bodies also offer Kanban-related learning: Scrum.org runs a Professional Scrum with Kanban course and assessment for Scrum Teams, and the ProKanban.org community teaches the Vacanti–Coleman guide. Course names and requirements change, so check the providers' current pages before relying on any of them. A personal credential shows that someone has been trained; it says nothing about whether their organisation's kanban systems work.

The Kanban Maturity Model

The Kanban Maturity Model (KMM), by David J. Anderson and Teodora Bozheva, is the method's main tool for assessing how deeply an organisation has adopted Kanban. It describes seven maturity levels, numbered 0 to 6, from level 0 (oblivious), where individuals manage their own work with little shared process, up to level 6, where the organisation's culture, strategy and services are fully aligned and it can adapt to survive major change. For each level the model lists Kanban practices, cultural values and expected business outcomes. Some published versions of the model use level names that echo CMMI (such as Defined and Managed), while others name the levels after business outcomes; either way its focus is on flow, fitness for purpose and culture rather than process compliance.

The KMM is used for improvement, not for passing an audit. A coach observes boards, policies, meetings and metrics, decides which practices are in place, and then recommends the next practices that would help, avoiding jumps that the culture cannot yet support. Some coaches and consultancies offer structured KMM-based appraisals, but there is no public register of "KMM level" organisations comparable to certification schemes for ISO standards.

How to tell whether Kanban is working

The most useful assessment is the one you run yourself against the reasons you adopted Kanban. Useful questions include: are lead times shorter and less variable than before; is the delivery rate steady; how many items are blocked and for how long; do customers report better predictability; are WIP limits respected, and when they are broken, is that discussed; and have explicit policies changed as a result of reviews? A board that has not changed in six months, with no WIP limits and no metrics, is a sign that the method has stopped at visualisation.

Lesson 6 – Worked example

The following is an illustrative scenario, not a real company. It shows how the parts of the method come together in a typical first year.

The situation

Northfield Mutual, a mid-sized insurer, has a twelve-person Platform Services team that provides cloud environments, database changes, access requests and infrastructure fixes to around twenty product teams. Requests arrive by email, chat and a ticketing tool. The team lead reports that "everything is urgent", engineers juggle up to eight requests each, and product teams complain that they can never predict when an environment will be ready. Attempts to impose fixed two-week iterations failed because a third of the work is unplanned.

Step 1 – Listening

The team's delivery manager runs a STATIK workshop. Product teams name their main frustration: unpredictability. A request might take two days or six weeks with no warning. Engineers name theirs: constant interruptions and unclear priorities. Both groups agree that predictability matters more than raw speed.

Step 2 – Demand and capability

Analysing three months of tickets, the team finds four work item types: access requests (many, small), database changes (moderate), new environments (fewer, larger) and incidents (unpredictable). From the ticket dates they calculate that, on average, about 45 items are open at any time and about 15 are closed per week. Using Little's Law as a sanity check, the average item takes around three weeks, which matches what customers feel. The lead time histogram is very wide: some items finish in a day, others take forty days.

Step 3 – Modelling the workflow and designing the board

Rather than inventing an ideal process, the team maps what actually happens: requests are triaged, then wait for an engineer, are worked on, wait for a security review (for some types), are verified and then handed back. The board gets these columns: Options, Ready, In progress, Waiting for security review, Verify and Delivered. The commitment point is the move from Options to Ready; the delivery point is the move to Delivered. Swimlanes separate incidents from planned work.

Step 4 – Policies and WIP limits

The team writes its first explicit policies on the board itself:

Ready holds at most eight items; product team representatives replenish it in a 20-minute meeting every Tuesday and Thursday.
In progress is limited to nine items for twelve people, to encourage pairing on larger work.
Incidents form an expedite class: at most one at a time, allowed to exceed the WIP limit; the person on call pulls it immediately.
Regulatory changes with a deadline are fixed-date items and must enter Ready at least three weeks before their date.
An item may move to Verify only when its acceptance notes are filled in and peer-checked.

Step 5 – Cadences

The existing Monday team meeting becomes the start of a daily 15-minute Kanban meeting, held at the board, which walks from Delivered back towards Ready and focuses on blocked and ageing items. The twice-weekly replenishment meetings replace ad-hoc email requests. Every two weeks, the delivery manager holds a service delivery review with product team representatives, showing the lead time chart and blocker list.

Step 6 – Evolving

Within six weeks the cumulative flow diagram shows a widening band in "Waiting for security review". At the next service delivery review, the blocker list reveals that one security specialist reviews every change, including trivial access requests. The team and the security group agree a new policy: standard access requests that match an approved pattern skip the manual review, with automated checks instead. The band shrinks. Later, the team lowers the In progress limit from nine to seven and finds that lead times drop further without anyone being idle, because people now help clear blockers.

Results after nine months

Average WIP is down to about 20 items, the delivery rate is roughly unchanged at 15 per week, and so average lead time is now about 1.3 weeks, or roughly nine days. More importantly, the lead time distribution has narrowed: 85% of standard items now finish within 14 days, which the team publishes as its service level expectation. Product teams plan around it. The team did not change job titles or reorganise; it started from what it was doing and changed it step by step, which is exactly what the change management principles describe. In KMM terms, a coach would say the team has moved from scattered individual practice towards a defined, managed service, with a clear next step of linking its metrics with those of the services it depends on.

Lesson 7 – Relationship to other standards and frameworks

Kanban rarely stands alone. It is often combined with, compared with, or embedded in other frameworks. The table summarises the most common relationships.

Framework or standard	What it is	Relationship to the Kanban Method
Toyota Production System and Lean	Manufacturing philosophy focused on flow, eliminating waste and continuous improvement (kaizen)	The source of kanban cards, pull and WIP control. Kanban adapts these ideas to knowledge work, where items vary greatly in size and much of the work is discovery.
Scrum (Scrum Guide 2020)	A framework of fixed-length Sprints, three accountabilities, five events and three artifacts	Scrum prescribes roles and timeboxes; Kanban starts from the current process and prescribes neither. Many teams add Kanban practices (visualisation, WIP limits, flow metrics) inside Scrum; Scrum.org's Kanban Guide for Scrum Teams describes this combination.
The Kanban Guide (kanbanguides.org, edition 2025.5)	A minimal definition of Kanban as a strategy for optimising the flow of value	Shares the core of visualising work and controlling WIP. It has three practices and four flow metrics (WIP, throughput, work item age, cycle time) and a "Definition of Workflow"; it does not include Kanban University's change management principles or cadence network.
CMMI	A capability and maturity model for improving processes, with formal appraisals	The Kanban Maturity Model borrows the idea of maturity levels and echoes some CMMI naming, but focuses on flow and culture. Organisations sometimes use Kanban practices to meet CMMI process expectations.
ITIL 4	Guidance for IT service management, built around a service value system and practices	Both are service-oriented. Kanban boards and WIP limits are often used to run ITIL practices such as change enablement, incident and service request management, and ITIL 4's guiding principle "collaborate and promote visibility" points the same way.
DevOps and DORA metrics	Practices and research linking delivery performance to measures such as lead time for changes and deployment frequency	Kanban's emphasis on lead time, delivery rate and limiting batch size supports the same goals; a kanban system gives visibility of where work waits before deployment.
Scaled frameworks (for example SAFe)	Frameworks for coordinating many agile teams	Several use kanban systems at portfolio or programme level to visualise and limit the flow of large initiatives. Kanban University's own approach to scale is Enterprise Services Planning.

Kanban and Scrum in more detail

The comparison with Scrum comes up so often that it deserves a few more sentences. Scrum batches work into Sprints and plans each one at its start; Kanban flows items continuously and replenishes whenever space frees up. Scrum has explicit accountabilities (Product Owner, Scrum Master, Developers); Kanban keeps existing roles, although Kanban literature describes two optional roles, the service request manager, who looks after customer demand, and the service delivery manager, who looks after flow. Scrum's main measure of progress is a Done Increment each Sprint; Kanban's main measures are lead time and delivery rate. Neither is "better": the choice depends on how predictable demand is and how much structure a team needs. Many mature teams use elements of both.

Choosing a vocabulary

If your organisation trains people in both Kanban University courses and Scrum.org or ProKanban.org classes, agree on terms early. "Lead time" in the Kanban Method and "cycle time" in the Vacanti–Coleman guide describe similar ideas measured from each guide's own start point, while in Lean manufacturing "cycle time" often means something different again. Writing the definitions into your explicit policies removes most confusion.

Common pitfalls and best practices

Pitfalls to avoid:

A board without limits. Teams put up columns and cards but never set WIP limits, so the board shows the overload without reducing it. Visualisation is the first practice, not the whole method.
Ignoring the limits under pressure. Limits are respected in quiet weeks and broken whenever a manager pushes. Once that happens the pull signal disappears, and long lead times and multitasking return.
Modelling the ideal instead of the real. A board with three tidy columns hides the queues and hand-offs where most delay happens, so improvement work targets the wrong places.
Everything is expedite. When urgent lanes fill up, the class of service loses its meaning and standard work stalls.
Metrics without conversations. Charts are produced but no review ever leads to a changed policy, so feedback loops exist in name only.
Optimising one team in isolation. A team speeds up its own column while items still wait weeks for an upstream decision or downstream approval.
Using metrics to judge individuals. Turning lead time into a personal performance target encourages gaming and destroys the transparency the method depends on.

Best practices:

Start from today's process. Map how work actually flows, including waiting states, and agree the first board with the people who do the work.
Introduce WIP limits early and adjust them with evidence. Begin near current levels and lower them gradually while watching lead times and blockers.
Define commitment and delivery points clearly. Everyone should know when the clock starts and stops, and what "delivered" means to the customer.
Write policies where the work is. Keep explicit policies short, visible on or next to the board, and owned by the team so they can be changed when needed.
Build cadences gradually. Reuse existing meetings first, keep them short and focused on flow, and add reviews as the system grows.
Forecast with history. Use lead time distributions and delivery rates to give customers probabilistic dates instead of single-point promises.
Look at the whole service network. Review dependencies regularly so that improvements in one place do not simply move the bottleneck.

Summary and key takeaways

The Kanban Method, maintained by Kanban University, is a method for managing and improving services that deliver knowledge work; it is not a formal standard and has no numbered edition.
It starts with what you do now and improves it through small, agreed, evidence-based changes, encouraging leadership from everyone.
Its six general practices are visualise, limit WIP, manage flow, make policies explicit, implement feedback loops, and improve collaboratively and evolve experimentally.
Limiting work in progress turns a board into a pull system; by Little's Law, lower average WIP at the same delivery rate means shorter average lead time.
Commitment and delivery points define lead time; classes of service and explicit policies govern how different kinds of work are treated.
STATIK provides a structured way to design a first kanban system from real dissatisfaction, demand, capability and workflow.
There is no organisational certification; individuals can earn credentials, and the Kanban Maturity Model helps organisations plan their next improvements.
Kanban complements Scrum, ITIL, Lean and DevOps practices, and differs from the Vacanti–Coleman Kanban Guide mainly in scope and vocabulary.

Reflection questions

Think of a team you work in or with. Where does work actually wait today, and how would you show those waiting states on a first kanban board?
If you introduced WIP limits tomorrow, who would resist and why? How could the change management principles help you address that resistance?
Which work in your environment would qualify as expedite, fixed date, standard and intangible? What explicit policy would you write for each?
Your service averages 25 items in progress and finishes 5 per week. What does Little's Law suggest about average lead time, and what would you try first to improve it?
A manager asks you to "certify the department for Kanban". How would you explain what can and cannot be certified, and what evidence you would show instead?