Summary
Kanban is a workflow management method that visualises work in progress, limits the amount of work active at any one time, and continuously improves the flow of work through a pipeline. In game development, Kanban is particularly well suited to content production disciplines — art, audio, and level design — where work flows continuously rather than in discrete sprint-sized chunks.
Kanban complements Scrum rather than replacing it. Many studios use Scrum for feature development and Kanban for their content pipelines. See scrum-in-game-development for the broader Agile framework.
Key ideas
The three Kanban practices
1. Visualise the workflow
Map every step that an asset moves through from conception to completion. For a level, this might be:
Backlog → Concept → Design → High-Res Art → Audio → Tuning → Done
Each stage is a column on the Kanban board. Work items (cards) move left to right. Buffers between stages can be added to smooth flow and prevent starvation/overflow at any step.
2. Limit Work in Progress (WiP)
Each column has a WiP limit — the maximum number of items that can be in that stage at once. When a stage hits its limit, the team cannot pull more work into it; instead, they help clear the blockage downstream.
WiP limits:
- Force bottlenecks to become visible (if a stage is always at its limit, it is the constraint)
- Prevent partially finished work from accumulating
- Encourage swarming — team members help unblock stuck items rather than starting new ones
Example board with WiP limits:
Backlog | Concept(1) | Buffer(2) | Design(2) | Buffer(2) | Hi-Res(3) | Buffer(1) | Audio(1) | Buffer(1) | Tuning(1) | Done
3. Measure and manage the workflow
Key metrics:
- Cycle time — how long it takes one item to move from start to done; the primary improvement target
- Takt time — the rate at which items must be completed to meet the release schedule (total available time ÷ number of items needed)
- Throughput — items completed per unit time
The goal is to make cycle time match or beat takt time sustainably — without overtime.
Improving the workflow
Reducing batch sizes
Large batches (a dozen character models completed before any are handed to a rigger) increase cycle time and delay feedback. Smaller batches reveal quality and production issues earlier and more cheaply.
One documented example: a level production team broke levels into seven streaming “zones.” Cycle time dropped to one-seventh of what it was before, and each zone fed improvements into subsequent zones. By end of production the team had reduced cycle time by more than 50%.
Reducing handoffs
Every handoff between specialists introduces delay, misunderstanding, and potential rework. A concept artist sitting separately from the level design team produces drawings based on assumptions that may be wrong; the level designers may not need most of what is produced.
Keith’s example: moving the concept artist to sit next to the level designer and high-resolution artists meant far fewer drawings were needed and their quality improved — the team had the dialogue that handoffs prevent. This single change contributed to the 56% cycle time improvement.
Responding to bottlenecks
When a stage consistently hits its WiP limit while upstream stages starve, the bottleneck is visible. Responses:
- Reduce the scope of work per item at the bottleneck stage
- Add capacity (more people, better tools)
- Adjust process to bypass or restructure the bottleneck step
- Move specialist closer to the work (as with the concept artist example)
On creativity and constraints
A common objection: “Won’t WiP limits and takt time stifle creative work?”
Keith quotes T.S. Eliot: “When forced to work within a strict framework, the imagination is taxed to its utmost and will produce its richest ideas. Given total freedom the work is likely to sprawl.”
In practice, teams working under takt time constraints become inventive about finding waste and improving their tools. The constraints surface problems that were previously invisible — and creative teams solve them creatively.
Kanban vs. Scrum
| Aspect | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed sprints (1–3 weeks) | Continuous flow |
| Commitment | Sprint Goal committed per sprint | Ongoing; items pulled when capacity allows |
| Change | No changes mid-sprint | Changes can be made at any time |
| Metrics | Velocity, burndown | Cycle time, throughput, WiP |
| Best for | Feature development | Content pipelines, support, live games |
| Roles | Scrum Master, PO, Dev Team | No prescribed roles |
Many studios use Scrum for gameplay programming and feature work, and Kanban for their art/audio/level pipelines. The Scrum Sprint Review pulls the two together: the sprint goal determines what content the pipeline needs to produce by the end of the sprint.
Lean principles underlying Kanban
Kanban in game development draws from Lean manufacturing principles:
- Eliminate waste — waiting time, unnecessary exports, approval delays, redundant meetings are waste
- Amplify learning — smaller batches produce faster feedback loops
- Decide as late as possible — defer decisions until information is available
- Deliver as fast as possible — reduce cycle time as the primary improvement goal
- Empower the team — the people doing the work identify and solve bottlenecks; managers cannot be everywhere
In practice
For a Unity art pipeline (characters):
Backlog → Concept sketch → 3D blockout → Rigging → Skinning → Animation → VFX → QA → Done
WiP limit of 2 on each stage prevents a pile-up of “almost done” characters that block the pipeline without delivering value.
For audio (which Keith notes is chronically “at the end of the chain”):
- Traditional: audio is added last, meaning changes to gameplay require expensive audio rework
- Kanban solution: audio joins content teams earlier; audio cards flow through the same board as the assets they support
Evidence
“By reducing the cycle time of level sections to one-seventh of what they were before […] this team eventually reduced its cycle time by more than 50 percent.” (Keith, Ch. 10)
“Moving the concept artist next to the level designer and high-resolution artists […] far fewer drawings needed to be created, and the quality of the levels improved. […] By the end of production, [the team] had improved takt time by 56 percent while significantly improving quality.” (Keith, Ch. 10)
“One concern about Lean is that it limits the creativity of artists in production. I have found that the opposite is the case. […] ‘When forced to work within a strict framework, the imagination is taxed to its utmost.‘” (Keith, Ch. 10, citing T.S. Eliot)
Implications
- Art and audio teams that work in discipline silos accumulate batch sizes automatically — Kanban is the most direct intervention
- “Optimising for utilisation of individual specialists” (everyone always busy) is the wrong goal; optimising for flow of finished assets is the right goal
- Outsourcing works better with Lean: outsource the components that flow into studio-side layouts, not entire levels; deliver in small batches, not one large shipment
Open questions
- How should student projects (short duration, small team, all disciplines overlapping) structure a Kanban board?
- When Scrum and Kanban are used simultaneously, who owns the interface between them — the Scrum Master or a producer?
- How does Kanban need to change for live game development where content pipelines never end?
Related
scrum-in-game-development | sprints | product-backlog | agile-design | minimum-viable-game | overview-agile-game-development | source-agile-game-development