Scope-Driven Production

Game development has adopted production methodologies from other industries. Scrum emerged from manufacturing. Kanban from automotive. Agile from enterprise software. These frameworks have brought valuable discipline to creative work, and we respect the problems they solved.

But game development is distinct. We ship interconnected assets and features, not isolated tickets. Our teams are highly specialized, not interchangeable. Our work flows through parallel pipelines, not linear boards. The estimation challenges we face are structural, not procedural.

We believe game production is ready for its own methodology that reflects how successful studios actually work. Not a rejection of what came before, but an evolution built on our industry’s specific needs. We have observed these patterns across studios that ship well, and we are giving them a name and a structure so they can be taught, refined, and supported by better tooling. We call this approach Scope-Driven Production.

Tenet 1: Assets Over Tickets

The principle: The primary unit of game production is the asset, not the task.

Why this matters: Games are made of concrete things like weapons, characters, levels, dialogue trees, and sound effects. These assets have identity, state, and dependencies that persist throughout production. When we organize work around assets rather than abstract tasks, we gain clarity about what we are building and where it stands.

How it works: Tasks don’t disappear. They live in service of assets. The asset is the anchor. The tasks are the work required to complete it.

The test question: Can you answer “What is the current state of the broadsword needed for Level 3?” If your system lets you trace an asset from concept through completion, seeing all related work and dependencies in one place, you are practicing this tenet.

Tenet 2: Estimation by Discipline

The principle: Art, engineering, design, and audio have different effort costs. Measure them separately.

Why this matters: Game teams are specialized. A character artist cannot complete a networking task, and a sound designer cannot unblock a shader bug. Different people have different capacities and velocities, which means you need to track effort separately by discipline to understand your real constraints.

How it works: One asset might require 3 days of art, 1 day of engineering, and half a day of audio. These aren’t interchangeable - you need to track them separately to see where your bottlenecks are.

The test question: Can you see, at a glance, how much art effort versus engineering effort remains in your milestone? If your system tracks effort by discipline and lets you assess workload per team, you are practicing this tenet.

Tenet 3: Estimation by Asset Type

The principle: A shotgun is two pistols. Compare within asset types, not across them.

Why this matters: Traditional story points ask you to compare incomparable things. How do you calibrate a story point for implementing a credits screen against creating a new enemy type? They’re fundamentally different kinds of work and frames of context. A “5-point story” is unintuitive when you’re mixing asset types.

How it works: Estimate within asset categories instead. Compare enemies to other enemies. Compare weapons to other weapons. Ship a few assets in a category and use that completed work as your baseline. A standard pistol took 28 effort points across all disciplines. A shotgun needs more animations, more VFX, more balance tuning - probably 1.5x or 2x the pistol. You’re not guessing hours, you’re saying “this is like that, but bigger.”

The benefit: Comparisons within asset types are intuitive because the work is structurally similar. Your estimates improve with every asset you complete in that category. After shipping 5 enemies, your enemy estimates become reliable. After shipping 5 weapons, your weapon estimates become reliable. The data compounds over time.

The test question: Do you estimate new assets by comparing them to completed assets of the same type? If you can say “this enemy is 3.0x a standard enemy” based on shipped work, you are practicing this tenet.

Tenet 4: Parallel Pipeline Architecture

The principle: Assets flow through multiple disciplines simultaneously, not sequentially through a single board.

Why this matters: A character requires concept art, modeling, rigging, animation, and implementation. Some work is sequential (you can’t animate without a rig), while other work runs in parallel (VFX and implementation can happen simultaneously). Linear Kanban columns (To Do → In Progress → Done) can’t capture this complexity.

How it works: During pre-production, you design pipeline templates for each asset type. During production, you apply these templates to new assets. Over time, you refine them based on what you learn. The pipeline becomes institutional knowledge, encoded in structure, not dependent on tribal memory.

The test question: Can you see all disciplines working on an asset in a single view, with clear stages and handoffs? If your system supports configurable, parallel pipelines with predefined stages, you are practicing this tenet.

Tenet 5: Scope Control

The principle: You control scope through data. Adjust what you’re building based on what you can actually ship.

Why this matters: Asset count × effort × complexity ÷ velocity = ship date. When you know your team’s velocity (how much work you complete per sprint) and the total effort required for your remaining assets, you can project a completion date. More importantly, you can manipulate the variables to control your timeline.

How it works: Cut 10 assets and your ship date moves up 2 weeks. Reduce complexity and gain another week. Add capacity and gain 3 more weeks. Increase quality (higher effort per asset) and your date pushes out. These aren’t guesses - they’re calculations based on your team’s actual performance.

The benefit: This approach is not perfect, but it is improvable. Each completed asset refines your understanding. Each sprint updates your velocity. Your projections get better because they’re built on structure and real data.

The test question: Can you look at your remaining scope and current velocity and project a realistic completion date? More importantly, can you adjust scope variables and understand the timeline impact? If you can control your scope through informed trade-offs rather than wishful thinking, you are practicing this tenet.

Why This Matters for Game Development

Traditional project management treats all work as interchangeable units flowing through sequential stages. This works for assembly lines and software features, but breaks down for games.

Game development is different:

What Scope-Driven Production gives you:

• Clarity: See what you’re building (assets) and what it takes (effort by discipline)
• Flexibility: Organize by asset or discipline without duplication
• Predictability: Calculate scope from data, not hope
• Scalability: Templates that work for 10 assets or 1,000

Closing Words

Scope-Driven Production is not a rejection of existing methodologies. Iteration matters. Adaptation matters. Responding to change matters. These principles remain valuable.

What we are proposing is a layer of structure designed specifically for how games are made. We did not invent these ideas. We observed them in studios that consistently deliver. We are offering language and framework so these practices can be shared, taught, and improved upon.

If your production process already embodies these tenets, you are practicing Scope-Driven Production—whether you have called it that or not. If some of these ideas are new to you, we invite you to experiment with them.

This manifesto is a starting point, not a final word. We welcome conversation, critique, and collaboration from producers, leads, and directors who care about how games get made.

Game development deserves production methodology built for game development.

The Scope-Driven Production methodology is developed and maintained by Codecks. For tooling, resources, and discussion, visit codecks.io