Scope & Vertical Slice Definition

Step 1 — List every feature anyone has proposed

Pull every mechanic, asset, system, and level requirement from your greenlit pitch, your GDD draft, and any group brainstorming sessions. Get them all written into a single shared raw list before sorting anything.

Step 2 — Sort into MoSCoW, as a group

As a team, review every item and assign it to one of the four MoSCoW buckets:

• Must have: If even one of these features is missing, the vertical slice fails to demonstrate the core game loop.
• Should have: Genuinely valuable and planned for inclusion, but the core slice remains playable without it.
• Could have: Low-cost polish items and stretch goals. The first items cut when deadlines tighten.
• Won’t have: Explicitly cut or deferred for this vertical slice.

If team members disagree on whether an item is a Must or a Should, talk it out. That debate is valuable: it exposes differing assumptions about the core loop before production begins.

Step 3 — Stress-test the Must-have list

Once sorted, read your Must-have list out loud as a single continuous sentence describing what a player experiences in the slice:

“The player controls [Character] in [Location], uses [Core Mechanic] to solve/defeat [Primary Challenge], and completes the slice at [End Trigger].”

Ask honestly: Is this genuinely buildable by this team in our available lab hours before deadline? If you are unsure, move the least critical item from Must down to Should. A lean Must-have list now is what makes spring milestones achievable.

Step 4 — Write the Won’t-have list clearly

The Won’t-have section is the most important part of your contract. Do not treat it as a graveyard of discarded bullet points. Write each cut feature as a clear sentence explaining why it is omitted:

• Example: "Multiplayer / Co-op — Out of scope for a 5-minute single-player vertical slice; revisit only in post-slice full production."
• Example: "Branching Narrative Dialogue Trees — Requires custom UI and narrative scripting beyond current timeline; slice will feature direct environmental objectives instead."

Step 5 — Define the slice boundary

Write a single, tightly scoped paragraph defining the start, middle, and end conditions of the slice:

• Where does the player start? (e.g., waking up in the broken maintenance bay).
• What is the central objective? (e.g., restore power to the primary airlock).
• Where does the slice end? (e.g., stepping through the airlock as the station alarms trigger).

This boundary paragraph is the studio’s concrete definition of “Done” for the year.

Step 6 — Build the scope contract document

Format your studio’s scope contract into a clean document (Google Doc or Notion page) containing:

1. Title & Game Hook: Game title, logline, and studio team name.
2. Slice Boundary Paragraph: The narrative and gameplay start/end conditions.
3. MoSCoW Feature Tables:
   • Must-have features
   • Should-have features
   • Could-have features
   • Won’t-have features (with rationale for each)
4. Team Signatures: Date and typed/signed names of every studio member committing to this scope.

Step 7 — Post it where the team works

Link the signed scope contract at the top of your team’s GDD and pin it to your Kanban task board (Trello/GitHub Projects). Whenever a new idea or mechanic is proposed during sprints, check the contract first.