How We Scope Game Projects to Avoid Production Failure

Most game projects run over budget and past deadline. Not because the teams are bad, but because the estimates were wrong from the start. Here's how we approach scoping to avoid that.

Why Game Estimates Are Usually Wrong

Software estimation is famously hard. Game estimation is harder. The requirements change as you discover what's fun. "One level" can mean vastly different amounts of work depending on dozens of factors. And everyone involved is optimistic because they want the project to happen.

The Planning Fallacy

Humans consistently underestimate how long things take, especially things they haven't done before. "I built a weapon system before, this will take two weeks." But this weapon system has 15 attachments, procedural animations, and multiplayer sync. It takes two months.

Unknown Unknowns

You can estimate what you understand. You can't estimate what you don't know you don't know. That physics bug that takes three weeks to fix. The middleware that doesn't work as documented. The asset store purchase that needs complete reworking.

Scope Creep Disguised as Clarification

"The inventory should sort by type" becomes "actually we need customizable sorting" becomes "and filtering" becomes "and search" becomes "and the UI needs to be prettier." Each change seems small. Together they double the work.

Our Scoping Process

1. Define Success First

Before estimating anything, we define what "done" looks like. Not "a fun game" - something measurable. "5 levels with 3 enemy types, playable start to finish, running at 60 FPS on GTX 1060." This becomes the scope anchor.

2. Break Down Ruthlessly

Big features hide complexity. "Multiplayer" isn't a feature - it's dozens of features. We break tasks down until each one is estimable (usually 1-3 days of work). If we can't break it down, we don't understand it well enough to estimate.

3. Estimate in Ranges

Single-number estimates are lies. We estimate optimistic, expected, and pessimistic cases. "Character controller: 3-5-10 days." The optimistic case is if everything goes right. The pessimistic case is if we hit significant problems. Most things land between expected and pessimistic.

4. Add Buffers Explicitly

We add 30-50% buffer for unknowns, integration issues, and iteration. This isn't padding - it's accounting for reality. Projects that "don't need buffer" are projects that will run over.

Scope Management During Production

The initial estimate is a starting point. Reality diverges. The question is how you respond.

Track Velocity

We measure actual time against estimates weekly. If we're consistently taking 1.5x estimated time, we adjust remaining estimates by 1.5x. Early warning means early adjustment.

Replan Regularly

Monthly scope reviews compare remaining work to remaining time and budget. If they don't align, something changes. Better to cut a feature at month 3 than discover at month 11 you can't ship.

Change Control

New features and changes go through explicit approval. What does this add? What does it cost? What gets cut to make room? Adding things without cutting things is how scope explodes.

What We Need for Good Estimates

To scope a project accurately, we need:

• Clear target - What platforms, what audience, what quality bar
• Reference points - Games you want to be like, and how you differ
• Existing work - If there's a prototype, we can estimate production more accurately
• Constraints - Fixed deadline? Fixed budget? Platform requirements?
• Priorities - When we inevitably need to cut, what goes first?

The more clarity upfront, the better the estimate. "Make a game" is impossible to estimate. "3D FPS, single-player, 8 levels, Steam release, comparable to X" is estimable.