Turn scope into milestones

1786. Lesson identity

Module

4.11 — Production

Lesson

Turn scope into milestones

Academic type

Systems

Schema type

text

Order

1 in the module

Estimated time

40–55 minutes, including practice

1787. Learning objective

After this lesson, you can map a bounded game feature or release slice into a milestone plan that identifies genuine dependencies, integration points, review decisions, observable completion criteria, and either rollback or containment where a milestone changes an existing state or a documented stop or revision condition where it does not.

1788. Why this matters

An approved product choice is not yet an executable production plan. A milestone plan makes the work inspectable: the team can see what must happen first, where a decision is required, how work will connect to the existing game, and what evidence counts as complete.

Changes to an executable path, integration, data, configuration, or release state need a safe rollback or containment response. Approval and discovery milestones may not alter a working state at all; their safe response is usually to stop, revise, or block later work. Making this distinction prevents artificial rollback instructions while keeping production decisions explicit.

The same structure gives AI a bounded planning problem instead of inviting an unprioritized task list.

1789. Prior knowledge

You should already be able to distinguish a product choice from an implementation detail and record the reasoning, boundary, and review conditions for a tradeoff, as practiced in 4.10 L2 — Record the tradeoff. You should also be able to describe a bounded game slice by its player-facing result and identify relevant constraints. You do not need a complete backlog or a finished implementation.

1790. Core concept

A milestone is a reviewable production state, not merely a date or a large task. It describes a meaningful result, the conditions required to reach it, a point where someone inspects it, the possible decision, and evidence supporting that decision.

Build each milestone plan from six layers:

1. Scope: What player-facing result is included, and what is explicitly excluded?
2. Dependencies: What must be true before later work can be completed, tested, or judged correctly?
3. Integration: Where and how will the result connect to an existing game path, system, content boundary, data set, configuration, or release state?
4. Review: Where will the result be inspected, and can the decision be accept, revise, reduce, block, or stop?
5. Failure response: If the milestone changes an existing executable or operational state, what rollback or containment action applies, what condition triggers it, and what state is restored or isolated? If it is an approval or discovery milestone that changes no such state, what condition stops, revises, or blocks subsequent work?
6. Evidence: What observable behavior or artifact proves completion?

Integration planning does not require a full implementation design. It identifies the connection that must be checked and, where that connection changes existing state, the smallest safe way to reverse or isolate the change. A rollback or containment plan names a trigger, an action, and a state to restore or isolate. A stop or revision condition names the evidence that prevents approval or later work and the required next decision.

“Build combat, add UI, polish audio” is an activity list, not a milestone plan. Reframe it as a reviewable state, such as “the player can complete one defined encounter, see its result, and retry after failure.” Then state where it connects to the existing player flow, how that connection will be checked, and what response applies if the milestone fails.

1791. Mental model

Use Scope → Dependency → Integration → Review → Failure response → Evidence.

A hard dependency blocks valid execution or evaluation. A preference only suggests a convenient order. Do not label every related task as a dependency.

An integration point is not automatically a dependency. It becomes a hard dependency when the milestone cannot be validly tested or judged without the connection. Record the integration check separately so the team does not mistake “connected” for “complete.”

A milestone should be small enough to review and large enough to demonstrate a meaningful production state. If it cannot be demonstrated, it is probably a task. If it contains unrelated player-facing outcomes, split it. If it changes an existing state but no credible rollback or containment action can be named, reduce or isolate it before execution. If it changes no existing state, do not invent a rollback; define a stop, revision, or block condition instead.

1792. Concrete example

Bounded scope: “Create one playable checkpoint sequence in which the player enters a space, uses one approved interaction, receives a clear result, and can retry after failure.”

The first milestone changes no executable path, so its failure response is to stop and revise rather than pretend to restore a prior game state. The later milestones modify playable behavior and therefore require rollback or containment.

“Polish” is not a useful milestone by itself. Specific polish work can be included only when it has a reason, boundary, review decision, evidence, and an applicable failure response.

1793. AI-native workflow

Use AI as a planning critic, not as the authority that defines scope or completion.

