Kanban Flow Stinger

---
name: "kanban-flow-stinger"
description: "Improve Kanban flow. Use for WIP limits, cycle time, throughput, Little's Law, board design, or cumulative flow. Read guides/ for the decision path."

license: AGPL-3.0-or-later
---

# kanban-flow Stinger

The arsenal for `kanban-flow-wasp-drone`. This skill encodes the Kanban Method from the Toyota Production System lineage through David J. Anderson's 2010 formalization to the 2026 practitioner landscape, with hands-on implementation guidance for the tools teams actually use.

**Master index:** read `SKILL.md` (this file) first to orient. Then open the guide for the specific domain the user's question touches. All factual claims in the guides trace to files in `research/`.

---

## When this stinger applies

Activate on any of:

- "Our WIP keeps climbing" / "team has too much in flight"
- "We can't predict when work will finish"
- "How do I measure cycle time?" / "what's our throughput?"
- "Apply Little's Law to our board"
- "Help us design our Kanban columns" / "we need WIP limits"
- "Should we use Kanban or Scrum?"
- "How do I set up Kanban in Linear / Jira / GitHub Projects?"
- "Why is our flow efficiency so low?"
- "kanban-flow-wasp-drone" invoked directly

Do NOT activate for:

- Sprint planning, retrospectives, or velocity measurement (Scrum; no peer Drone today)
- CI/CD deployment pipeline design (`devops-wasp-drone`)
- Prometheus / Grafana / Datadog metric dashboards for infrastructure (monitoring stack)
- Custom Kanban app development in React or Python (hand off after designing the board)

---

## Guardrails (from SUBAGENT CRITICAL DIRECTIVES)

These are non-negotiable before proceeding with any recommendation:

1. **Surface WIP limits first.** Without WIP limits, what you are looking at is a task list, not Kanban. Every recommendation starts here. Source: `research/internal/command-brief-summary.md`.

2. **Never set a WIP limit without data.** Arbitrary limits ("just use 3") create false confidence. Ask for historical WIP or throughput data. If none exists, explain how to gather two weeks of data first. See `guides/01-wip-limits.md`. Source: `research/external/2026-05-20-wip-limits-agile-flow-consulting.md`.

3. **Always distinguish cycle time from lead time.** Define which clock starts and ends for each. Conflation is the most common flow-metric error. See `guides/02-flow-metrics.md`. Source: `research/external/2026-05-20-flow-metrics-definitions-cylenivo.md`.

4. **Apply Little's Law only in steady state.** If >20% of WIP is blocked or the expedite queue is active, flag non-steady-state before running L = λW. See `guides/03-littles-law.md`. Source: `research/external/2026-05-20-littles-law-abstract-algorithms.md`.

5. **Respect the Toyota lineage without dogmatism.** Kanban evolved from TPS, but software teams are not car factories. Use the theory to explain *why* practices work, not to shame adaptation.

6. **Distinguish the Kanban Method from a Kanban board.** A Scrum team using a board is NOT practising Kanban (no explicit policies, no WIP limits, no cadence meetings). Correct this politely but clearly.

7. **Confirm the target tool before prescribing configuration.** Linear (no native WIP limits), Jira (swimlane WIP bug), and GitHub Projects (visual-only limits) all behave differently. See `guides/08-tool-implementation.md`. Source: `research/external/2026-05-20-tool-wip-limits-honest-review.md`.

---

## Guide map

Open the guide that matches the user's question. Each guide is self-contained and cites its research sources.

| Guide | When to open |
|---|---|
| `guides/00-kanban-theory.md` | User asks about the Kanban Method's foundations, Toyota lineage, or the six general practices |
| `guides/01-wip-limits.md` | WIP limit setting, enforcement, Little's Law connection to cycle time |
| `guides/02-flow-metrics.md` | Calculating cycle time, lead time, throughput, flow efficiency, WIP age |
| `guides/03-littles-law.md` | L = λW application, steady-state assumptions, three-variable dial, forecasting |
| `guides/04-cumulative-flow-diagram.md` | Reading the CFD, seven anti-pattern shapes, leading vs lagging indicators |
| `guides/05-board-design.md` | Column structure, explicit policies, blocker notation, replenishment |
| `guides/06-class-of-service.md` | Four tiers (Standard, Fixed-Date, Expedite, Intangible), queue-bypass rules |
| `guides/07-kanban-vs-scrum.md` | Decision framework, Scrumban hybrid, migration path |
| `guides/08-tool-implementation.md` | Linear, Jira, GitHub Projects: exact configuration steps and known bugs |

---

## Template map

Use these stubs to produce deliverables for the user:

| Template | Use for |
|---|---|
| `templates/board-design-spec.md` | Column / WIP limit / policy / done-definition table |
| `templates/class-of-service-card.md` | Four-tier service class reference card |
| `templates/flow-metrics-report.md` | Computed metrics summary with interpretation |
| `templates/littles-law-forecast.md` | WIP-scenario forecast table |

---

## Example map

| Example | Shows |
|---|---|
| `examples/wip-limit-setup-happy-path.md` | End-to-end WIP limit implementation from raw throughput data to Jira configuration |
| `examples/cycle-time-diagnosis.md` | Diagnosing a cycle-time spike using flow metrics and CFD shape |

---

## Key benchmarks (2026 practitioner data)

These numbers come from `research/external/2026-05-20-value-stream-metrics-axify.md` and should be cited when calibrating expectations:

- **Typical software team flow efficiency:** 5-20% (15-20% is mature/WIP-limited; single-digits is common in unoptimized teams)
- **Elite cycle time (p75):** 1.8 days
- **Elite lead time:** sub-24 hours
- **Scrumban adoption:** 45% of Scrum teams migrate to Scrumban after 2-3 years (State of Agile 2026)
- **WIP limit ROI case study:** a 12-person team achieved 42% cycle time reduction (p85 62 days → 36 days) by implementing throughput-derived WIP limits

---

## Tool WIP limit status (2026)

From `research/external/2026-05-20-tool-wip-limits-honest-review.md`, confirmed April 2026:

| Tool | Native WIP limit enforcement | Notes |
|---|---|---|
| **Linear** | None | GraphQL API workaround available; soft enforcement via naming convention |
| **Jira Software** | Column limits only (not per-swimlane) | Swimlane WIP count bug: Atlassian has not fixed; see `guides/08-tool-implementation.md` |
| **GitHub Projects** | Visual-only (no enforcement) | Column limit shows count in red but does not block card addition |
| **Azure DevOps Boards** | Column limits with enforcement | Most capable WIP enforcement of the four tools |
| **Trello** | None native | Power-Up plugins available |

---

## Open questions (for user decision before next stinger refresh)

Two questions from `research/research-summary.md` remain unresolved:

> TODO: Monte Carlo for small teams (< 5 people): Vacanti/ActionableAgile has not published 2025-2026 guidance specific to small sample sizes. Until resolved, `guides/03-littles-law.md` advises 15-20 data points minimum and directs users to ActionableAgile Analytics tooling.

> TODO: Kanban vs Shape Up formal comparison: No 2025-2026 comparison article found. `guides/07-kanban-vs-scrum.md` notes Shape Up as a distinct alternative with a brief first-principles contrast.

---

*Command Brief: `ai-tools/command-briefs/kanban-flow-wasp-drone-command-brief.md`*
*Research: `research/` (17 files, normal depth, 2025-11 to 2026-05)*
*Forged: 2026-05-20 by stinger-forge via gods-hand slot-04*