Merge pull request 'Add kanban-guru skill — virtual Kanban expert' (#17) from feat/kanban-guru-skill into main

Reviewed-on: https://git.brandyapple.com/magnus/agent-skills/pulls/17

AGENTS.md

@@ -58,6 +58,7 @@ When the user mentions these keywords, load the corresponding skill:
 | "weather", "forecast", "temperature", "is it raining", "Tempest" | [tempest-cli](tempest-cli/SKILL.md) |
 | "reverse-engineer", "understand this codebase", "PRD from code", "architecture document" | [software-architecture-analysis](software-architecture-analysis/SKILL.md) |
 | "data architecture", "data platform", "data strategy", "data mesh", "governance" | [data-architect](data-architect/SKILL.md) |
+| "kanban", "WIP", "cycle time", "flow metrics", "Scrum to Kanban", "multi-portfolio", "throughput", "classes of service" | [kanban-guru](kanban-guru/SKILL.md) |
 | "skill format", "how do I make a skill", "agentskills.io" | [agent-skills](agent-skills/SKILL.md) |
 
 ## Best Practices

README.md

@@ -36,6 +36,10 @@ Ghost CMS from the terminal. Manage posts and pages, list tags, and check site i
 
 Jellyfin media server from the terminal. Check server info, browse recently added, search your library by type, list libraries, and view statistics.
 
+### [kanban-guru](kanban-guru/SKILL.md)
+
+A virtual Kanban expert for engineering teams. Diagnose flow problems, design board configurations, calibrate WIP limits, establish service level expectations, set up multi-portfolio operating models, and navigate Scrum-to-Kanban transitions. Covers all seven cadences, classes of service, Little's Law, flow metrics, and the full practitioner's playbook with rich reference material.
+
 ### [jira-cli](jira-cli/SKILL.md)
 
 Atlassian Jira from the terminal. Search issues with JQL, view details, create issues, add comments, list projects, and transition status. API token from id.atlassian.com.

kanban-guru/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: kanban-guru
+description: >-
+  A virtual Kanban expert who can diagnose flow problems, design board
+  configurations, set up multi-portfolio operating models, calibrate WIP
+  limits, establish service level expectations, and guide Scrum-to-Kanban
+  transitions. Load this when your team is struggling with throughput,
+  cycle times are unpredictable, multiple stakeholders compete for the
+  same engineers, or you're wondering if Kanban is right for you.
+compatibility: >-
+  Designed for agentic AI assistants (Hermes Agent, Claude Code, OpenCode,
+  GitHub Copilot, Cursor, similar coding/chat agents). No special system
+  requirements.
+metadata:
+  author: kanban-guru contributors
+  version: "1.0.0"
+  topics: kanban, agile, flow-metrics, wip-limits, multi-portfolio, lean, engineering-management, product-management
+---
+
+# Kanban Guru — Virtual Expert
+
+When this skill is loaded, I become a **virtual Kanban expert** — someone who's helped enough engineering teams navigate flow-based delivery to recognize the patterns early. I don't need you to know what's wrong. If you're not sure where to start, describe what you're feeling and I'll help you find the diagnosis.
+
+## Do You Need a Kanban Guru? (Recognizing the Symptoms)
+
+Load this skill if any of these sound familiar — even if you're not sure how to fix them:
+
+**Flow pain signals:**
+- Cycle times are unpredictable and stakeholders are losing confidence in delivery dates
+- Your team is serving multiple product managers and everyone feels like they're competing for the same engineers
+- WIP keeps growing but throughput stays flat — people are busy but nothing finishes
+- Sprint commitments slip routinely and the sprint review is where surprises surface
+- Your team context-switches between different portfolios within the same day or week
+- Production incidents and urgent requests constantly blow up your sprint plan
+- You're about to switch from Scrum to Kanban and need a sane transition path
+- Someone just asked "should we try Kanban?" and you need a structured evaluation
+
+**Ambient anxiety signals:**
+- "I feel like we're always busy but not delivering faster"
+- "Different PMs keep asking 'when will my thing be done?' and I don't have a consistent answer"
+- "Our standup is a reporting ritual, not a coordination mechanism"
+- "We have too much work in progress but everyone says their item is the priority"
+
+Not sure if you're a candidate? Say "I don't know where to start" and I'll run a quick diagnostic.
+
+## QuickScan — Five Minutes to Spot Common Gaps
+
+If you're not sure what problems you have, answer these yes/no questions. I'll focus on where to dig first.
+
+**Q1: WIP visibility.** Can you, right now, name every item in progress across your team and how long each has been there?
+- If no → start with the board. See `references/wip-limits.md` and `references/flow-metrics.md` for setup guidance.
+
+**Q2: Pull discipline.** Do engineers pull new work only when they have capacity, or is work assigned to them?
+- If work is assigned → you have a push system, not Kanban. See `references/transition-guide.md` for the shift to pull.
+
+**Q3: Multi-portfolio governance.** If your team serves multiple stakeholders, is there a visible, agreed-upon capacity allocation between them?
+- If no → you have hidden competition for engineering time. See `references/multi-portfolio.md`.
+
+**Q4: Delivery predictability.** When a stakeholder asks "when will this be done," do you give a probabilistic range based on historical data, or a single date?
+- If single dates → you're making commitments without evidence. See `references/flow-metrics.md` on SLEs and forecasting.
+
+**Q5: Policies.** Does your team have written, visible rules for Definition of Ready, expedite criteria, and how pull decisions are made?
+- If no → the rules live in the manager's head. See `references/classes-of-service.md`.
+
+**Scoring:**
+- **0-1 no's:** You're in good shape. Pick the specific area that bothers you most.
+- **2-3 no's:** Classic growing-pain territory. Say "I don't know where to start" and I'll prioritize.
+- **4-5 no's:** You've been flying without instruments. This is exactly the right time to bring in Kanban thinking.
+
+## What I Do When Loaded
+
+I help in three modes depending on what you need:
+
+### Diagnosis Mode
+Describe your team's current pain. I'll map it to Kanban patterns — which cadence is missing, which metric would reveal the root cause, which policy change would shift the dynamic. I don't need you to speak Kanban terminology. Just describe what's happening.
+
+### Design Mode
+Tell me what you're trying to achieve and your constraints. I'll help design:
+- A board structure with columns, WIP limits, and swimlanes
+- A class-of-service policy set
+- A multi-portfolio capacity allocation model
+- A set of cadences with agendas and participants
+- A measurement and reporting framework
+
+### Transition Mode
+If you're moving from Scrum to Kanban, I'll help you sequence the change — what to keep, what to replace, and how fast to move based on your organization's change tolerance. See `references/transition-guide.md` for the full playbook.
+
+## Core Kanban Principles (Quick Reference)
+
+If you're new to Kanban or need a refresher, here's the compressed model:
+
+**Pull system.** Engineers take new work only when they have capacity — not when work is assigned by a manager. The board enforces this through WIP limits. Work moves when downstream capacity exists, not when upstream wants to push.
+
+**WIP limits.** The primary flow control mechanism. Each workflow stage has a maximum number of items. When a stage hits its limit, upstream stops feeding it. This forces finishing over starting.
+
+**Explicit policies.** Written, visible rules for how work moves: Definition of Ready, Definition of Done, class-of-service rules, pull criteria. A new team member should be able to read the policies and know how to behave in every routine situation.
+
+**Flow metrics.** Four core measurements: WIP (items in system), Cycle Time (time from commitment to done), Throughput (items completed per period), Flow Efficiency (active work time / total cycle time). Related by Little's Law: WIP = Throughput × Cycle Time.
+
+**Classes of service.** Not all work is equal. Four canonical classes: Expedite (crisis), Fixed Date (deadline-driven), Standard (default), Intangible (tech debt/investment). Each has distinct policies for WIP treatment and cycle time expectations.
+
+**Cadences.** Seven coordination rhythms from daily to quarterly: Daily Standup, Replenishment, Delivery Planning, Service Delivery Review, Team Retrospective, Risk Review, Strategy Review.
+
+## When to Load Reference Files
+
+| If this comes up... | Load this reference |
+|---|---|
+| Team serves multiple PMs or portfolios | `references/multi-portfolio.md` |
+| Setting up WIP limits or they keep getting breached | `references/wip-limits.md` |
+| Need to define classes of service or expedite criteria | `references/classes-of-service.md` |
+| Stakeholders want delivery date predictions | `references/flow-metrics.md` |
+| Moving from Scrum to Kanban | `references/transition-guide.md` |
+| Confused by a Kanban term | `references/glossary.md` |
+| Setting up the seven cadences | `references/cadences.md` |
+
+## Common Anti-Patterns to Watch For
+
+**Everything is expedite.** If your expedite lane is never empty, you don't have an urgency problem — you have a class-of-service definition problem. Expedite means crisis, not high priority. Tighten the criteria. See `references/classes-of-service.md`.
+
+**WIP limits always breached.** Breaches are diagnostic signals, not triggers to raise the limit. When the limit is hit, ask: are items too large? Is there a downstream bottleneck? Are expedites flooding the system? See `references/wip-limits.md` on the Little's Law trap.
+
+**Side-channel asks.** PMs or leaders sending requests directly to engineers outside the board. This destroys allocation visibility and defeats WIP limits. The fix: all work enters through Replenishment. No exceptions. See `references/multi-portfolio.md`.
+
+**Standup as status report.** Walking around the room asking "what did you do yesterday" is a reporting ritual, not a coordination mechanism. Walk the board right-to-left, starting at Done. Focus on blocked and aging items. See `references/cadences.md`.
+
+**Velocity as a proxy for productivity.** Velocity measures output, not outcomes. It is easily gamed, systematically over-optimistic (it ignores waiting time), and creates perverse incentives. Replace with cycle time and throughput trends. See `references/flow-metrics.md`.
+
+## How I Consult
+
+**I push back on premature solutions.** Before any board configuration or policy recommendation, I need to understand your team structure, demand profile, current pain, and organizational constraints.
+
+**I make tradeoffs explicit.** Every Kanban design decision is a set of tradeoffs — tighter WIP limits improve cycle time but require more discipline. More classes of service add precision but increase complexity. I frame the choices clearly.
+
+**I think in flow, not tasks.** I trace work from request through delivery, identifying where waiting accumulates, where policies are missing, and where governance gaps exist.
+
+**I design for the team that will maintain it.** A sophisticated board with perfect policies is a liability if the team can't operate it daily. I factor in team maturity, organizational culture, and change capacity.
+
+**I teach as I go.** If you don't know what a term means or why I'm asking, say so. I'll explain the concept and why it matters before we proceed.
+
+**I'm honest about uncertainty.** Kanban is empirical — the right answer comes from measuring your system, not from theory. I'll give you a starting point, but I'll always say "measure this for two weeks and we'll calibrate from there."

kanban-guru/references/cadences.md

@@ -0,0 +1,120 @@
+# The Seven Kanban Cadences
+
+Unlike Scrum's four ceremonies, Kanban defines seven cadences spanning from daily coordination to quarterly strategy. These cadences replace the ad-hoc management conversations, escalation chains, and priority negotiations that emerge in the absence of structure.
+
+## 1. Daily Kanban Standup
+
+**Frequency:** Daily. **Duration:** 15 minutes hard stop. **Participants:** Whole team.
+
+**Purpose:** Optimize today's flow. Identify and address blockers. Determine what to pull next.
+
+**Format:** Stand at the board. Walk **right-to-left** — start at the column closest to Done, move leftward. Focus on blocked and aging items. Do not have individuals report what they did yesterday — the board shows that.
+
+**Agenda:**
+1. Review Done column (2 min) — what shipped? Celebrate briefly.
+2. Review In Review (3 min) — any items blocked waiting for feedback, deployment? Who can unblock?
+3. Review In Progress (5 min) — stuck, blocked, or aging items? Are we at WIP limit?
+4. Determine what to pull from Ready (3 min) — given WIP and allocations, what's next?
+5. Parking lot (2 min) — blockers needing offline follow-up. Don't solve in standup.
+
+**Anti-patterns:** Going around the room for individual status updates. Solving problems in standup. Treating it as reporting to the EM rather than team coordination.
+
+## 2. Replenishment (Intake)
+
+**Frequency:** 1–2× per week. **Duration:** 30–60 minutes. **Participants:** EM/TL + PMs.
+
+**Purpose:** Decide what enters the Ready queue, respecting WIP capacity and capacity allocations. Close the intake to all other entry paths.
+
+**Agenda:**
+1. System state review — current WIP, throughput, capacity allocations
+2. Fixed Date and Bug items first (objective urgency)
+3. PMs present candidates
+4. Selection respects allocation percentages and WIP capacity
+5. Return items that don't meet Definition of Ready
+
+**Key rule:** All new work enters through Replenishment. No side-channel asks to engineers. The EM/TL enforces this boundary consistently.
+
+## 3. Delivery Planning
+
+**Frequency:** Weekly or bi-weekly (often combined with Replenishment). **Duration:** 30–45 minutes.
+
+**Purpose:** Coordinate near-term delivery expectations against actual WIP and throughput data. Surface Fixed Date items at risk. Resolve timing conflicts between portfolios.
+
+**Agenda:**
+1. WIP aging review (10 min) — walk in-progress items sorted by age, oldest first
+2. Fixed Date calendar review (10 min) — upcoming deadlines, flag at-risk items
+3. Throughput-to-commitment check (10 min) — for each portfolio, does pipeline clear rate match roadmap expectations?
+4. Dependency and constraint review (10 min) — cross-team, infrastructure, skills
+5. Adjustments and escalations (5 min)
+
+## 4. Service Delivery Review (SDR)
+
+**Frequency:** Bi-weekly or monthly. **Duration:** 60–90 minutes. **Participants:** EM/TL + all PMs + leadership (optional).
+
+**Purpose:** The primary governance loop for shared teams. Inspect actual throughput against allocation targets, review SLE adherence, analyze systemic blockers, and make allocation adjustment decisions with data.
+
+**Pre-work (distributed 24h in advance):** Data packet with throughput by portfolio, lead time distribution, blocker log, SLE hit rate.
+
+**Agenda:**
+1. Service definition reminder (3 min) — current allocation splits
+2. Throughput by portfolio (12 min) — actual vs. target
+3. Lead time and SLE review (12 min) — 85th percentile by class of service
+4. Blocker analysis (10 min) — categorize by root cause; identify top patterns
+5. PM portfolio health checks (10 min) — each PM asserts under/over-served
+6. Improvement experiments (15 min) — 1–2 changes to test next period
+7. Allocation decision (10 min, if needed) — temporary shifts, documented
+8. Close-out (3 min)
+
+**See also:** `references/multi-portfolio.md` for deeper governance context.
+
+## 5. Team Retrospective
+
+**Frequency:** Every 2–4 weeks. **Duration:** 60–90 minutes. **Participants:** Engineering team only.
+
+**Purpose:** Inward-focused improvement. How are we working together? What can we improve about our practices? Separated cleanly from the SDR's outward-facing service review.
+
+**Suggested format (75 min):**
+1. Safety check (5 min) — anonymous psychological safety rating
+2. What went well? (15 min) — practices, behaviors, decisions worth repeating
+3. What was hard or frustrating? (20 min) — systemic observations, not personal complaints
+4. What shall we change? (20 min) — 1–3 concrete experiments with owners and success criteria
+5. Close loop on previous experiments (10 min) — what happened? Continue, adjust, or stop?
+
+**PM participation:** Not recommended. PMs are stakeholders, not team members. Their concerns belong in the SDR and Replenishment.
+
+## 6. Risk Review
+
+**Frequency:** Monthly. **Duration:** 60 minutes. **Participants:** EM/TL + engineering leadership + optional PMs.
+
+**Purpose:** Identify and mitigate systemic threats to delivery — technical, operational, organizational, and market risks that will become next quarter's service failures if left unaddressed.
+
+**Risk categories for shared teams:**
+- **Technical/architectural:** Accrued tech debt, legacy dependencies, SPOFs
+- **Capacity/skill:** Skills concentrated in one or two engineers, bus factor
+- **Dependency:** External teams, vendors, data providers multiple portfolios depend on
+- **Operational/incident:** Recurring incident patterns suggesting systemic reliability issues
+- **Market/regulatory:** Incoming compliance deadlines, competitive pressures
+
+**Agenda:**
+1. Risk register review (15 min) — existing risks, status changes, completed mitigations
+2. Operational signal review (15 min) — blocker log, expedite frequency, WIP aging
+3. Forward-looking risk identification (15 min) — calendar scan, roadmap scan, architecture scan
+4. Mitigation planning (10 min) — likelihood, impact, owner, trigger
+5. Policy updates (5 min) — unplanned work buffer, expedite criteria, cross-training
+6. Escalation decisions (5 min) — risks requiring leadership authorization
+
+## 7. Strategy Review
+
+**Frequency:** Quarterly. **Duration:** 2–4 hours. **Participants:** CTO/CPO/VP Eng + portfolio leaders + EM/TL.
+
+**Purpose:** The highest-level cadence. Review whether portfolio capacity allocations reflect organizational priorities. Set the strategic parameters that will govern the next quarter of Replenishment decisions.
+
+**Agenda:**
+1. Operational evidence review (45 min) — throughput vs. targets, lead time trends, risk register
+2. Market and business context (30 min) — what changed externally?
+3. Cost-of-Delay analysis (30 min) — CD3 ranking of next quarter's major initiatives
+4. Allocation revision (30 min) — new allocation splits for next quarter
+5. Structural decisions (30 min) — headcount, skills investment, team composition
+6. Commitment and communication (15 min) — document decisions, assign communications
+
+The EM/TL is the bridge between strategy and execution — they bring operational truth upward to strategy and bring strategic decisions downward to the weekly cadences.

kanban-guru/references/classes-of-service.md

@@ -0,0 +1,83 @@
+# Classes of Service in Kanban
+
+Classes of Service (CoS) are the Kanban mechanism for differentiating how work items flow based on their urgency and cost of delay. They are not simply priority levels — each class carries distinct policies for WIP treatment, pull sequence, cycle time expectations, and governance.
+
+## The Four Canonical Classes
+
+### Expedite (Crisis)
+**Purpose:** Work with immediate, maximum cost of delay — production incidents causing user harm, active security breaches, regulatory violations with legal consequences.
+
+**Policy:** Pre-empts all other work. Bypasses WIP limits. Team swarms until resolved.
+
+**WIP Limit:** 1 on the Expedite lane — prevents simultaneous crises from fracturing the team.
+
+**Cost of Delay Profile:** Immediate and maximum — delay has high cost right now (exponential).
+
+**SLE Target:** 95% within 24 hours (or faster, depending on severity).
+
+**Common Mistake:** Treating "high priority" as expedite. High-priority work belongs in Fixed Date or Standard with an aggressive queue position. Expedite means crisis — if your expedite lane is never empty, the definition is too loose.
+
+### Fixed Date (Deadline-Driven)
+**Purpose:** Work with a specific future deadline and high cost of missing it — regulatory filing dates, contractual milestones, external launch commitments.
+
+**Policy:** Pulled in advance based on throughput forecasting. Must pass Monte Carlo simulation at intake to confirm the deadline is achievable before the team commits.
+
+**Cost of Delay Profile:** Low until deadline, then sharply high (cliff-shaped). Asymmetric risk justifies careful planning.
+
+**Key Practice:** Never accept a Fixed Date commitment without running a forecast against historical throughput data.
+
+### Standard (Default)
+**Purpose:** The default class for the majority of feature work and improvements — moderate cost of delay, no specific deadline.
+
+**Policy:** Pulled FIFO within this class. No pre-emption of other Standard items. Subject to normal WIP limits.
+
+**Cost of Delay Profile:** Linear — the cost accumulates steadily but is not acutely high at any specific moment.
+
+**Important:** When Standard items have homogeneous cost of delay (all roughly equivalent business value), relying solely on Standard class is preferred over adding sub-prioritization complexity. More classes add precision but increase complexity.
+
+### Intangible (Investment)
+**Purpose:** Work where the cost of delay is not visible in the near term — technical debt reduction, internal tooling, platform reliability, developer experience, training.
+
+**Policy:** Pulled last. Yielded first when higher-class items arrive. May sit in the queue for extended periods.
+
+**Cost of Delay Profile:** Appears near-zero — but chronic deferral silently accumulates the conditions that produce future Expedite emergencies.
+
+**Key Practice:** Track aging Intangible items in the Risk Review. An authentication service that hasn't been updated in 18 months is a future Expedite item in waiting.
+
+## Custom Classes
+
+Teams frequently add a fifth class:
+
+**Bugs** (software teams): Positioned between Fixed Date and Standard. Bugs have higher urgency than Standard features but rarely warrant the full Expedite response. Own SLE: "85% of Bug-class items resolve within 5 days."
+
+**Urgent** (high unplanned request volume): For teams that struggle to decompose work. Positioned between Standard and Fixed Date. Allows prioritization of small unplanned requests (e.g., content updates) without triggering Expedite policies.
+
+## Classes and Forecasting
+
+Per-class cycle time measurement produces far more reliable SLEs and Monte Carlo simulations than system-wide averages. An Expedite item completing in 4 hours and a Standard item taking 14 days must not share a cycle time distribution.
+
+Segregate data by class:
+- Standard: 85% within 14 days (derived from Standard item history)
+- Expedite: 95% within 24 hours (derived from Expedite item history)
+- Fixed Date: committed only at ≥85% Monte Carlo confidence
+
+## Board Implementation
+
+Classes are typically implemented as swimlanes (horizontal bands on the board), one per class. The class is set at intake (Replenishment) or when an incident is raised. It can be escalated (Standard → Expedite when conditions change) but should never be inflated by default.
+
+Typical priority order within the Ready queue:
+1. Expedite items first (immediate, bypasses queue)
+2. Fixed Date items (by deadline proximity)
+3. Bug class items
+4. Standard items (FIFO within portfolio allocation)
+5. Intangible items (when no higher-class work is Ready)
+
+## Cost of Delay Profiles
+
+The three cost of delay profiles map directly to classes of service:
+
+- **Linear (Standard):** Steady weekly cost of deferral — routine features
+- **Cliff (Fixed Date):** Near-zero cost until a deadline, then catastrophic — regulatory, contractual
+- **Exponential (Expedite):** Immediate spike — production incidents, active user harm
+
+**CD3** (Cost of Delay Divided by Duration) ranks work by speed of economic return, surfacing which work generates the fastest return on investment rather than merely the highest total value.

kanban-guru/references/flow-metrics.md

@@ -0,0 +1,103 @@
+# Flow Metrics in Kanban
+
+Kanban replaces story point velocity with four core flow metrics. These metrics are derived from observed system behavior, not estimates, making them more honest and more actionable.
+
+## The Four Core Metrics
+
+### 1. WIP (Work in Progress)
+The number of items that have entered the active workflow but have not yet reached Done.
+
+**How to measure:** Count the items in all active columns (Ready + In Progress + In Review, depending on board design). The CFD shows this as the vertical distance between the entry band and the Done band.
+
+**What it tells you:** Whether the team is overloaded. Rising WIP with flat throughput signals trouble — per Little's Law, cycle times are about to increase.
+
+### 2. Cycle Time (or Lead Time)
+The total time from when an item is committed (pulled into active work) to when it reaches Done.
+
+**How to measure:** For each completed item, record the date it entered active work and the date it completed. Plot on a **cycle time scatterplot** — X = completion date, Y = cycle time in days. Draw percentile lines (50th, 85th, 95th).
+
+**What it tells you:** Delivery predictability. The 85th percentile is the standard Service Level Expectation (SLE) threshold. If the 85th percentile is 14 days, then 85% of items complete within 14 days.
+
+### 3. Throughput
+The number of items completed per unit of time (typically per week).
+
+**How to measure:** Count items reaching Done each week. Track as a time-series chart. A mature team's throughput will be relatively stable over time (fluctuating within a predictable range).
+
+**What it tells you:** System capacity. Throughput is the denominator in Little's Law and the input to Monte Carlo simulations for forecasting.
+
+### 4. Flow Efficiency
+The ratio of active work time to total cycle time.
+
+**Formula:** Active Time ÷ Total Cycle Time × 100
+
+**How to measure:** Requires separating each workflow stage into active and queue states (e.g., "In Progress (active)" vs. "Ready for Review (queue)"). Active time = sum of time in active states; total cycle time = complete duration.
+
+**What it tells you:** How much of your delivery time is actually productive work vs. waiting.
+- **Typical starting range:** 1–15% (meaning 85–99% of time is waiting)
+- **Mature, optimized teams:** ~40% (considered the practical upper bound)
+
+## Service Level Expectations (SLEs)
+
+An SLE is a published, data-derived probability statement: "Based on our historical performance, 85% of Standard work items complete within 14 days of being pulled into active work."
+
+**How to derive an SLE:**
+1. Collect cycle times for all completed items in the last 10–12 weeks
+2. Filter by class of service
+3. Plot on a scatterplot
+4. Draw the 85th percentile line — this is your SLE
+
+**Why 85th percentile:** High enough to be meaningful (most items fall within it) while excluding long-tail outliers that would inflate the number to uselessness.
+
+**SLE vs. SLA vs. Sprint Commitment:**
+
+| Mechanism | What it is | Enforced how |
+|-----------|-----------|-------------|
+| **SLA** | Contracted obligation | Penalties, escalation |
+| **Sprint commitment** | Team promise | Social obligation; frequently missed |
+| **SLE** | Data-derived forecast | Continuous monitoring; transparency |
+
+SLEs replace sprint commitments. The key difference: sprint commitments are judged at sprint end with no visibility in between. SLEs are continuous — every item is monitored against the SLE daily, and approaching items are surfaced in standup before they breach.
+
+## Cumulative Flow Diagrams (CFD)
+
+The CFD is the single most information-dense chart available to a Kanban team. It simultaneously encodes WIP, cycle time, throughput, and flow health patterns.
+
+**Reading a CFD:**
+- **X-axis:** Calendar time
+- **Y-axis:** Cumulative item counts per workflow stage
+- **WIP:** Vertical distance between entry and Done bands
+- **Cycle Time:** Horizontal distance between entry and exit
+- **Throughput:** Slope of the Done band (steeper = faster delivery)
+
+**Diagnostic patterns:**
+- **Widening band:** WIP accumulating in that stage — bottleneck.
+- **Flat line:** Zero items exited that stage — complete blockage.
+- **Stair-step Done band:** Batch delivery, not continuous flow.
+- **Narrowing band:** Stage is completing faster than new items arrive — possible upstream starvation.
+- **S-curve:** Periods of zero WIP (feast-famine replenishment).
+
+## Forecasting: Individual Items
+
+Use the cycle time scatterplot. Instead of estimating how long an item will take, say:
+
+> "This item just entered Ready. Our 85th percentile for Standard items is 14 days. There's an 85% chance it completes within 14 days."
+
+No estimate required. The forecast is based on actual historical data.
+
+## Forecasting: Initiatives and Backlogs
+
+Use **Monte Carlo simulation** sampling from historical weekly throughput:
+
+> "This backlog has 30 items. Our throughput is 6–8 items per week. Monte Carlo gives us: 50% confidence by week 5, 85% by week 7, 95% by week 9."
+
+**Always give a range** — never a point estimate. Always state the confidence level. Always state the assumptions (no major incidents, stable staffing).
+
+## Right-Sizing for Reliable Forecasting
+
+Throughput-based forecasting requires consistent item sizes. If items vary from 1 day to 3 weeks, the cycle time scatterplot becomes a wide cloud and confidence intervals span months.
+
+**Right-sizing vs. Same-sizing:** Right-sizing means decomposing work to the smallest customer-valuable unit that fits within the SLE threshold — not making all items the same size. The anchor: before pulling an item, ask "are we 85% confident this will complete within our SLE?" If not, can it be sliced?
+
+**Wrong decomposition** (technical layers, no independent value at each step): "Build schema" / "Build API" / "Build frontend" — all three required before anything is evaluatable.
+
+**Right decomposition** (customer value at each step): "Users can submit the form (basic flow)" / "Connect submission to backend" / "Add validation" — each is independently evaluatable.

kanban-guru/references/glossary.md

@@ -0,0 +1,77 @@
+# Kanban Glossary
+
+## A–C
+
+**Aging Chart** — A view plotting every in-flight item by age (days in workflow) versus current stage. Items color-coded against the SLE threshold: green (within range), yellow (approaching), red (exceeded). Replaces sprint commitment as the primary accountability mechanism.
+
+**Blocker** — An impediment preventing a work item from progressing. Tracked in a blocker log with duration and root cause category. A blocker category accounting for >20% of blocked time is a systemic risk, not a one-off.
+
+**Cadence** — A recurring coordination meeting with fixed frequency, duration, participants, and purpose. Kanban defines seven cadences from daily (Standup) to quarterly (Strategy Review).
+
+**Capacity Allocation** — The percentage of a shared team's throughput earmarked for each portfolio over a planning horizon. The foundational governance mechanism for multi-portfolio Kanban. Set by leadership quarterly, tracked in Service Delivery Reviews.
+
+**CD3 (Cost of Delay Divided by Duration)** — A prioritization heuristic that ranks work by economic return speed. CD3 = Cost of Delay ÷ Duration. Higher CD3 values indicate work that should be pulled first when capacity is scarce.
+
+**CFD (Cumulative Flow Diagram)** — A stacked area chart plotting cumulative work item counts per workflow stage over time. Simultaneously encodes WIP (vertical band width), cycle time (horizontal distance through bands), and throughput (slope of Done band).
+
+**Class of Service (CoS)** — A policy framework differentiating how work items are treated based on urgency and cost of delay. Four canonical classes: Expedite, Fixed Date, Standard, Intangible. Each has distinct WIP treatment, pull sequence, and SLE.
+
+**Cost of Delay** — The economic cost of deferring a work item by one unit of time. Three profiles: Linear (steady cost), Cliff (near-zero until deadline, then catastrophic), Exponential (immediate spike).
+
+**Cycle Time** — The time from when an item enters active work (committed) to when it reaches Done. The primary delivery predictability metric. Measured per-class and expressed as percentiles (50th, 85th, 95th).
+
+## D–F
+
+**Definition of Done (DoD)** — The exit criteria for each workflow stage. Explicit conditions an item must meet before moving to the next column. Without explicit DoD, items move prematurely, creating rework and inflated cycle time.
+
+**Definition of Ready (DoR)** — The entry criteria for the Ready queue. Items that don't meet the DoR are returned for clarification before entering active work. Typical: clear problem statement, acceptance criteria, independently deliverable, right-sized.
+
+**Expedite** — The highest class of service. For work with immediate, maximum cost of delay. Bypasses WIP limits. WIP limit of 1 on the Expedite lane. Team swarms until resolved. Not "high priority" — crisis.
+
+**Explicit Policies** — The fourth core Kanban practice. Written, visible, jointly-agreed rules governing how work moves through the system. Required properties: sparse, simple, well-defined, visible, always applied, readily changeable.
+
+**Fixed Date** — A class of service for work with a specific future deadline and high cost of missing it. Requires Monte Carlo forecasting at intake. Never accept a Fixed Date commitment without running a forecast.
+
+**Flow Debt** — The accumulated cost of systematically bypassing blocked or aging items in favor of fresh, easy work. Cherry-picking feels locally rational but produces systemic slowdown as avoided items age into crises.
+
+**Flow Efficiency** — The ratio of active work time to total cycle time. Formula: Active Time ÷ Total Cycle Time × 100. Typical starting range: 1–15%. Mature optimum: ~40%. Requires separating active and queue states on the board.
+
+## I–P
+
+**Intangible** — The lowest class of service. Work with no visible near-term cost of delay: tech debt, internal tooling, platform reliability. Pulled last. Chronic deferral silently accumulates future Expedite conditions.
+
+**Kanban** — A pull-based flow management system for knowledge work. Originating in Toyota's manufacturing system, adapted for knowledge work by David J. Anderson. Governed by four core principles and six core practices.
+
+**Lead Time** — Often used interchangeably with cycle time. Some teams distinguish: lead time = time from request (backlog entry) to done; cycle time = time from commitment (pulled into active work) to done.
+
+**Little's Law** — The mathematical relationship governing flow systems: WIP = Throughput × Cycle Time. Derived from queuing theory. Explains why reducing WIP is the most reliable path to faster delivery.
+
+**Monte Carlo Simulation** — A forecasting technique that samples from historical throughput distributions to generate probability ranges for project completion dates. Replaces sprint commitment with evidence-based ranges.
+
+**Multi-Portfolio Kanban** — An operating model for shared engineering teams serving multiple product portfolios simultaneously. Uses capacity allocations, a single board, and structured cadences to replace political negotiation with policy.
+
+## P–Z
+
+**Pull System** — Work moves forward when downstream capacity exists, not when upstream is ready. Engineers take new work only when a column drops below its WIP limit, not when assigned by a manager.
+
+**Replenishment** — The cadence where work enters the Ready queue. Multi-PM intake forum. Applies capacity allocations, enforces Definition of Ready. All new work enters through Replenishment — no side-channel asks.
+
+**Right-Sizing** — Decomposing work to the smallest customer-valuable unit that fits within the SLE threshold. Distinct from same-sizing (making all items identical size). Right-sizing enables reliable throughput-based forecasting.
+
+**Service Delivery Review (SDR)** — The primary governance cadence for shared teams. Data-driven review of throughput vs. allocation, SLE adherence, blocker patterns. Where capacity allocation adjustments are debated and decided.
+
+**Side-Channel Ask** — Work requested directly to an engineer outside the board and Replenishment process. The most common failure mode in multi-portfolio governance. The fix: all work through Replenishment, no exceptions.
+
+**SLE (Service Level Expectation)** — A data-derived probability statement about delivery time: "85% of Standard items complete within 14 days." Replaces sprint commitments as the primary delivery communication mechanism.
+
+**STATIK (Systems Thinking Approach to Implementing Kanban)** — A framework for designing Kanban systems per-team rather than applying a template. Analyzes sources of dissatisfaction, demand, capability, workflow, classes of service, and metrics.
+
+**Throughput** — The number of items completed per unit time (typically per week). Kanban's replacement for velocity. Used as input to Monte Carlo simulations and SLE derivation.
+
+**Upstream Kanban** — An extension of the pull model into pre-delivery phases. The backlog is a collection of options, not commitments. Commitment happens at the latest responsible moment — when an item enters Ready.
+
+**WIP (Work in Progress)** — Items that have entered the active workflow but have not yet reached Done. The primary control variable in Kanban. Managed through WIP limits.
+
+**WIP Limit** — The maximum number of items allowed in a workflow stage simultaneously. The primary flow control mechanism. A breach is a diagnostic signal, not a prompt to raise the limit. Enforced by team agreement, not by tooling.
+
+**WIP Limit Trap** — The mistake of raising WIP limits in response to stakeholder pressure or capacity demand. Per Little's Law, this increases cycle time — making every stakeholder wait longer.

kanban-guru/references/multi-portfolio.md

@@ -0,0 +1,65 @@
+# Multi-Portfolio Kanban Operating Model
+
+When a single engineering team serves multiple product portfolios simultaneously, classic Scrum breaks down — its 1:1:1 assumption (one Product Owner, one team, one backlog) cannot handle the reality of multiple stakeholders with competing priorities. Multi-Portfolio Kanban addresses this structural failure.
+
+## Core Insight: Engineering as a Service
+
+Treat the shared engineering group not as a team juggling multiple masters, but as a **service** with multiple clients. Services have explicit capacity, published service-level expectations, governed intake processes, and regular performance reviews. The clients compete transparently for service capacity under visible, agreed rules.
+
+## Capacity Allocations
+
+Leadership sets a baseline capacity split — a percentage of throughput earmarked for each portfolio over a planning horizon (typically a quarter):
+
+| Portfolio | Allocation | Notes |
+|-----------|-----------|-------|
+| Portfolio A | 60% | Primary product line |
+| Portfolio B | 30% | Internal platform |
+| Unallocated buffer | 10% | Incidents, tech debt, unplanned |
+
+These allocations are:
+- Applied at Replenishment when deciding what enters the Ready queue
+- Tracked against actual throughput in Service Delivery Reviews
+- Adjusted through formal channels when priorities shift — not through ad hoc escalation
+
+Capacity allocations eliminate the need for stack ranking portfolios. No PM needs to "win" against another PM. Each portfolio has a guaranteed share.
+
+## Board Design
+
+One single board for all portfolios — not one per portfolio. The board is the team's operating reality and must show everything in one place.
+
+**Swimlanes** (JQL-based in Jira, or equivalent):
+- **Expedite** lane at top (WIP limit 1) — pinned above all portfolios
+- **Portfolio A** lane
+- **Portfolio B** lane
+- **Everything Else** lane — tech debt, internal work, team improvement
+
+**Columns** representing actual workflow stages:
+- Backlog (not counted in WIP)
+- Ready (committed, meets Definition of Ready)
+- In Progress (active development — WIP limited)
+- In Review (code review, QA — WIP limited)
+- Done
+
+**Card colors** by portfolio for at-a-glance allocation visibility during standup.
+
+## Cadences for Multi-Portfolio
+
+**Replenishment (1–2×/week, 30–60 min):** Replaces sprint planning. All PMs attend with the EM/TL. The team selects what enters Ready based on WIP capacity and allocation percentages. All new work enters through Replenishment — no side-channel asks to engineers.
+
+**Service Delivery Review (bi-weekly or monthly, 60–90 min):** The primary governance loop. EM/TL presents metrics by portfolio: throughput vs. allocation, lead time percentiles, blocker frequency, SLE hit rate. PMs formally assert whether their portfolio is under- or over-served. Capacity allocations are adjusted here with data, not politics.
+
+**Team Retrospective (every 2–4 weeks, 60 min):** Inward-focused. Engineers surface context-switching burden, expedite frequency, handoff friction, and replenishment quality. PMs do not attend — their concerns belong in the SDR.
+
+## Side-Channel Asks: The Most Common Failure Mode
+
+The most common failure in multi-portfolio governance is the direct ask — a PM messages an engineer directly, or a senior leader asks someone to "just squeeze this in." These asks are invisible to the board, consume real capacity, and violate allocations.
+
+**The fix:** All work enters through Replenishment. The EM/TL tells engineers: "If anyone asks you to work on something not on the board, the answer is 'please bring it to Replenishment.'" PMs are told: "I will route any direct asks back to you for submission through Replenishment."
+
+## Role Shifts
+
+**EM/TL** moves from "sprint runner" to "service owner for flow" — accountable for the Kanban system design, enforcing WIP and policies, blocking side doors, and providing range-based forecasts.
+
+**PM** moves from owning a dedicated squad to competing transparently for shared capacity. Their preparation discipline matters more: small, well-defined, high-value candidates are selected first. The primary governance lever is the Service Delivery Review, not the sprint negotiation.
+
+**CTO/CPO** sets baseline allocation splits, reviews systemic bottlenecks in Risk Reviews, and resolves allocation disputes that can't be resolved at the team level.

kanban-guru/references/transition-guide.md

@@ -0,0 +1,77 @@
+# Scrum-to-Kanban Transition Guide
+
+Moving from Scrum to Kanban is one of the most common engineering transitions, and one of the most frequently mishandled. The failure modes are consistent: misdiagnosing why Scrum isn't working, making the switch without building understanding first, or treating it as a tool swap rather than a system change.
+
+## Step 0: Diagnose First
+
+Before switching, determine whether Scrum is failing due to structural limitations or poor implementation.
+
+**Scrum is structurally the wrong fit when:**
+- The team serves multiple stakeholders with competing priorities — the 1 PO:1 team:1 backlog model breaks
+- Work is too variable in urgency and size for sprint commitments to be reliable
+- The team is a shared service for multiple product portfolios
+- Continuous delivery is expected rather than sprint-batch delivery
+
+**Scrum is being implemented poorly when:**
+- Engineers don't attend ceremonies or write acceptance criteria
+- The product owner won't make hard prioritization calls
+- Retrospectives produce no action items
+- Velocity is treated as a performance metric rather than a planning input
+
+A clean switch to Kanban will not fix poor implementation discipline. It will produce poorly implemented Kanban instead. Fix the culture first; then consider whether the method needs to change.
+
+## What to Keep, Change, and Drop
+
+### Keep
+- **Daily standup** — retained with modified format (right-to-left board walk instead of personal status)
+- **Retrospectives** — retained; focus shifts toward flow metrics and WIP health rather than sprint velocity
+- **Frequent deliveries** — if the team shipped at sprint end, keep shipping; Kanban enables continuous delivery
+- **Explicit planning** — planning doesn't disappear, it becomes more frequent and continuous via Replenishment
+
+### Replace
+
+| Scrum Practice | Kanban Equivalent |
+|---------------|-------------------|
+| Sprint planning (1 PO, 2-week scope) | Replenishment (multi-PM, 1–2×/week, capacity-allocation-based) |
+| Sprint commitment | WIP limits + SLE |
+| Sprint Review | Service Delivery Review (bi-weekly/monthly, portfolio-segmented) |
+| Sprint burndown | CFD + throughput chart |
+| Velocity (story points/sprint) | Throughput (items/week) + cycle time |
+
+### Drop
+- Sprint time boxes — no more end-of-sprint scrambles or carried-over work
+- Story points and planning poker — replaced by right-sizing at Replenishment + cycle time forecasting
+- Sprint scope commitment — replaced by WIP-based flow and SLEs
+- Velocity targets — replaced by cycle time improvement and throughput stability
+
+## The Scrumban Bridge
+
+For teams where the organizational disruption of a direct switch is too high, Scrumban is the practical bridge. It retains sprint cadences while progressively adding WIP limits and flow metrics.
+
+**Sequencing:**
+
+1. **Month 1–2:** Add WIP limits to active work columns (In Progress, In Review). Don't change ceremonies yet. Let engineers experience the pull discipline.
+2. **Month 2–3:** Add flow metrics — CFD, cycle time scatterplot. Present alongside velocity in sprint reviews. Let the team see what the data reveals.
+3. **Month 3–4:** Introduce classes of service for Expedite items. Introduce a Definition of Ready.
+4. **Month 4–6:** Replace sprint planning with Replenishment for the most variable work streams. Retain retrospective cadence.
+5. **Month 6+:** If the team has built confidence in throughput-based forecasting, drop sprint commitments and time boxes.
+
+The transition is reversible at any step. If Scrumban proves sufficient and full Kanban isn't needed, there is no obligation to continue.
+
+## Changing the Stakeholder Relationship
+
+The most psychologically challenging part is stakeholder communication. Stakeholders accustomed to "we promised Feature X in Sprint 7" will be unsettled by "Feature X has an 85% probability of delivery within 14 days."
+
+**The reframe:** "We are replacing a commitment that frequently didn't hold with a forecast that is calibrated against our actual historical performance. The forecast is honest about uncertainty in a way the sprint commitment was not."
+
+**The conversation:** "Under our Kanban model, I can't give you a hard date — but I can give you a probability. Based on our team's historical throughput and the current queue position, this feature has an 85% chance of completing by April 10. That's based on observed performance, not an estimate. If you need a harder commitment — 95% confidence — that moves to April 18. Which level of certainty do you need to plan around?"
+
+## Common Transition Failure Modes
+
+**1. Everyone-loves-Kanban honeymoon.** The first 2–3 weeks feel liberating (no sprints!). Then the board gets messy, WIP creeps up, and stakeholders realize "no sprint commitment" feels like "no commitment at all." The fix: have WIP limits and SLEs in place before removing sprint commitments.
+
+**2. Sprint planning nostalgia.** PMs keep asking for sprint-level commitments. Engineers keep volunteering dates. The fix: anchor on the SLE and range-based forecasts. Give the same answer every time: "Based on throughput, 2–3 weeks at 85% confidence."
+
+**3. Kanban-in-name-only.** Team switches the Jira project from Scrum to Kanban template but keeps working the same way — assign work in planning, commit to scope, no WIP enforcement. The fix: WIP limits that are actually enforced. A limit that is never hit is not a limit.
+
+**4. Tool-switch without behavior change.** Switching Jira board templates is not a Kanban adoption. The method is about WIP limits, pull discipline, explicit policies, and cadences — not column names in a tool.

kanban-guru/references/wip-limits.md

@@ -0,0 +1,65 @@
+# WIP Limit Calibration and Little's Law
+
+WIP limits are Kanban's primary mechanism for controlling cycle time, preventing overload, and making systemic problems visible.
+
+## Little's Law: The Mathematical Backbone
+
+**WIP = Throughput × Cycle Time**
+
+Or rearranged for practitioners: **Cycle Time = WIP ÷ Throughput**
+
+This single equation makes explicit the relationship between how much work is in flight, how fast work exits the system, and how long each item waits to be delivered.
+
+**The behavioral implication:** If throughput is roughly stable (which it is in any mature team near capacity), the only way to reduce cycle time is to reduce WIP. Adding more work in flight — expanding WIP limits under stakeholder pressure — produces longer wait times, not faster delivery.
+
+## Setting Initial WIP Limits
+
+The most reliable starting point is a team conversation, not a formula. Ask the team: **"What number of items in progress feels comfortable? Where you're busy and engaged but not overwhelmed?"**
+
+That answer is the initial WIP limit. Treat it as a hypothesis — set it, observe for 2–4 weeks, read the CFD, and adjust.
+
+**Structural principles:**
+- WIP limits apply to **activities** (workflow stages), not to roles or people
+- Columns should represent **activities**, not specialties
+- A common starting heuristic for active work columns: `team_size × 1.5`
+- Initial limits for In Review typically match or are slightly lower than In Progress
+
+## WIP Limit Breaches as Diagnostic Signals
+
+A WIP limit breach is not a prompt to raise the limit — it is an alarm mechanism. When the limit is hit, the correct question is "why are we at the limit?"
+
+Common causes of breaches:
+- **Items too large** — big items sit in a stage too long, blocking the limit for smaller items behind them. Fix: smaller slices.
+- **Bottleneck downstream** — items pile up waiting for the next stage because that stage can't absorb them. Fix: increase throughput at the bottleneck, not the WIP limit upstream.
+- **Expedite overuse** — frequent emergency items push over the limit. Fix: tighten expedite criteria or increase the unplanned buffer.
+- **External dependencies** — blocked items count against WIP but aren't consuming active capacity. Fix: track blocked items explicitly and consider excluding them from active WIP counts.
+
+## The Little's Law Trap
+
+Adding more WIP in response to stakeholder pressure is the most common WIP calibration mistake. It feels like responsiveness, but Little's Law guarantees it produces slower cycle times.
+
+**Example:** If throughput is stable at 10 items/week and WIP rises from 20 to 30, average cycle time increases from 2 weeks to 3 weeks. Every stakeholder now waits 50% longer.
+
+**The counterintuitive move:** When cycle times are too long, reduce WIP. Finish current work first. The items most urgently needed will reach Done faster because they have a shorter queue to wait behind.
+
+## When to Legitimately Adjust WIP Limits
+
+**Legitimate reasons to increase:**
+- Team has grown (new engineers added)
+- A chronic blocker category has been resolved
+- Retrospective data shows the team is consistently under the limit with low cycle times
+
+**Legitimate reasons to decrease:**
+- Cycle times are rising
+- The CFD shows WIP widening in a stage
+- Team composition has changed (members departed)
+- The team identifies cherry-picking behavior during retros
+
+## Little's Law for Bottleneck Identification
+
+Applied per workflow stage, Little's Law becomes a diagnostic tool:
+1. Calculate the average items in each stage (in-stage WIP)
+2. Calculate the average items exiting per week (throughput out of that stage)
+3. Divide: **in-stage Cycle Time = WIP ÷ Throughput**
+
+The stage with the longest in-stage cycle time is the bottleneck. It is not necessarily the stage with the most items — it is the stage where WIP accumulates faster than items exit. This is visible in the CFD as a widening band.