Skills / Project_300

Kanban Method

Stop starting, start finishing.

The Kanban Method is David J. Anderson's prescriptive framework for managing knowledge work through evolutionary change. Built on four Foundational Principles and six Core Practices, it transforms any team's workflow into a measurable system of visual boards, WIP limits, flow metrics, and explicit policies — without requiring a disruptive process overhaul. It applies equally to software teams, IT operations, marketing, legal, and any knowledge-work context.

By David J. Anderson  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisKanban Method

Input

“We have a Jira board with To Do, In Progress, and Done. Everything piles up in In Progress for weeks. We have around 20 things in progress at once…”

Diagnosis

I apply the Kanban Method — David Anderson's framework built on six Core Practices: Visualize, Limit WIP, Manage Flow, Make Policies Explicit, Implement Feedback Loops, and Improve Collaboratively.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Stop piling work on your team — visualize flow, cap WIP, and let metrics replace delivery guesswork

The Kanban Method is organized around four Foundational Principles — start with what you do now, pursue incremental evolutionary change, respect current roles and processes, and encourage leadership at all levels — paired with six Core Practices: Visualize, Limit WIP, Manage Flow, Make Policies Explicit, Implement Feedback Loops, and Improve Collaboratively. Teams design a Kanban board reflecting their actual workflow, then apply WIP limits per stage to expose bottlenecks and reduce multitasking. Flow is measured with lead time distributions, throughput run charts, and Cumulative Flow Diagrams (CFDs). Work is categorized into four Classes of Service (Expedite, Fixed Date, Standard, Intangible) with Service Level Expectations (SLEs) providing explicit delivery commitments. Seven standard cadences — from daily standups to quarterly strategy reviews — create the feedback loops that drive improvement. The Kanban Maturity Model (KMM) maps a team's progress across seven levels from Level 0 (Oblivious) to Level 6 (Congruent), providing a structured improvement roadmap grounded in queuing theory and systems thinking.

The problem

Most teams operate with invisible, unlimited work-in-progress — starting everything, finishing nothing, and unable to forecast when anything will be delivered. Generic agile boards create the appearance of visibility without the discipline of WIP limits, explicit policies, or flow measurement, leaving managers guessing at delivery dates and teams perpetually context-switching across too many open items. The result is unpredictable delivery, stakeholder distrust, and improvement discussions driven by opinion rather than data.

The solution

Apply the Kanban Method's six Core Practices to transform your team's workflow into a system where work is visible, capacity is explicitly capped, bottlenecks surface before they become crises, and delivery commitments are backed by real lead time data — not estimates or gut feel.

You bring

A description of your current workflow — how work enters, moves, and exits your team today (not the ideal version)
Known pain points: missed deadlines, constant context-switching, overloaded stages, or unpredictable delivery
Your team size, work type mix, and any existing metrics (lead time, throughput, or velocity data if available)
The improvement goal: faster delivery, better stakeholder predictability, reduced overload, or organizational flow visibility

You get

A Kanban Board Blueprint with named workflow columns, WIP limits, swimlane logic, and commitment/delivery point definitions
A Service Level Expectation (SLE) policy defining delivery targets per Class of Service, ready to share with stakeholders
A flow metrics diagnostic interpreting your lead time distribution, throughput, or CFD patterns with a concrete systemic recommendation
A KMM-aligned improvement roadmap placing your team on the 7-level maturity scale with the highest-leverage practices to adopt next

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team has 22 items in 'In Progress' on a 3-column Jira board. Code reviews sit untouched for three days with no visibility into the queue. A stakeholder asks when Feature X will ship — your honest answer is 'we're working on it.' Your last three releases slipped by a week or more, but you can't explain why because the workflow data doesn't exist.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Kanban Method

“Your board has 8 columns mapping your actual workflow, with WIP limits enforced at every stage. When Awaiting Review fills to its limit, the team sees it immediately and swarms. Your lead time histogram shows 85% of standard items complete within 9 business days — that's the commitment you give stakeholders, backed by 10 weeks of real data. Your last three releases matched the SLE target.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Kanban MethodClaude

Kanban Method

I apply the Kanban Method — David Anderson's framework built on six Core Practices: Visualize, Limit WIP, Manage Flow, Make Policies Explicit, Implement Feedback Loops, and Improve Collaboratively. Before we design anything, tell me: what does work actually look like on your team right now? Not the ideal version — how does it actually move from 'someone requests it' to 'it's delivered'?

