Getting Started with Kanban | WIP & Flow

Implement Kanban with continuous flow, WIP limits, and visual boards. GitScrum provides swimlanes, flow metrics, and analytics for continuous improvement.

5 min read

Kanban emphasizes visualizing work, limiting work in progress, and optimizing flow for continuous delivery. GitScrum's customizable boards with WIP limits, swimlanes, and flow metrics make implementing Kanban straightforward while providing the analytics needed to continuously improve team performance.

Kanban Core Principles

Principle	What It Means	Benefit
Visualize Work	See all work on board	Transparency
Limit WIP	Cap items per stage	Focus, flow
Manage Flow	Optimize throughput	Predictability
Make Policies Explicit	Clear rules	Consistency
Improve Continuously	Evolve process	Better over time

Setting Up Your Kanban Board

BASIC KANBAN BOARD SETUP

     Backlog   │  To Do   │  In Progress  │  Review   │  Done
     (no limit)│   (10)   │      (5)      │    (3)    │  (∞)
    ───────────┼──────────┼───────────────┼───────────┼────────
               │          │               │           │
    [Feature A]│[Feature B]│ [Feature D]   │[Feature F]│[Done 1]
    [Bug 1]    │[Bug 2]   │ [Bug 3]       │           │[Done 2]
    [Feature C]│[Task 1]  │               │           │[Done 3]
    [Task 2]   │          │               │           │
    [Task 3]   │          │               │           │
               │          │               │           │

    ← Pull from left │ WIP Limit enforced │ Completed →

Column Design

RECOMMENDED COLUMNS FOR DEV TEAMS

SIMPLE (Start here):
┌─────────────────────────────────────────────────┐
│ Backlog → To Do → In Progress → Done            │
└─────────────────────────────────────────────────┘

STANDARD:
┌─────────────────────────────────────────────────┐
│ Backlog → Ready → Dev → Review → Test → Done    │
└─────────────────────────────────────────────────┘

WITH EXPLICIT WAITING:
┌─────────────────────────────────────────────────┐
│ Backlog → Ready → Dev → [Waiting] → Review →    │
│                                  → Test → Done   │
│                                                 │
│ [Waiting] columns expose blockers               │
└─────────────────────────────────────────────────┘

SPLIT COLUMNS (Doing/Done):
┌─────────────────────────────────────────────────┐
│           Dev          │        Review          │
│  ┌─────────┬─────────┐ │ ┌─────────┬─────────┐  │
│  │ Active  │ Review  │ │ │ Review  │ Approved│  │
│  │         │ Ready   │ │ │         │         │  │
│  └─────────┴─────────┘ │ └─────────┴─────────┘  │
│                        │                        │
│  "Done" = ready for    │  Visual handoff        │
│  next stage to pull    │  within stages         │
└─────────────────────────────────────────────────┘

WIP Limit Strategy

SETTING WIP LIMITS

Step 1: Count team members actively working
Step 2: Set WIP limit per stage

FORMULA (starting point):
┌─────────────────────────────────────────────────┐
│  In Progress WIP = Team Size × 1.5              │
│                                                 │
│  Example: 4 developers                          │
│  In Progress limit: 6 items                     │
│  Review limit: 3 items                          │
└─────────────────────────────────────────────────┘

TOO HIGH (no effect):
┌─────────────────────────────────────────────────┐
│  Everyone has 5 items → constant switching      │
│  No pain → no improvement signal                │
└─────────────────────────────────────────────────┘

TOO LOW (blocking):
┌─────────────────────────────────────────────────┐
│  People idle waiting for capacity               │
│  Artificial bottlenecks                         │
└─────────────────────────────────────────────────┘

JUST RIGHT:
┌─────────────────────────────────────────────────┐
│  Slight pressure to finish before starting      │
│  Bottlenecks visible and addressed              │
│  Flow is smooth                                 │
└─────────────────────────────────────────────────┘

ADJUST: If WIP limit rarely hit → lower it
        If always blocked → investigate why

Kanban Metrics

KEY METRICS TO TRACK

LEAD TIME
┌─────────────────────────────────────────────────┐
│  Time from request to delivery                  │
│  Example: 8 days average                        │
│  Goal: Reduce or stabilize                      │
└─────────────────────────────────────────────────┘

CYCLE TIME
┌─────────────────────────────────────────────────┐
│  Time from work started to done                 │
│  Example: 3 days average                        │
│  Goal: Reduce                                   │
└─────────────────────────────────────────────────┘

THROUGHPUT
┌─────────────────────────────────────────────────┐
│  Items completed per time period                │
│  Example: 12 items/week                         │
│  Goal: Increase or stabilize                    │
└─────────────────────────────────────────────────┘

CUMULATIVE FLOW DIAGRAM
┌─────────────────────────────────────────────────┐
│  Visual of items in each stage over time        │
│  Flat areas = stuck work                        │
│  Bulges = bottlenecks                           │
└─────────────────────────────────────────────────┘

Best Practices

Start with current workflow don't invent

Set WIP limits from day one even if generous

Prioritize finishing over starting new work

Address bottlenecks when they appear

Use swimlanes for work types (bug, feature)

Have regular replenishment meetings

Track cycle time to measure improvement

Evolve gradually based on data

Anti-Patterns

✗ No WIP limits (just a to-do list)
✗ Pushing work instead of pulling
✗ Ignoring blocked items
✗ WIP limits that never get hit
✗ No regular review of flow metrics
✗ Treating board as status report only