Try free
5 min read Guide 485 of 877

Getting Started with Kanban

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

PrincipleWhat It MeansBenefit
Visualize WorkSee all work on boardTransparency
Limit WIPCap items per stageFocus, flow
Manage FlowOptimize throughputPredictability
Make Policies ExplicitClear rulesConsistency
Improve ContinuouslyEvolve processBetter 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

  1. Start with current workflow don't invent
  2. Set WIP limits from day one even if generous
  3. Prioritize finishing over starting new work
  4. Address bottlenecks when they appear
  5. Use swimlanes for work types (bug, feature)
  6. Have regular replenishment meetings
  7. Track cycle time to measure improvement
  8. 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