Try free
5 min read Guide 523 of 877

How to Use Kanban for IT Operations

IT operations teams face constant interruptions from incidents, user requests, and maintenance tasks. GitScrum's Kanban boards with WIP limits, swimlanes for work types, and SLA tracking help ops teams manage flow, maintain service levels, and avoid the chaos of unmanaged work queues.

IT Operations Work Types

Work TypePriorityFlow Treatment
P1 IncidentsImmediateExpedite lane
P2 IncidentsSame dayHigh priority
Service requestsNormalStandard flow
MaintenancePlannedScheduled
ImprovementsLowWhen capacity allows

IT Operations Kanban Board

IT OPERATIONS BOARD STRUCTURE

┌─────────────────────────────────────────────────────────────────────┐
│  EXPEDITE (P1 Incidents) - No WIP Limit                            │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ [INC-234] Production database unresponsive                  │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

┌─────────┬──────────┬──────────┬──────────┬──────────┬─────────────┐
│ Backlog │ Ready    │ Working  │ Review   │ Deploy   │ Done        │
│ (no WIP)│ (WIP: 3) │ (WIP: 4) │ (WIP: 2) │ (WIP: 2) │ (no WIP)    │
├─────────┼──────────┼──────────┼──────────┼──────────┼─────────────┤
│ [REQ]   │ [INC]    │ [INC]    │ [CHG]    │ [CHG]    │ [INC] ✓     │
│ [REQ]   │ [REQ]    │ [CHG]    │          │          │ [REQ] ✓     │
│ [CHG]   │          │ [REQ]    │          │          │ [CHG] ✓     │
│ [CHG]   │          │          │          │          │             │
│ [IMP]   │          │          │          │          │             │
└─────────┴──────────┴──────────┴──────────┴──────────┴─────────────┘

SWIMLANES BY WORK TYPE:
┌─────────────────────────────────────────────────────────────────────┐
│ 🔴 Incidents (P2-P3)                                               │
├─────────────────────────────────────────────────────────────────────┤
│ 📋 Service Requests                                                 │
├─────────────────────────────────────────────────────────────────────┤
│ 🔧 Changes & Maintenance                                            │
├─────────────────────────────────────────────────────────────────────┤
│ 📈 Improvements                                                     │
└─────────────────────────────────────────────────────────────────────┘

Work Item Types

WORK ITEM DEFINITIONS

INCIDENT (INC):
┌─────────────────────────────────────────────────┐
│  Unplanned service disruption                   │
│  Goal: Restore service ASAP                     │
│                                                 │
│  Fields:                                        │
│  ├── Priority (P1-P4)                           │
│  ├── Affected service                           │
│  ├── Impact (users affected)                    │
│  ├── Start time                                 │
│  └── Resolution time                            │
│                                                 │
│  SLAs:                                          │
│  P1: Response <15 min, Resolve <4 hours         │
│  P2: Response <1 hour, Resolve <8 hours         │
│  P3: Response <4 hours, Resolve <24 hours       │
│  P4: Response <1 day, Resolve <1 week           │
└─────────────────────────────────────────────────┘

SERVICE REQUEST (REQ):
┌─────────────────────────────────────────────────┐
│  Standard user request                          │
│  Goal: Fulfill per SLA                          │
│                                                 │
│  Fields:                                        │
│  ├── Request type                               │
│  ├── Requester                                  │
│  ├── Due date                                   │
│  └── Approval status                            │
│                                                 │
│  Examples: Access request, new account,         │
│  software install, hardware request             │
└─────────────────────────────────────────────────┘

CHANGE (CHG):
┌─────────────────────────────────────────────────┐
│  Planned infrastructure modification            │
│  Goal: Implement safely                         │
│                                                 │
│  Fields:                                        │
│  ├── Change type (standard/normal/emergency)    │
│  ├── Risk level                                 │
│  ├── Rollback plan                              │
│  ├── Change window                              │
│  └── CAB approval                               │
└─────────────────────────────────────────────────┘

IMPROVEMENT (IMP):
┌─────────────────────────────────────────────────┐
│  Proactive enhancement                          │
│  Goal: Improve operations                       │
│                                                 │
│  Examples: Automation, monitoring,              │
│  documentation, process improvement             │
└─────────────────────────────────────────────────┘

Capacity Planning

OPS TEAM CAPACITY MODEL

TEAM: 5 engineers

CAPACITY ALLOCATION:
┌─────────────────────────────────────────────────┐
│  Incident response:     1-2 engineers (20-40%)  │
│  (rotates daily)                                │
│                                                 │
│  Planned work:          3-4 engineers (60-80%)  │
│  ├── Service requests                           │
│  ├── Changes                                    │
│  └── Improvements                               │
└─────────────────────────────────────────────────┘

WIP LIMITS RATIONALE:
┌─────────────────────────────────────────────────┐
│  Ready: 3                                       │
│  └── Half day's worth of prepared work          │
│                                                 │
│  Working: 4                                     │
│  └── Less than team size (5) for focus          │
│                                                 │
│  Review: 2                                      │
│  └── Minimize approval bottleneck               │
│                                                 │
│  Deploy: 2                                      │
│  └── Control change velocity                    │
└─────────────────────────────────────────────────┘

Flow Metrics

IT OPS METRICS DASHBOARD

FLOW METRICS:
┌─────────────────────────────────────────────────┐
│  Cycle Time (avg days):                         │
│  Incidents P2: 0.5 days     Target: <1    ✓     │
│  Requests: 3.2 days         Target: <5    ✓     │
│  Changes: 5.1 days          Target: <7    ✓     │
│  Improvements: 12 days      Target: <14   ✓     │
└─────────────────────────────────────────────────┘

THROUGHPUT:
┌─────────────────────────────────────────────────┐
│  This Week:                                     │
│  Incidents resolved: 8                          │
│  Requests fulfilled: 15                         │
│  Changes deployed: 6                            │
│  Improvements done: 2                           │
└─────────────────────────────────────────────────┘

SERVICE LEVELS:
┌─────────────────────────────────────────────────┐
│  SLA Compliance:                                │
│  P1 Incidents: 100% (2/2 met)          ✓        │
│  P2 Incidents: 95% (19/20 met)         ✓        │
│  Service Requests: 92% (46/50 met)     ⚠        │
└─────────────────────────────────────────────────┘

Best Practices

  1. Use expedite lane for true emergencies only
  2. Set WIP limits based on team size
  3. Track cycle time by work type
  4. Reserve incident capacity daily
  5. Visualize all work including improvements
  6. Review blocked items in standups
  7. Measure SLA compliance continuously
  8. Conduct regular retrospectives for flow improvement

Anti-Patterns

✗ No WIP limits (everything in progress)
✗ Expedite lane for all incidents
✗ Hidden work not on board
✗ No time for improvements
✗ Ignoring blocked items
✗ No metrics on flow