1. Write the scope boundary, exclusions, constraints, and product decision record yourself.
2. Ask AI to propose missing dependencies, integration checks, review decisions, failure conditions, and testable completion criteria without adding features, platforms, content, or unrequested polish.
3. Classify each milestone: does it change an existing executable path, integration, data, configuration, or release state? If yes, require rollback or containment. If no, require a stop, revise, or block condition instead.
4. Reject preferences presented as hard dependencies, invented rollback actions, and responses that do not restore, isolate, or protect a known state.
5. Ask AI to challenge the plan with hidden cross-system work, integration assumptions, irreversible changes, and milestones too large to review.
6. Produce the final milestone table yourself and record which suggestions you accepted, modified, or rejected.

Example prompt:

Given this bounded game-production scope, its exclusions, constraints, and recorded product tradeoff, propose reviewable milestones. For each one, state genuine prerequisites, the integration boundary and check, the review decision, and observable completion evidence. If the milestone changes an existing executable path, integration, data, configuration, or release state, propose a rollback or containment trigger and action. Otherwise, propose a stop, revise, or block condition. Do not add scope, and separate assumptions from facts.

The developer remains responsible for verifying the plan. AI cannot inspect a player-facing result or prove that a restored or isolated state is safe.

1794. Common mistakes

• Turning departments or activities—programming, art, audio, testing, or polish—into milestones instead of reviewable outcomes.
• Treating every convenient sequence as a hard dependency.
• Treating integration as a final handoff rather than a connection to test throughout production.
• Requiring a fictional rollback for an approval or discovery milestone that changed no working state.
• Writing “roll back if it fails” without naming the trigger, action, and state restored or isolated.
• Using subjective criteria such as “works,” “feels good,” or “is polished” instead of observable evidence.

1795. Guided practice

Create a milestone plan for one bounded scope from your project, or use the checkpoint sequence from the example.

1. Write one sentence describing the player-facing result.
2. List three explicit exclusions.
3. Identify at least four outcomes or conditions required for that result.
4. Represent the hard dependencies and preferred ordering either as a labeled diagram or as a text list. For example: “Milestone C depends on A and B; B before C is mandatory, while A before B is preferred.” Do not rely on color or spatial position alone.
5. Group the work into three or four reviewable milestones.
6. For each milestone, identify the existing player flow, system, content boundary, data, configuration, or release state involved and define one integration check.
7. Add a review point and possible decision—accept, revise, reduce, block, or stop—to each milestone.
8. Classify each milestone’s failure response. Where it changes an existing state, define a rollback or containment trigger, action, and restored or isolated state. Otherwise, document the condition that stops, revises, or blocks later work.
9. Write at least two observable completion criteria for each milestone.
10. Simulate one failure involving a changed state and show the applicable rollback or containment response. If the plan has no such milestone, simulate a failed approval or discovery condition and show how work stops or is revised.
11. Ask AI to challenge the plan, then record one accepted suggestion and one rejected suggestion with reasons.

Make one deliberate scope decision: defer an attractive item that is not required for the bounded result and explain why.

1796. Validation and evidence

The practical assessment requires one milestone plan containing:

• a bounded player-facing result and explicit exclusions;
• three or four meaningful production states;
• hard dependencies distinguished from preferences in a labeled diagram or text list;
• an integration boundary and integration check for every milestone;
• a review point and decision options for every milestone;
• rollback or containment where a milestone changes an existing state, or a documented stop or revision condition where it does not;
• observable completion criteria rather than activity labels or subjective claims;
• at least one deferred item with a reason;
• a brief record of how AI challenged the plan and how its suggestions were evaluated.

Trace one milestone from dependency through integration and review. Then simulate one named failure. Show the trigger, response, resulting state, and evidence that later work can safely continue, remain blocked, or return for revision without silently expanding scope.

1797. Key takeaways

• A milestone is a reviewable production state, not a date or department task.
• Hard dependencies are genuine blocking conditions; preferences are not.
• Integration planning identifies an existing boundary and a checkable connection.
• Rollback or containment is required when a milestone changes existing executable or operational state.
• Approval and discovery milestones instead need explicit stop, revision, or block conditions when no state has changed.
• Every milestone needs a review decision and observable completion evidence.
• AI can challenge the plan, but the developer owns its final decisions.

1798. Next lesson

Continue to 4.11 L2 — Manage risk before it becomes schedule fiction, where you will use this milestone plan to identify production risks and assign mitigation or decision dates.

1799. Knowledge check