game-scope-check

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

1. **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.

2. **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.

3. **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.

4. **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."

5. **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.

6. **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.

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge