Scrum vs Kanban in Game Pre-Production and Production

Game development shifts fundamentally as a project transitions from the exploratory chaos of pre-production to the disciplined execution of full production. Choosing between Scrum and Kanban across these two phases directly dictates how teams manage unpredictability, asset pipelines, and delivery schedules. This article explores the operational differences between Scrum and Kanban in both pre-production and production, detailing how cadence, scope management, estimation, and workflow tracking diverge in each framework.

Cadence and Planning Cycles

In pre-production, the primary objective is finding "the fun" through rapid prototyping, concept art iteration, and technical de-risking. Operating Scrum during this phase requires fixed-length sprints (typically one to two weeks), sprint planning, and a defined sprint goal. Operationally, this structure often clashes with pre-production because prototypes frequently invalidate assumptions midweek, rendering committed sprint backlogs obsolete. Conversely, Kanban operates on a continuous flow model without fixed iterations. Pre-production teams using Kanban pull work on demand, allowing designers and engineers to discard failed experiments instantly and pull new tasks without waiting for the next sprint boundary.

During full production, the cadence dynamic shifts. Production requires predictable output across engineering, art, animation, audio, and level design to hit publisher milestones or release dates. Scrum provides operational predictability through regular, synchronized sprint intervals. Teams commit to a clear package of deliverables every two to three weeks, establishing a dependable cadence for integration and internal playtests. Kanban in production abandons these fixed sync points, relying instead on continuous integration and just-in-time delivery. While efficient for modular asset delivery, Kanban without strict timeboxes can make cross-discipline alignment and synchronized milestone tracking more difficult across large teams.

Scope Management and Work-in-Progress (WIP)

Scrum manages scope through sprint commitments. Once a sprint begins, the scope is ideally locked. In pre-production, locking scope is counterproductive, as immediate pivots are required based on prototype playtesting. Teams using Scrum in pre-production often suffer from persistent "spillover" and broken commitments. In production, however, locked sprint scope acts as a shield, preventing feature creep and shielding developers from ad-hoc managerial requests while they build core game systems.

Kanban manages scope strictly through Work-in-Progress (WIP) limits per column or discipline rather than timeboxes. In pre-production, WIP limits prevent designers from starting five parallel mechanics before validating the first one. In production, WIP limits expose bottlenecks directly on the operational pipeline—such as 3D models piling up at the rigging or texturing stage. Operationally, Kanban forces the team to clear these pipeline chokepoints before pulling new assets into the board.

Estimation and Velocity Tracking

Estimation methods differ significantly between the two frameworks and their respective phases:

• Scrum in Pre-production: Teams attempt to assign story points or hours to high-uncertainty research and development (R&D) tasks. These estimates are routinely inaccurate because the technical or creative solution is not yet known, leading to volatile velocity metrics that offer little predictive value.
• Kanban in Pre-production: Teams often forego granular estimation entirely. Instead, they track throughput and cycle time—measuring how long an experimental mechanic takes from concept to playable build—focusing on rapid feedback rather than velocity forecasts.
• Scrum in Production: Estimation becomes highly reliable. Features are broken into well-understood user stories. Velocity stabilizes, allowing producers to construct burn-down and burn-up charts to accurately forecast whether milestones, beta phases, or submission deadlines will be met.
• Kanban in Production: Teams measure lead time (request to completion) and cycle time (active development to completion). This operational metric is ideal for repetitive pipelines, such as producing 200 environment props or resolving thousands of QA bug tickets, but provides less structural data for long-term project-wide milestone forecasting.

Discipline Alignment and Handoffs

Game development relies heavily on sequential dependencies: concept art informs 3D modeling, which informs rigging, animation, and engine implementation.

Scrum handles these dependencies by building cross-functional "feature teams" containing all required disciplines. During production, a feature squad (e.g., combat or UI) plans and delivers a complete slice of functionality within the sprint. During pre-production, cross-functional Scrum teams work closely to build vertical slices, though individual specialists may face idle time if dependent technical foundations are not ready.

Kanban treats dependencies as stages in a visual value stream. This makes Kanban operationally superior for functional, pipeline-based departments during production—such as dedicated art, QA, or localization teams. These teams operate as service desks, processing requests steadily regardless of feature sprint cycles. However, in pre-production, purely pipeline-based Kanban can cause siloed thinking if disciplines pass work over the wall instead of collaborating in real time to solve design challenges.

Summary of Operational Differences