What Is Kanban?
Kanban is an agile methodology based on visualizing work, limiting work in progress, and optimizing flow. Unlike Scrum, Kanban does not use time-boxed sprints. Instead, work items flow continuously through a series of stages from “To Do” to “Done.”
The word “Kanban” comes from Japanese and means “visual signal” or “card.” The methodology originated in Toyota’s manufacturing system in the 1940s and was adapted for software development by David J. Anderson in the 2000s.
For QA engineers, Kanban offers a fundamentally different way of working compared to Scrum. Understanding both helps you adapt to any team environment.
Core Kanban Principles
1. Visualize the Workflow
Everything the team is working on is visible on the Kanban board. Each card represents a work item, and its position on the board shows its current status.
2. Limit Work in Progress (WIP)
Each column on the board has a maximum number of items allowed. This is the WIP limit. When a column is full, no new items can enter until existing ones move forward.
3. Manage Flow
The goal is smooth, predictable flow of work through the system. Blocked items, bottlenecks, and long queues are signals that something needs attention.
4. Make Policies Explicit
Rules for moving items between columns are written down and visible. For example: “An item can only move to ‘Testing’ when a developer marks it as code-complete and unit tests pass.”
5. Implement Feedback Loops
Regular meetings (standups, reviews, retrospectives) provide feedback on how the process is working.
6. Improve Collaboratively
The team continuously looks for ways to improve the workflow based on data (cycle time, lead time, throughput).
The Kanban Board with QA
A Kanban board for a software team with dedicated QA activities looks like this:
Key QA columns:
| Column | WIP Limit | QA Role |
|---|---|---|
| Backlog | None | Review upcoming items for testability |
| Analysis | 3 | Clarify acceptance criteria, identify test approach |
| Development | 4 | Prepare test cases, set up test data |
| Code Review | 2 | Review test coverage in code reviews |
| QA Testing | 3 | Execute functional, regression, and exploratory testing |
| UAT | 2 | Support user acceptance testing, verify fixes |
| Done | None | Verify all quality criteria are met |
WIP Limits and Why They Matter for QA
WIP limits are the heart of Kanban. Without them, you just have a fancy to-do list.
How WIP Limits Prevent QA Bottlenecks
Consider this scenario without WIP limits:
- Developers complete 8 features in a week
- QA can test 4 features in a week
- The QA Testing column grows by 4 items every week
- After a month, QA has a backlog of 16 untested features
This is a bottleneck. Work piles up before QA, and the team’s overall throughput is limited by the testing capacity.
With WIP limits:
- The QA Testing column has a WIP limit of 3
- When 3 items are in testing, developers cannot push more items into Code Review
- This forces developers to either help with testing, fix bugs, or improve test automation
- The bottleneck becomes visible immediately, not after a month
Key insight: WIP limits do not slow down the team. They reveal where the team is already slow. If the QA column is always full, the team needs more testing capacity — not a higher WIP limit.
Setting the Right WIP Limit for QA
A good starting point for your QA Testing column WIP limit:
| Team Size | QA Engineers | Suggested WIP Limit |
|---|---|---|
| 3-5 people | 1 QA | 2-3 items |
| 5-8 people | 2 QA | 3-4 items |
| 8-12 people | 3 QA | 4-5 items |
Start conservative and adjust based on data. If the QA column is rarely full, lower the limit. If items frequently wait before QA, the limit might be right but you need more capacity.
Flow-Based Testing
In Kanban, testing is not a phase — it is part of the flow. This means:
Test When Ready, Not on Schedule
In Scrum, testing happens within a sprint. In Kanban, you test an item as soon as it enters the QA Testing column. There is no “sprint end” deadline pushing you to rush.
Focus on One Item at a Time
With WIP limits, you focus on fewer items simultaneously. This reduces context switching and improves test quality. Testing one feature thoroughly is better than testing three features superficially.
Pull, Don’t Push
QA pulls work from the Code Review column when ready, rather than having developers push work to QA. This gives you control over your workload and prevents overload.
Measure Cycle Time for Testing
Track how long items spend in the QA Testing column. This is your testing cycle time. If it is increasing, it signals a problem:
- Items are growing in complexity
- Test environments are unstable
- Requirements are unclear, causing back-and-forth
Kanban vs Scrum: QA Perspective
| Aspect | Scrum | Kanban |
|---|---|---|
| Time structure | Fixed sprints (1-4 weeks) | Continuous flow |
| Testing cadence | Within sprint boundaries | Continuous, as items flow |
| Planning | Sprint Planning every 1-4 weeks | Just-in-time, as capacity allows |
| Roles | PO, SM, Dev Team (with QA) | No prescribed roles |
| Metrics | Velocity, sprint burndown | Lead time, cycle time, throughput |
| Releases | At end of sprint | Any time an item reaches Done |
| Best for QA when | Team needs structure and rhythm | Team needs flexibility and fast delivery |
When to Choose Kanban
Kanban works better for QA when:
- Bug fixing: Bugs arrive unpredictably. A flow-based system handles this naturally.
- Maintenance teams: Ongoing support work doesn’t fit sprint time-boxes.
- Multiple priorities: Stakeholders change priorities frequently.
- Continuous deployment: Features go live individually, not in batches.
When to Choose Scrum
Scrum works better for QA when:
- New product development: The team benefits from sprint goals and focused effort.
- Complex features: Sprint planning helps coordinate testing of interrelated features.
- Team building: Scrum ceremonies build team cohesion and communication.
Kanban Metrics for QA
Lead Time
Time from when a work item is requested to when it is delivered. QA contributes to lead time through testing duration.
Cycle Time
Time from when work begins on an item to when it is done. The testing portion of cycle time is directly in your control.
Throughput
Number of items completed per time period (usually per week). Track QA-specific throughput: how many items pass through the QA Testing column per week.
Cumulative Flow Diagram
This chart shows the number of items in each stage over time. It reveals bottlenecks visually:
Exercise: Design a Kanban Board for a QA Team
You are the QA lead for a team of 7 people (4 developers, 2 QA engineers, 1 product manager). The team maintains a live e-commerce platform and handles both new feature development and production bug fixes.
Current problems:
- QA is always overloaded — 10+ items waiting for testing at any time
- Bug fixes take 5+ days to reach production
- Developers start new features while their previous features wait for QA
- No visibility into what QA is currently working on
Your task:
Design a Kanban board that includes:
- Column names and WIP limits for each column
- How bug fixes are handled differently from features (expedite lane or separate class of service)
- Policies for moving items between columns (especially into and out of QA Testing)
- What metrics you would track and why
- How you would handle the initial transition from the current overloaded state
Hint
Consider these design decisions:
- An “Expedite” lane (or swimlane) with no WIP limit allows urgent bug fixes to bypass the normal flow
- You might split QA Testing into sub-columns: “In Testing” and “Tested” to show progress
- Explicit policies prevent arguments: define what “ready for QA” means
- To handle the initial backlog of 10+ items, you might need a temporary “drain” strategy
- Think about blocked items: what happens when QA finds a bug? Does the item go back to Development?
Sample Solution
Kanban Board Design
Board Layout:
| Lane | Backlog | Ready | Dev (WIP: 4) | Review (WIP: 2) | QA Testing (WIP: 3) | QA Passed | Release (WIP: 2) | Done |
|---|---|---|---|---|---|---|---|---|
| Expedite | — | — | No WIP limit | No WIP limit | No WIP limit | — | No WIP limit | — |
| Features | Items | Refined items | Active dev | Code review | In Testing / Tested | Verified | Deploying | Live |
| Bugs | Items | Triaged | Fixing | Review | Verification | Verified | Deploying | Live |
WIP Limits:
- Dev: 4 (one per developer)
- Code Review: 2 (prevents review backlog)
- QA Testing: 3 (manageable for 2 QA engineers, ~1.5 items each)
- Release: 2 (prevents deployment conflicts)
- Expedite lane: No limits but tracked separately
Column Policies:
Ready → Dev:
- Acceptance criteria defined and approved by PM
- QA has reviewed the story for testability
- Test approach documented (even if brief)
Dev → Code Review:
- Code complete with unit tests
- Unit test coverage ≥ 80% for new code
- Dev has done self-testing of happy path
Code Review → QA Testing:
- Code review approved by at least one peer
- Feature deployed to staging/test environment
- Developer provides test notes (what changed, what to focus on)
QA Testing → QA Passed:
- All acceptance criteria verified
- Exploratory testing completed
- No open critical or high-severity bugs
- Regression tests passing
QA Passed → Release:
- PM approves for release
- Release notes prepared
Bug Fix Flow (Expedite):
- Critical production bugs enter the Expedite lane
- No WIP limits — they get priority over everything
- Shortened testing: focused regression around the fix
- Target: fix deployed within 24 hours for critical, 48 hours for high
Metrics to Track:
- Cycle time by type: Features vs. bugs — to ensure bugs are fixed quickly
- QA testing cycle time: Average time items spend in QA Testing — to detect capacity issues
- Throughput per week: Items completed — to track team capacity
- Bug escape rate: Bugs found in production vs. caught in QA — to measure quality effectiveness
- Blocked time: How often and how long items are blocked — to identify systemic issues
Transition Strategy:
- Week 1: Apply WIP limits. Items already in progress are grandfathered.
- Week 2-3: As items finish, the board normalizes. Do not start new items until WIP is under limits.
- Week 4: Review cycle time data. Adjust WIP limits if needed.
- Ongoing: Weekly review of cumulative flow diagram to spot trends.
Advanced Kanban Practices for QA
Classes of Service
Not all work items are equal. Kanban uses “classes of service” to handle different priorities:
| Class | Example | QA Treatment |
|---|---|---|
| Expedite | Production outage | Drop everything, test immediately, focused regression |
| Fixed Date | Regulatory deadline | Plan testing early, no delays allowed |
| Standard | Regular features | Normal flow through the board |
| Intangible | Tech debt, refactoring | Test when capacity allows, lower priority |
Swarming
When the QA column hits its WIP limit and items are queuing up, the team can “swarm” — developers temporarily help with testing. This is one of Kanban’s most powerful mechanisms for resolving bottlenecks.
How developers can help:
- Execute predefined test cases
- Perform code-level testing (integration tests, API tests)
- Set up test data or environments
- Pair-test with QA engineers
Kanban Cadences (Meetings)
Kanban does not prescribe specific meetings, but most teams use these:
| Cadence | Frequency | QA Focus |
|---|---|---|
| Daily standup | Daily | Report blocked items, pull new work |
| Replenishment meeting | Weekly | Review upcoming items for testability |
| Delivery review | Weekly/biweekly | Review quality metrics, cycle time trends |
| Retrospective | Monthly | Improve testing flow, address bottlenecks |
Pro Tips for QA in Kanban
Track your testing cycle time religiously. If the average time items spend in QA Testing increases week over week, raise it immediately. Do not wait until the backlog is unmanageable.
Create explicit “ready for QA” criteria. The biggest waste in Kanban is pulling an item into testing only to discover it is not actually ready. Define minimum criteria (deployed to test environment, unit tests passing, dev notes provided).
Use sub-columns within QA Testing. Split into “In Testing” and “Tested, Awaiting Verification” to show progress within the QA stage.
Automate regression testing. In Kanban, you test items continuously. Running a full manual regression for every item is not sustainable. Automate the regression suite so you can focus manual effort on new functionality.
Visualize blocked items. When a test fails and the item goes back to developers, mark it as blocked (red flag on the card). This makes the rework visible and helps identify patterns.