Kanban for Continuous Flow
When Scrum Does Not Fit
Not every team uses Scrum. Kanban is an alternative that works well for teams with a continuous flow of work rather than time-boxed sprints. Maintenance teams, DevOps teams, and support-focused QA teams often find Kanban more natural than Scrum.
Core Kanban Concepts
Visual Board
Work items move through columns representing workflow stages. Everyone can see the state of all work at a glance.
| To Do | In Progress | In Review | Testing | Done |
|----------|-------------|-----------|-----------|-----------|
| SHOP-901 | SHOP-789 | SHOP-654 | SHOP-456 | SHOP-321 |
| SHOP-902 | | | SHOP-457 | SHOP-322 |
| SHOP-903 | | | | SHOP-323 |
| | | | | SHOP-324 |
WIP Limits
WIP (Work in Progress) limits restrict the number of items in each column. This is the most important and most counterintuitive principle in Kanban.
| To Do | In Progress (3) | In Review (2) | Testing (3) | Done |
| | WIP limit: 3 | WIP limit: 2 | WIP limit: 3 | |
If the Testing column has a WIP limit of 3 and there are already 3 items there, no new items can move in until one moves out. This prevents QA from being overwhelmed and forces the team to help unblock testing before starting new work.
Why WIP Limits Work
Without WIP limits:
- Developers start 10 features simultaneously
- 10 half-finished features pile up in "Testing"
- QA cannot keep up
- Everything is "in progress," nothing is "done"
- Context-switching kills productivity for everyone
With WIP limits:
- Developers finish features before starting new ones
- Items flow through the board steadily
- If testing is backed up, developers help with test automation or bug investigation
- The team finishes work instead of starting work
Pull System
In Kanban, QA pulls the next item when they have capacity, rather than being pushed work by developers. This means QA can prioritize what to test based on risk and business value, not on who finishes coding first.
Lead Time and Cycle Time
| Metric | What It Measures | Why It Matters |
|---|---|---|
| Lead time | Time from item creation to completion | How long customers wait for features |
| Cycle time | Time from work starting to completion | How long items are actively being worked on |
| Throughput | Items completed per time period | Team capacity and predictability |
QA in Kanban
Testing as a Column, Not a Phase
In Kanban, testing is a column on the board. If items pile up in the Testing column, the team has a bottleneck. The solution is not "hire more QA" -- it is for the team to swarm and help.
What "swarming" looks like:
- Developers write automated tests for their features
- Developers investigate failed tests and fix root causes
- PO helps verify business logic during exploratory testing
- The team focuses on finishing existing work before starting new work
Continuous Testing
Without sprint boundaries, testing must be continuous. There is no "end of sprint regression" -- tests run on every change, and quality is validated continuously.
Implications for QA:
- CI pipeline must be fast and reliable (no stabilization period)
- Automated regression must be comprehensive (no manual regression sprint)
- Test environments must always be ready
- Monitoring replaces periodic testing (production quality is measured continuously)
Kanban vs Scrum: A QA Comparison
| Aspect | Scrum | Kanban |
|---|---|---|
| Time structure | Fixed-length sprints (1-4 weeks) | Continuous flow |
| Planning | Sprint planning at sprint start | Prioritize backlog continuously |
| Testing rhythm | Testing within sprint, regression at end | Continuous testing on every item |
| Quality gates | DoD checked at sprint review | DoD checked when item moves to "Done" |
| Metrics | Velocity (points per sprint) | Lead time, cycle time, throughput |
| Improvement | Sprint retrospective | Continuous improvement, periodic reviews |
| Best for QA when | Features are batched, regression makes sense | Work is continuous, items are independent |
Implementing Kanban for QA
Step 1: Design Your Board
Start with a simple board and add columns as needed:
Basic: To Do → In Progress → Done
Better: To Do → In Progress → In Review → Testing → Done
Best: Backlog → Ready → In Dev → Code Review → QA Testing → Staging → Done
Step 2: Set WIP Limits
Start with generous limits and tighten over time:
| Column | Starting WIP | Mature WIP |
|---|---|---|
| In Progress | Team size | Team size / 2 |
| In Review | 3 | 2 |
| Testing | 4 | 2-3 |
Step 3: Measure Lead Time
Track how long items take from start to finish. Look for:
- Items that get stuck in "Testing" (bottleneck)
- Items that bounce between "In Progress" and "Testing" (quality issues)
- Items with very long lead times (complexity or blocking issues)
Step 4: Optimize Flow
- If Testing is the bottleneck, add more automation or have developers help with testing
- If Code Review is the bottleneck, pair-program instead of async review
- If items bounce back from Testing, invest in better requirements (three amigos)
Kanban Metrics Dashboard
Team Kanban Metrics (Last 30 Days)
──────────────────────────────────
Average Lead Time: 4.2 days (target: < 5 days)
Average Cycle Time: 2.8 days
Throughput: 12 items/week
Testing Bottleneck: 3 items waiting > 2 days this month
WIP Violations: 2 this month (both in Testing column)
Top Bottleneck: Testing (average wait: 1.4 days)
Action: Developer-written automation for standard flows
Hands-On Exercise
- Set up a Kanban board for your team's QA work (physical or digital)
- Add WIP limits to each column. Start generous and tighten over 2 weeks.
- Track lead time for 10 items. Where do items spend the most time?
- Identify your biggest bottleneck and propose a solution (automation, swarming, process change)
- Compare your team's rhythm: would Kanban or Scrum work better? Why?