7 min read • Guide 671 of 877
Implementing Kanban for Development Teams
Kanban provides a flexible framework for managing development work with minimal process overhead. GitScrum's Kanban boards help teams visualize their workflow, identify bottlenecks, and continuously improve their process through flow optimization.
Kanban Fundamentals
Core Principles
KANBAN PRINCIPLES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. VISUALIZE WORK │
│ Make all work visible on the board │
│ Include work type, status, blockers │
│ │
│ 2. LIMIT WORK IN PROGRESS (WIP) │
│ Focus on finishing, not starting │
│ WIP limits create flow │
│ │
│ 3. MANAGE FLOW │
│ Optimize for smooth, predictable delivery │
│ Measure and improve cycle time │
│ │
│ 4. MAKE POLICIES EXPLICIT │
│ Document how work moves through columns │
│ Define "ready" and "done" for each stage │
│ │
│ 5. IMPLEMENT FEEDBACK LOOPS │
│ Regular reviews of work and process │
│ Adapt based on metrics and experience │
│ │
│ 6. IMPROVE COLLABORATIVELY │
│ Team owns the process │
│ Continuous, evolutionary change │
└─────────────────────────────────────────────────────────────┘
Kanban vs Scrum
KANBAN CHARACTERISTICS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ KANBAN: SCRUM: │
│ • Continuous flow • Time-boxed sprints │
│ • WIP limits • Sprint commitment │
│ • Pull-based • Push at sprint planning │
│ • Change anytime • Change at sprint boundary │
│ • Roles optional • Defined roles │
│ • Metrics: cycle time • Metrics: velocity │
│ │
│ CHOOSE KANBAN WHEN: │
│ • Work is unpredictable (support, ops) │
│ • Continuous deployment needed │
│ • Team handles varied work types │
│ • Frequent priority changes │
│ • Minimal process overhead preferred │
│ │
│ CHOOSE SCRUM WHEN: │
│ • Work is plannable │
│ • Team needs structure │
│ • Stakeholders want predictable commitments │
│ • Building complex features iteratively │
└─────────────────────────────────────────────────────────────┘
Implementation Steps
Step 1: Map Your Workflow
WORKFLOW MAPPING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DISCOVER YOUR ACTUAL PROCESS: │
│ │
│ Ask: "What states does work go through?" │
│ │
│ Example discovery: │
│ 1. Someone requests work │
│ 2. Product reviews and prioritizes │
│ 3. Work waits for availability │
│ 4. Developer picks it up │
│ 5. Developer completes coding │
│ 6. Work goes to code review │
│ 7. Review comments addressed │
│ 8. QA tests the work │
│ 9. Work deployed to staging │
│ 10. Work released to production │
│ │
│ MAP TO COLUMNS: │
│ Backlog → Ready → In Progress → Review → QA → Done │
│ │
│ TIP: Start simple, add columns as needed │
└─────────────────────────────────────────────────────────────┘
Step 2: Set Initial WIP Limits
INITIAL WIP LIMITS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEAM SIZE: 5 developers + 1 QA │
│ │
│ COLUMN │ INITIAL WIP │ REASONING │
│─────────────────┼─────────────┼───────────────────────────│
│ Backlog │ None │ Prioritized queue │
│ Ready │ 8 │ Buffer for planning │
│ In Progress │ 5 │ One per developer max │
│ Code Review │ 4 │ Encourages finishing │
│ QA Testing │ 3 │ QA capacity │
│ Done │ None │ Completed work │
│ │
│ TOTAL SYSTEM WIP: ~20 items │
│ │
│ ADJUST AFTER 2-4 WEEKS: │
│ Too easy? Lower limits. │
│ Constantly blocked? Raise slightly. │
└─────────────────────────────────────────────────────────────┘
Step 3: Establish Policies
EXPLICIT POLICIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COLUMN: READY │
│ Entry criteria: │
│ • User story with acceptance criteria │
│ • Design approved (if needed) │
│ • Dependencies identified │
│ Exit criteria: │
│ • Developer pulls when capacity available │
│ │
│ COLUMN: IN PROGRESS │
│ Entry criteria: │
│ • Pulled from Ready │
│ • Developer assigned │
│ Exit criteria: │
│ • Code complete with tests │
│ • PR created │
│ │
│ COLUMN: CODE REVIEW │
│ Entry criteria: │
│ • PR created with description │
│ • CI passing │
│ Exit criteria: │
│ • Approved by reviewer │
│ • Comments addressed │
│ │
│ PRIORITIZATION: │
│ • Finish work in progress before starting new │
│ • Help unblock others before starting own work │
│ • Critical bugs may bypass normal queue │
└─────────────────────────────────────────────────────────────┘
Daily Operations
Daily Standup
KANBAN STANDUP (15 min):
┌─────────────────────────────────────────────────────────────┐
│ │
│ FOCUS: Walk the board right-to-left │
│ │
│ 1. Start from DONE, move left │
│ "What moved to done since yesterday?" │
│ │
│ 2. Review items close to DONE first │
│ "What's blocking these from finishing?" │
│ │
│ 3. Check WIP limits │
│ "Are we at or over any limits?" │
│ │
│ 4. Address blockers │
│ "Who can help unblock this?" │
│ │
│ 5. Pull new work only if capacity │
│ "Do we have room to start anything new?" │
│ │
│ WHY RIGHT-TO-LEFT: │
│ Prioritizes finishing over starting │
│ Items closer to done = more investment │
│ Reveals blockers in later stages │
└─────────────────────────────────────────────────────────────┘
Handling Work Types
WORK TYPE MANAGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SWIMLANES BY WORK TYPE: │
│ │
│ URGENT │ ■ Critical bug │
│ (expedite) │ │
│──────────────┼──────────────────────────────────────────────
│ FEATURES │ □ #125 ■ #123 ■ #120 │
│ │ □ #126 ■ #124 │
│──────────────┼──────────────────────────────────────────────
│ BUGS │ □ #45 ■ #43 │
│ │ │
│──────────────┼──────────────────────────────────────────────
│ TECH DEBT │ □ #TD-12 │
│ │ │
└──────────────┴──────────────────────────────────────────────┘
CAPACITY ALLOCATION:
• Features: 60%
• Bugs: 20%
• Tech Debt: 20%
Track each lane separately, maintain ratios
Metrics and Improvement
Flow Metrics
KEY KANBAN METRICS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CYCLE TIME (primary metric): │
│ Time from "In Progress" to "Done" │
│ Current avg: 3.2 days │
│ Target: <3 days │
│ │
│ LEAD TIME: │
│ Time from "Ready" to "Done" │
│ Current avg: 5.1 days │
│ Shows total time including wait │
│ │
│ THROUGHPUT: │
│ Items completed per time period │
│ Current: 14 items/week │
│ Trend: Stable │
│ │
│ WIP AGE: │
│ How long items have been in progress │
│ Alert if item > 2x average cycle time │
│ │
│ CUMULATIVE FLOW DIAGRAM: │
│ Shows work volume in each state over time │
│ Widening bands = bottlenecks │
└─────────────────────────────────────────────────────────────┘
Continuous Improvement
KANBAN IMPROVEMENT CYCLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WEEKLY: Board Review (15 min) │
│ • Check metrics │
│ • Identify stuck items │
│ • Note patterns │
│ │
│ BI-WEEKLY: Process Review (30 min) │
│ • Review flow metrics │
│ • Discuss bottlenecks │
│ • Adjust WIP limits if needed │
│ • Update policies │
│ │
│ IMPROVEMENT EXPERIMENTS: │
│ │
│ "Hypothesis: Lowering Review WIP from 4 to 3 │
│ will reduce review wait time." │
│ │
│ Try for: 2 weeks │
│ Measure: Review stage cycle time │
│ Decide: Keep, adjust, or revert │
└─────────────────────────────────────────────────────────────┘