AlterLab GameForge -- Sprint Planning Workflow

Game development sprints fail for different reasons than software sprints. A SaaS team struggles with unclear requirements and shifting priorities. A game team struggles with cross-discipline dependencies and the fundamental unpredictability of "fun." You can spec out an inventory system perfectly, build it to spec, and discover in playtest that it makes the game worse. Supergiant's sprint model (documented in their GDC talks) accounts for this by reserving explicit "discovery time" in every sprint -- time allocated to test whether what they built actually feels good, not just whether it works.

Sprint planning for games must build in structured discovery time, explicit scope tiers that flex without chaos, and a dependency model that respects the sequential nature of art-to-integration pipelines. This workflow produces a concrete sprint plan document a team can execute against.

Purpose & Triggers

Use this workflow when:

• A team is about to start a new development sprint
• A solo developer wants to structure their next 1-2 weeks of work
• After a sprint retrospective, when planning the next iteration
• When a milestone is approaching and work needs to be decomposed
• The user finished game-brainstorm or game-design-review and needs to turn design decisions into executable tasks

Problems this solves:

• Sprints with vague goals that cannot be evaluated as done or not done
• Tasks estimated at "a few days" that actually take two weeks
• Art and code tasks planned in parallel when art must finish first
• Teams that commit to more work than their capacity allows every sprint
• Risks that were obvious in retrospect but invisible in planning
• No velocity tracking, so every sprint's estimates are guesses
• Scope creep disguised as small additions that accumulate into missed deadlines

Critical Rules

1. One goal per sprint. The sprint goal is a single sentence that defines success. If the sprint achieves this goal and nothing else, it was a successful sprint. If the sprint ships everything on the task list but misses the goal, it failed. Hades' sprint goals during Early Access were experience-focused: "players feel the narrative progressing even when they die." That clarity prevents the "we did a lot of stuff but nothing feels finished" anti-pattern.

2. Tasks max 1 day. Any task estimated at more than 1 day must be decomposed further. Large tasks hide complexity and create false confidence in estimates. If a task seems irreducible at more than 1 day, it is either too vague or the developer does not yet understand the work well enough (which is itself a discovery task). Dead Cells' development at Motion Twin used day-sized tasks for everything -- even major features like new biomes were decomposed into dozens of single-day tasks with clear done criteria.

3. The 20% buffer is non-negotiable. After calculating raw capacity, subtract 20%. This covers meetings, code reviews, unexpected bugs, build issues, hardware problems, and the general friction of collaborative work. Teams that skip the buffer consistently overcommit and consistently underdeliver. Solo devs are not exempt; context switching, research tangents, and "I'll just refactor this one thing" all eat time.

4. Dependencies are first-class concerns. A task that is blocked by another task is not ready to be worked. Map dependencies explicitly, identify the critical path, and ensure blocking tasks are scheduled first. The most common game-dev dependency chain: design spec --> art/audio asset creation --> code integration --> QA verification.

5. Scope tiers enable flexibility. Not everything in a sprint has equal priority. Use Must/Should/Could/Won't tiers so the team knows what to cut first when reality intrudes. Cutting a Could-Have on Wednesday is healthy scope management. Cutting a Must-Have on Friday is a crisis.

6. Velocity honesty over velocity aspirations. If the team has completed an average of 30 story points in each of the last 3 sprints, planning 45 points this sprint is not ambition -- it is delusion. Use actual historical velocity, not hoped-for velocity. Larian's milestone-based development for BG3 worked because they tracked velocity obsessively and adjusted scope accordingly -- not because they crunched harder.

7. Align with pillars. Every sprint goal traces to a design pillar. If a sprint goal does not serve any pillar, the team is either working on infrastructure (acceptable but call it out) or drifting from the vision (flag for discussion). Supergiant's sprint goals are always framed as player experience statements, not feature lists -- "players feel the weight of their weapon choices" not "implement weapon system." Reference docs/game-design-theory.md for pillar methodology and docs/collaboration-protocol.md for cross-discipline coordination rules.

Sprint Context (Auto-populated)

These values are injected automatically via shell preprocessing before the skill content reaches Claude. They provide real-time project data so sprint planning starts from the actual state of the codebase, not from memory or assumption.

• Recent commits: !git log --oneline -20 2>/dev/null || echo "No git history"
• Open issues: !gh issue list --limit 10 --state open 2>/dev/null || echo "No GitHub issues accessible"
• Last sprint: !cat production/session-state/last-sprint.json 2>/dev/null || echo "No previous sprint data"
• Team velocity: !cat production/session-state/velocity.json 2>/dev/null || echo "No velocity data"
• Active branches: !git branch --list 2>/dev/null | head -10 || echo "No branches detected"
• Uncommitted changes: !git status --short 2>/dev/null | wc -l || echo "0"
• Days since last tag: !git log --tags --simplify-by-decoration --pretty="format:%ar" 2>/dev/null | head -1 || echo "No tags — no milestone history"
• Current milestone files: !ls production/milestones/ 2>/dev/null | tail -3 || echo "No milestone directory"

Use this auto-populated data to inform sprint planning decisions. The recent commits reveal what work was recently completed and what areas of the codebase are active. Open issues provide the backlog candidates. Previous sprint data and velocity JSON enable data-driven capacity planning (see Step 5 and Step 7). Active branches reveal work in progress that may carry over into this sprint. Days since last tag indicates how long since the last formal milestone, which helps calibrate sprint scope.

If velocity data is unavailable (first sprint), plan conservatively and use this sprint to establish a baseline. If last sprint data is available, compare planned vs. completed to calibrate this sprint's commitments.

Workflow

Step 1: Sprint Goal Definition

A sprint goal is not a task list summary. It is the strategic purpose of the sprint, connected to the game's design pillars and current milestone.

SPRINT GOAL FRAMEWORK
-------------------------------------------------
Format: "By the end of this sprint, [specific deliverable] is [specific state]
         so that [specific value to the project]."

GOOD EXAMPLES:
- "By the end of this sprint, the core combat loop is playable with 3 enemy
   types so that we can run our first combat-focused playtest."
- "By the end of this sprint, the save/load system handles all current game
   state so that playtesters can resume sessions."
- "By the end of this sprint, the tutorial sequence covers movement, combat,
   and inventory so that new players can learn without external instructions."

BAD EXAMPLES:
- "Work on combat stuff." (vague, not evaluable)
- "Fix bugs and add features." (two goals, not one)
- "Make the game better." (not falsifiable)

PILLAR ALIGNMENT:
Sprint goal: [goal statement]
Serves pillar: [which pillar this advances]
Milestone: [which milestone this contributes to]
-------------------------------------------------

Step 2: Task Decomposition

Brea