We have a Jira board with To Do, In Progress, and Done. Everything piles up in In Progress for weeks. We have around 20 things in progress at once for a team of 6, and stakeholders constantly ask when things will be done. We have no real answer.

Twenty items in progress for six people is the root cause — not a symptom. Little's Law explains this precisely: Lead Time = WIP ÷ Throughput. If your team completes roughly 8 items per week and carries 20 in progress, your minimum average lead time is 2.5 weeks — but with no WIP limit, outliers stretch far longer. The first intervention isn't a process overhaul. It's a WIP limit. Before I can recommend the right number, I need to understand what's hidden inside 'In Progress.' Are substages like code review and QA collapsed into that single column?

Yes — code review and QA are both just 'In Progress.' Work often sits waiting for review for two or three days before anyone picks it up.

That's a hidden queue — and it's a primary source of your unpredictability. The Kanban Method requires making every workflow state visible, including waiting states. Your actual board should look more like: Committed → In Development (WIP: 4) → Awaiting Review (WIP: 3) → In Review (WIP: 2) → Awaiting QA (WIP: 2) → In QA (WIP: 1) → Done. The waiting columns ('Awaiting Review', 'Awaiting QA') are diagnostic instruments: when they fill up, you see exactly where work is accumulating and can respond — swarm, pair, or reprioritize — rather than discovering the delay after the fact. What's your team composition? I need developer, QA, and reviewer counts to calibrate the limits correctly.

Four developers, one dedicated QA engineer, and reviews are done by the developers themselves — no dedicated reviewer role.

That tells me the In Review WIP limit should pull from developer capacity, not a separate role. Here's a Board Blueprint for your team: Backlog (uncontrolled) → Ready (WIP: 8, your commitment point) → In Development (WIP: 4) → Awaiting Review (WIP: 3) → In Review (WIP: 2) → Awaiting QA (WIP: 2) → In QA (WIP: 1) → Done. Total active WIP across all stages: 12, down from your current 20. The Ready column is your commitment point — nothing enters Development until it meets your Definition of Ready. For stakeholder conversations, I'd set a Standard Class of Service SLE: '85% of Standard items complete within 10 business days of entering Ready.' You can validate that target after 4–6 weeks of data. Want me to generate the full Kanban Board Blueprint document — column definitions, entry/exit criteria, WIP limit rationale, and the SLE policy?

Yes. But I need to sell this to leadership — they'll push back and say limiting WIP means the team is doing less work.

That pushback is predictable, and there's a direct quantitative rebuttal. I'll include a WIP Limit Rationale page in the blueprint using the utilization-vs-lead-time curve: as a team approaches 100% utilization — everyone always fully occupied — lead time doesn't increase linearly, it increases exponentially. At 85% utilization, average lead time is roughly 6× the task processing time. At 95%, it's 20×. The message to leadership is precise: we are not doing less work. We are finishing work faster by reducing the queue in front of every stage. The data will confirm it within two sprint cycles. I'll also note your current KMM level: you're at Level 1 — a basic board exists but policies are implicit and no flow metrics are collected. The roadmap to Level 2 runs through exactly what we're building today: explicit WIP limits, visible waiting states, your first SLE, and lead time tracking. Generating your Kanban Board Blueprint and SLE Policy now.

Reply to Kanban Method…

What the skill is doing

01Kanban Board Design

02WIP Limit Calibration

03Flow Metrics Interpretation

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

KMKanban Methodtyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We have a Jira board with To Do, In Progress, and Done. Everything piles up in In Progress for weeks. We have around 20 things in progress at once for…9:14✓✓

Before we design anything, tell me: what does work actually look like on your team right now?9:14

Not the ideal version — how does it actually move from 'someone requests it' to 'it's delivered'?9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Kanban Board Design

Design a board that maps your team's actual workflow states — not a generic To Do / In Progress / Done template. This includes defining commitment points (where work is formally pulled), delivery points (where it exits), explicit waiting columns that reveal handoff delays, and swimlane logic for different work types or service classes.

◦ MethodBased on Anderson's Core Practice #1 (Visualize): the board must represent the real knowledge-work system, including hidden queues and waiting states, so all work items, blockers, and flow impediments are visible to the entire team and not buried inside a single overloaded column.

CapabilityC-02

WIP Limit Calibration

