Skip to main content

codexkit-kanban-flow-analyzer

Analyze Kanban flow metrics to identify bottlenecks and improve team throughput. Covers Cycle Time, Throughput, WIP, and Flow Efficiency using Little's Law and Theory of Constraints. Use when a team wants to optimize delivery flow or improve predictability. Do not use for sprint-based Scrum planning — use sprint-planning-assistant instead.

Source facts

Repository
hoavdc/CodexKit
Last source activity
March 22, 2026 at 17:03
Detected SKILL.md language
English
Stars
26
Forks
12

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
codexkit-kanban-flow-analyzer
description
Analyze Kanban flow metrics to identify bottlenecks and improve team throughput. Covers Cycle Time, Throughput, WIP, and Flow Efficiency using Little's Law and Theory of Constraints. Use when a team wants to optimize delivery flow or improve predictability. Do not use for sprint-based Scrum planning — use sprint-planning-assistant instead.
version
1.0.0
category
data
# Kanban Flow Analyzer ## Purpose Transform raw task completion data into actionable flow insights — find bottlenecks, set WIP limits, and forecast delivery dates with confidence intervals. ## When to use - team wants to reduce cycle time or improve delivery predictability - WIP is growing and tasks are stalling in certain board columns - management asks "when will this be done?" and the team has no data-driven answer - transitioning from time-boxed sprints to continuous flow ## When not to use - sprint planning with story points (use sprint-planning-assistant) - strategic roadmap or portfolio prioritization - teams with fewer than 4 weeks of historical data ## Inputs - task data with start date and completion date (minimum 4 weeks history) - board column names and WIP limits (if any) - team size and working days per week - specific questions or concerns about flow ## Procedure 1. **Calculate 4 core flow metrics**: - **Cycle Time**: days from "In Progress" to "Done" — report P50 (median) and P85 - **Throughput**: items completed per week — report average and trend - **WIP**: items currently in progress — compare to team capacity - **Flow Efficiency**: (active work time / total elapsed time) × 100% - Typical: 15–25% | High-performing: > 40% 2. **Apply Little's Law**: Cycle Time = WIP ÷ Throughput - If cycle time is high but throughput is stable, WIP is too high 3. **Detect bottlenecks** using Theory of Constraints (5 Focusing Steps): - Identify the column with highest average queue time - Exploit: maximize throughput at the constraint - Subordinate: slow upstream to match constraint capacity - Elevate: add capacity or change process at constraint - Repeat: new constraint will emerge 4. **Set WIP limits**: initial recommendation = team size × 1.5 per column, then adjust based on data. 5. **Forecast delivery** using Monte Carlo simulation: - "If avg throughput = 12 items/week, 60-item backlog takes ~5 weeks at P85 confidence" ## Output - flow metrics dashboard (Cycle Time, Throughput, WIP, Flow Efficiency) - bottleneck analysis with identified constraint and root cause - WIP limit recommendations per board column - top 3 actionable improvements with expected impact - Monte Carlo forecast (items by date at P50, P85, P95 confidence) ## Definition of done - all 4 flow metrics are calculated and reported - at least one bottleneck is identified with a root cause - WIP limit recommendations are provided - forecast includes at least P85 confidence level ## Examples - "Analyze our Jira board data for the last 8 weeks — why are tasks stuck in Code Review?" - "Our cycle time went from 5 days to 12 days. What happened?" - "Set WIP limits for a 7-person team with columns: To Do, In Progress, Review, QA, Done." ## Quality Criteria - [ ] Data sources and assumptions are explicitly stated - [ ] Calculations are reproducible from provided inputs - [ ] Visualizations or tables have clear labels, units, and time ranges - [ ] Caveats and confidence levels are documented for estimates ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Are formulas, aggregations, and statistical methods applied correctly? | | **Completeness** | Does the analysis cover all requested metrics and time ranges? | | **Context-fit** | Are the chosen metrics relevant to the business question being answered? | | **Consequence** | If this data were used for a decision today, what blind spots remain? | ## Edge Cases - **Missing or incomplete data** — Document gaps and their potential impact on conclusions. Provide ranges instead of point estimates. - **Outliers skewing results** — Report with and without outliers. Document the decision to include or exclude. - **Changing data definitions mid-period** — Split analysis at the change boundary and note the schema difference. ## Changelog - v1.0.0 — Initial release
View on GitHub