AlterLab GameForge -- Scope Check Workflow
Scope creep is the number one killer of indie games. Not lack of talent, not bad ideas, not engine limitations. Games die because they grow past the team's capacity to finish them. It happens one "small" addition at a time, each individually reasonable, collectively fatal. The danger is that scope creep feels like progress -- adding a feature feels productive, cutting feels like failure. This workflow exists to invert that psychology: cutting is the skill, and a tight scope is the achievement.
Team Cherry shipped Hollow Knight with 3 people. ConcernedApe shipped Stardew Valley alone. Neither project was small in ambition -- they were ruthlessly disciplined about what to include and what to cut. The games that ship are not the ones with the longest feature lists. They are the ones where every feature earned its place through honest scope accounting.
The core principle: a finished game with 8 great features beats an abandoned game with 20 half-built ones. This workflow enforces that principle with concrete tools, not wishful thinking.
Purpose & Triggers
Use this workflow when:
- The feature list has grown since the last scope check
- Someone says "can we fit this in?" or "what if we also added..."
- A milestone deadline is approaching and confidence is low
- The team feels overwhelmed but cannot articulate why
- Sprint velocity is consistently below planned capacity
- Any stakeholder (including yourself) pushes back on cutting features
- The project has never had a formal scope check
Problems this solves:
- Feature lists that only grow, never shrink
- The "just one more thing" pattern that compounds into missed deadlines
- All features labeled "Must Have" because nobody wants to prioritize
- No clear connection between features and available work hours
- Teams afraid to cut features because they lack a framework for deciding what goes
- Scope discussions that devolve into opinion battles instead of data-driven decisions
Critical Rules
-
One In, One Out. Adding a feature requires cutting a feature of equivalent effort. No exceptions. No "we'll work harder." No "we'll figure it out." The budget is fixed. Moving a feature from Won't Have to Should Have means moving something from Should Have to Won't Have. Team Cherry cut entire areas from Hollow Knight to ship on time -- and the game is better for it because every surviving area is polished to a mirror shine.
-
Percentages are law. MoSCoW allocation must hold: Must Have occupies 60% of total effort, Should Have 25%, Could Have 15%. If Must Have exceeds 60%, the project is at risk regardless of how important each individual feature feels.
-
Score, don't debate. The Feature Scoring Matrix replaces opinion with arithmetic. Features are scored on Impact, Feasibility, and Risk. The math decides. If a team member disagrees, they challenge the individual scores, not the outcome.
-
Buffer is not optional. A schedule with less than 20% buffer is a schedule that will miss its deadline. Buffer absorbs the unexpected, and in game development, the unexpected is the expected. Treat buffer as sacred -- it is not "extra time for features."
-
Freeze dates are real. Feature additions freeze 3 days before any milestone. After the freeze, only bug fixes and polish are permitted. Breaking the freeze requires Producer-level sign-off and a corresponding cut elsewhere.
-
Honest estimates only. If you have never built a system like this before, double the estimate. If the tech is unfamiliar, triple it. Optimistic estimates are the fertilizer that scope creep grows in.
Workflow
🧠 PHASE 1: Feature Inventory
Goal: Catalog every feature currently planned, in progress, or requested.
Before you can assess scope, you need a complete picture. This phase produces an exhaustive list. Do not filter yet -- even features you suspect will be cut go on the list.
FEATURE INVENTORY
-------------------------------------------------
ID | Feature | Status | Requestor | Est. Hours
-------------------------------------------------
F01 | [feature name] | [planned/ | [who asked] | [honest
F02 | [feature name] | in-progress/ | | estimate]
F03 | [feature name] | complete/ | |
... | | requested] | |
-------------------------------------------------
Capture rules:
- Include features already in progress (sunk cost does not protect them)
- Include features someone mentioned casually ("wouldn't it be cool if...")
- Include features assumed but never written down (save system, settings menu)
- Estimate in hours, not days. Hours force specificity.
- If you cannot estimate a feature, mark it [UNKNOWN] -- that is itself a red flag
Ask the user to walk through every planned feature. Probe for hidden features: "Is there a settings menu? A save system? A tutorial? An options screen? Controller support?" These assumed features often consume significant time but never appear on lists.
🎯 PHASE 2: MoSCoW Classification
Goal: Sort every feature into four priority tiers with enforced percentages.
MoSCoW is not a wishlist exercise. It is a resource allocation framework. The percentages are constraints, not guidelines.
MoSCoW CLASSIFICATION
-------------------------------------------------
MUST HAVE (60% of total effort)
The game literally does not function or ship without these.
Test: "If this feature is missing, is the product broken?"
- F01: [feature] -- [hours] -- Reason: [why it's essential]
- F03: [feature] -- [hours] -- Reason: [why it's essential]
Subtotal: [X hours] / Target: [60% of total hours]
SHOULD HAVE (25% of total effort)
Significantly improves the game but it ships without them.
Test: "Would a reviewer notice this is missing?"
- F04: [feature] -- [hours] -- Reason: [why it matters]
Subtotal: [X hours] / Target: [25% of total hours]
COULD HAVE (15% of total effort)
Nice to have. First to be cut when time runs short.
Test: "Would anyone outside the team notice this?"
- F07: [feature] -- [hours] -- Reason: [what it adds]
Subtotal: [X hours] / Target: [15% of total hours]
WON'T HAVE (0% -- explicitly deferred)
Documented and deferred. Not forgotten, just not now.
These protect the team from revisiting already-made decisions.
- F09: [feature] -- Reason: [why it's deferred]
- F10: [feature] -- Reason: [why it's deferred]
-------------------------------------------------
RED FLAGS:
- Won't Have is empty --> Every feature cannot be essential. Be honest.
- Must Have exceeds 60% --> Either the game is too ambitious or the
classification is too generous. Demote features.
- All features are "Must Have" --> This is not prioritization. Start over.
Force-rank the Must Haves against each other.
🚨 PHASE 3: Feature Scoring Matrix
Goal: Replace subjective debate with a quantified score for each feature.
Every feature above the Won't Have line gets scored. The formula is: Score = (Impact x Feasibility) / Risk
FEATURE SCORING MATRIX
-------------------------------------------------
Feature | Impact | Feasibility | Risk | Score | Verdict
| (1-5) | (1-5) | (1-5) | |
-------------------------------------------------
[F01] | [ ] | [ ] | [ ] | [ ] | [Keep/Evaluate/Cut]
[F02] | [ ] | [ ] | [ ] | [ ] | [Keep/Evaluate/Cut]
... | | | | |
-------------------------------------------------
SCORING GUIDE:
Impact (1-5):
5 = Core loop depends on it. Game is broken without it.
4 = Major enhancement to player experience.
3 = Noticeable improvement. Reviewers would mention it.
2 = Minor polish. Players might notice if told.
1 = Developer-facing. Players never see it directly.
Feasibility (1-5):