Determine appropriate WIP limits for each workflow stage based on team size, role mix, and flow goals. Limits are set to create slack, reduce context-switching, and force bottlenecks to surface as visible queue buildup rather than be absorbed by adding more work — making the constraint visible and actionable.

◦ MethodGrounded in Anderson's Core Practice #2 (Limit WIP) and queuing theory: Little's Law (Lead Time = WIP ÷ Throughput) shows that lower WIP directly reduces average lead time, and the utilization-vs-lead-time curve demonstrates that as teams approach 100% utilization, lead time increases exponentially — not linearly.

CapabilityC-03

Flow Metrics Interpretation

Analyze your team's lead time histogram, throughput run chart, and Cumulative Flow Diagram to diagnose systemic issues — an expanding WIP band signals work accumulating faster than it completes; a narrowing throughput trend reveals a capacity or process degradation; a staircase CFD pattern exposes batch releases hiding continuous flow problems.

◦ MethodBased on Anderson's Core Practice #3 (Manage Flow): CFDs, lead time distributions, and throughput data are the primary diagnostic instruments of the Kanban Method, enabling evidence-based decisions and objectively measurable improvement rather than opinion-based retrospectives.

CapabilityC-04

Classes of Service Definition

Categorize your team's work into Anderson's four Classes of Service — Expedite (drop everything, highest cost of delay), Fixed Date (deadline-driven), Standard (normal flow), and Intangible (deferred value) — and define explicit Service Level Expectations for each, creating a shared prioritization policy that eliminates ad hoc escalation.

◦ MethodBased on Anderson's Core Practice #4 (Make Policies Explicit): Classes of Service and SLEs replace informal negotiation with a documented, agreed-upon system for handling different work types, which reduces managerial overhead, clarifies stakeholder expectations, and makes the cost of policy violations visible.

CapabilityC-05

KMM Maturity Assessment

Evaluate your current Kanban implementation against the seven levels of the Kanban Maturity Model — from Level 0 (Oblivious: no workflow awareness) through Level 6 (Congruent: organization-wide flow optimization) — and identify the specific practices that will advance your team to the next maturity level without overreaching.

◦ MethodThe KMM is Anderson's structured model for assessing organizational fitness; it prevents teams from attempting advanced practices like statistical Monte Carlo forecasting before foundational practices — visualization, WIP limits, and explicit policies — are stable and producing consistent data.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Kanban Board Blueprint

A complete specification for your team's Kanban board: workflow column names and state definitions, WIP limits per stage with rationale, swimlane logic, commitment and delivery point markers, and the rules governing how cards advance — ready to configure in any board tool.

OutputD-02

Service Level Expectation (SLE) Policy

A one-page policy document defining each Class of Service your team handles, the target lead time for each (e.g., 'Standard items: 85% completed within 14 calendar days of entering Ready'), and the handling rule for Expedite work — formatted for stakeholder review and team wall posting.

OutputD-03

Flow Metrics Diagnostic

An annotated interpretation of your team's flow data identifying the specific CFD pattern, lead time distribution shape, or throughput trend that reveals your primary systemic constraint, paired with a concrete Kanban practice recommendation to address it.

OutputD-04

KMM Improvement Roadmap

A maturity assessment placing your team on the 7-level KMM scale, with the top three highest-leverage practices to adopt next, organized by which Core Practice they belong to and what observable, measurable improvement each will produce.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

David J. Anderson

David J. Anderson developed the Kanban Method between 2004 and 2007 while leading engineering teams at Microsoft and Corbis, formalizing the framework in his 2010 book 'Kanban: Successful Evolutionary Change for Your Technology Business.' He founded Lean Kanban University, the global certification body for Kanban practitioners and trainers, and authored the follow-on work 'Kanban from the Inside' (2014). Anderson is the principal architect of the Kanban Maturity Model (KMM) and a co-founder of the international Lean Kanban conference series.

Status · Inspired by David J. Anderson’s work — not yet claimed. Are you David J. Anderson?

Primary sourceS-01

Kanban: Successful Evolutionary Change for Your Technology Business

by David J. Anderson

Creator of the Kanban Method; founder of Lean Kanban University; author of two foundational books (2010, 2014); developed the method at Microsoft and Corbis

Read the original ↗

Citationdjaa.com

In the build queue

Be first to run it.

Kanban Method is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchOur team has too much in progress, unpredictable delivery, and a 3-column Jira board that hides what's really happening. Can we design a proper Kanban system — board columns, WIP limits, and a stakeholder SLE — from scratch?