Invoke when the user needs to plan a development sprint, break down tasks, schedule game work, or organize a sprint with cross-discipline dependencies. Triggers on: "sprint plan", "task breakdown", "development planning", "scheduling", "sprint backlog". Do NOT invoke for scope evaluation (use game-scope-check) or retrospectives (use game-retrospective). Part of the AlterLab GameForge collection.
Invoke when the user needs to plan a development sprint, break down tasks, schedule game work, or organize a sprint with cross-discipline dependencies. Triggers on: "sprint plan", "task breakdown", "development planning", "scheduling", "sprint backlog". Do NOT invoke for scope evaluation (use game-scope-check) or retrospectives (use game-retrospective). Part of the AlterLab GameForge collection.
argument-hint
[milestone or focus area]
model
opus
effort
high
disable-model-invocation
true
allowed-tools
Read, Glob, Grep, Write, AskUserQuestion
version
1.3.0
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
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.
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.
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.
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.
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.
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.
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.
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
Break the sprint goal into implementable tasks. Each task must be small enough for one
person to complete in one day or less.
TASK DECOMPOSITION PROCESS
-------------------------------------------------
Step 2.1: List features needed to achieve the sprint goal
Step 2.2: For each feature, list the technical tasks
Step 2.3: For each technical task, break into sub-tasks until each is <= 1 day
Step 2.4: Add non-feature tasks (bug fixes, tech debt, reviews, meetings)
Step 2.5: Identify tasks that require discovery/research (estimate separately)
TASK FORMAT:
- ID: [SPRINT-001]
- Title: [clear, action-oriented name]
- Description: [what "done" looks like for this task]
- Estimate: [hours, max 8 for a full day]
- Owner: [person responsible]
- Discipline: [code / art / audio / design / QA]
- Dependencies: [list of task IDs this is blocked by]
- Scope tier: [Must / Should / Could]
ESTIMATION GUIDELINES:
- 1-2 hours: small, well-understood change (fix a known bug, add a config value)
- 3-4 hours: moderate task with clear requirements (implement a simple system)
- 5-6 hours: significant task with some unknowns (new feature with defined spec)
- 7-8 hours: full-day task at the complexity ceiling (decompose further if possible)
- > 8 hours: must be broken down into smaller tasks
DISCOVERY TASKS:
When a task involves unknown technology or untested approaches, create a
discovery task first: "Spike: determine if [approach] is feasible (max 4h)."
The spike produces information, not features. Schedule it before the
implementation task it informs.
-------------------------------------------------
Step 3: Dependency Mapping
Dependencies in game development are more complex than in most software because multiple
disciplines contribute to a single feature.
DEPENDENCY CHAIN ANALYSIS
-------------------------------------------------
TYPICAL GAME DEV DEPENDENCY CHAINS:
Design --> Art:
Game designer defines enemy behavior --> Artist creates enemy sprite/model
Level designer creates layout --> Environment artist builds the space
Art --> Code:
Artist delivers character sprites --> Programmer integrates animations
UI artist creates mockups --> Programmer implements interactive UI
Design --> Code:
Designer specifies mechanic --> Programmer implements system
Designer tunes values --> Programmer exposes tuning parameters
Code --> QA:
Programmer completes feature --> QA verifies correct behavior
Programmer fixes bug --> QA confirms fix and checks for regressions
Audio --> Code:
Audio designer creates sounds --> Programmer integrates audio triggers
MAPPING FORMAT:
[SPRINT-001] Design enemy patrol pattern
|
v (blocks)
[SPRINT-005] Create enemy patrol animation
|
v (blocks)
[SPRINT-009] Implement enemy patrol AI
|
v (blocks)
[SPRINT-012] QA: verify enemy patrol behavior
CRITICAL PATH:
The longest dependency chain determines the minimum sprint duration for
that feature. If the critical path is longer than the sprint, the feature
cannot be completed this sprint. Either rescope or split across sprints.
-------------------------------------------------
Step 4: Scope Tiering
Assign every task to a scope tier. This is the pressure-release valve that keeps
sprints from failing when reality diverges from plans.
SCOPE TIER DEFINITIONS
-------------------------------------------------
MUST-HAVE (sprint goal depends on this)
- If these tasks are not done, the sprint goal is not met
- These are scheduled first and protected from cuts
- Estimated effort for Must-Haves should not exceed 60% of capacity
SHOULD-HAVE (significantly enhances the sprint goal)
- The sprint goal is technically met without these, but weakened
- These are scheduled second and cut only under real pressure
- Estimated effort: up to 25% of remaining capacity after Must-Haves
COULD-HAVE (polish, nice-to-have, opportunistic improvements)
- Scheduled last, cut first, no guilt
- These are stretch goals for productive sprints
- Estimated effort: fills remaining capacity
WON'T-HAVE (explicitly deferred)
- Tasks that were considered and deliberately rejected for this sprint
- Writing these down prevents relitigating scope decisions mid-sprint
- "We already decided not to do that this sprint" is a powerful sentence
-------------------------------------------------
Step 5: Capacity Calculation
Determine how much work the team can actually do, not how much you wish they could do.
CAPACITY CALCULATION
-------------------------------------------------
For each team member:
Available days in sprint: [total days minus PTO, holidays, sick days]
Minus overhead (20%): [meetings, reviews, admin, build issues]
Effective person-days: [available * 0.8]
Effective person-hours: [person-days * productive hours per day]
Note: productive hours per day is typically 5-6, not 8.
The remaining 2-3 hours go to email, Slack, context switching,
and the unavoidable friction of being a human with a job.
TEAM CAPACITY:
Total effective hours: [sum of all team members]
Must-Have tasks: [total hours] ([%] of capacity)
Should-Have tasks: [total hours] ([%] of capacity)
Could-Have tasks: [total hours] ([%] of capacity)
Buffer (20%): [hours reserved]
Remaining: [positive or negative]
If remaining is negative: cut Could-Haves first, then Should-Haves
If still negative after cuts: the sprint goal itself is too ambitious.
Rescope the goal, do not just "try harder."
SOLO DEV ADJUSTMENTS:
Solo developers face unique overhead:
- No parallelism (all dependency chains are sequential)
- Every discipline switch has context-switching cost
- No rubber-ducking available (allocate more time for debugging)
- Apply an additional 10% buffer (30% total instead of 20%)
-------------------------------------------------
Step 6: Risk Identification
Name the top 3-5 risks for this specific sprint and define mitigations.
RISK ASSESSMENT
-------------------------------------------------
COMMON GAME DEV SPRINT RISKS:
Technical risks:
- "We've never built [system X] before and don't know the real complexity"
Mitigation: Schedule a spike task early in the sprint
- "The engine update might break existing functionality"
Mitigation: Pin the engine version for the sprint duration
- "Performance on target hardware is unknown"
Mitigation: Schedule a profiling session mid-sprint
Content risks:
- "The art assets won't be ready when code needs them"
Mitigation: Establish placeholder assets, code against placeholders
- "Level design iteration may require multiple art passes"
Mitigation: Use blocking geometry first, polish in a later sprint
Scope risks:
- "Stakeholder feedback mid-sprint could change requirements"
Mitigation: Define a change freeze date within the sprint
- "A Must-Have task is harder than estimated"
Mitigation: Identify which Should-Have to cut if Must-Have expands
Team risks:
- "Key person might be unavailable for part of the sprint"
Mitigation: Ensure no single-person bottlenecks on critical path
- "New team member ramp-up time is unpredictable"
Mitigation: Pair them with a senior member, reduce their capacity estimate
RISK FORMAT:
| Risk | Probability | Impact | Mitigation | Trigger (when to act) |
|------|------------|--------|------------|----------------------|
| [description] | H/M/L | H/M/L | [plan] | [observable signal] |
-------------------------------------------------
Step 7: Velocity Tracking
Compare planned work against actual completion from previous sprints to calibrate
future estimates.
VELOCITY TRACKING
-------------------------------------------------
PREVIOUS SPRINT DATA:
| Sprint | Planned (pts/hrs) | Completed | Completion Rate | Notes |
|--------|-------------------|-----------|-----------------|-------|
| N-3 | [amount] | [amount] | [%] | [context] |
| N-2 | [amount] | [amount] | [%] | [context] |
| N-1 | [amount] | [amount] | [%] | [context] |
| Avg | | | [avg %] | |
CALIBRATION RULES:
- If average completion rate is below 80%: you are chronically overcommitting.
Reduce this sprint's planned work by the gap percentage.
- If average completion rate is above 95%: you are undercommitting.
You can safely add a Should-Have or Could-Have item.
- If completion rate swings wildly (50% one sprint, 95% the next):
your estimation process is unreliable. Focus on improving estimates
before increasing velocity.
- First sprint (no history): plan conservatively. It is always better
to finish early and pull in stretch goals than to miss commitments.
ESTIMATION IMPROVEMENT:
After each sprint, compare estimated hours to actual hours for each task.
Track the ratio. Over time, you will learn your personal/team estimation
bias and can pre-correct for it.
-------------------------------------------------
📋 Solo Dev / Kanban Mode
Not every project needs Scrum. For solo developers or teams of two, the overhead of sprint ceremonies (planning meetings, standups, retrospectives with yourself) often exceeds their value. Kanban provides the same workflow discipline with less process friction.
When to use Kanban instead of Scrum:
Solo developer or team of 2 where sprint ceremonies would be a conversation with yourself
Projects with unpredictable task sizes (creative work, R&D-heavy prototyping)
Maintenance phases where work arrives continuously rather than in planned batches
When the overhead of sprint planning consistently takes longer than the sprint itself
The WIP (Work In Progress) limit is the critical constraint. For solo devs, a WIP limit of 2-3 prevents the "10 things started, nothing finished" anti-pattern. For a pair, WIP limit of 3-4 is appropriate. If you are tempted to increase the WIP limit, you are avoiding the discipline that makes Kanban work.
Discipline Swimlanes:
Organize your board with horizontal swimlanes by discipline: Code, Art, Audio, Design, Business. This makes context-switching visible. If your "In Progress" column has one card in Code, one in Art, and one in Business, you are paying three context-switching penalties simultaneously. Try to batch work by discipline when possible.
Weekly Review Cadence:
Instead of sprint retrospectives, hold a weekly review (even if it is just 15 minutes of self-reflection for solo devs):
What moved to Done this week?
What has been stuck in In Progress for more than 3 days? Why?
Is the WIP limit being respected, or are you cheating?
Does the Backlog still reflect actual priorities, or has it drifted?
Tool Recommendations:
HacknPlan -- purpose-built for game development, understands discipline categories
Codecks -- uses a card game metaphor, visually engaging, good for small teams
GitHub Projects -- free, integrates with your repository, good for code-heavy projects
Notion -- flexible, good for solo devs who want kanban + documentation in one place
MoSCoW Enforcement Percentages
Every sprint (or weekly kanban review) should verify that the planned work distribution follows these proportions:
Priority
Target Percentage
Purpose
Must
60% of capacity
Core deliverables that define sprint success
Should
25% of capacity
High-value enhancements that strengthen the sprint goal
Could
15% of capacity
Polish and stretch goals, cut first under pressure
Won't
0% of capacity
Explicitly deferred -- not in this sprint, no exceptions
If your Must-Have tasks exceed 60% of capacity, you are overcommitting on critical work and leaving no room for the unexpected. If Could-Have tasks creep above 15%, you are spending too much time on polish before the foundations are solid. Track these percentages explicitly in your sprint plan and review them during retrospectives.
Scope-Check Integration
When sprint velocity data suggests the team is consistently completing less than planned (completion rate below 75% for 3+ consecutive sprints), this is a scope creep signal. Before planning the next sprint:
Run /game-scope-check to assess whether the overall project scope has grown beyond the original estimate
Compare the current feature list against the original vertical slice definition
Identify features that were added after the initial plan without corresponding scope reduction elsewhere
Make an explicit cut/keep decision for each added feature before the next planning session
Output Format
The workflow produces a Sprint Plan Document. Reference templates/sprint-plan.md
for the full template.
# Sprint Plan## Sprint Identity-**Sprint Number:** [N]
-**Dates:** [start] to [end]
-**Duration:** [number of working days]
-**Sprint Goal:** [single sentence, pillar-aligned]
-**Milestone:** [which milestone this sprint serves]
## Team Capacity
| Team Member | Role | Available Days | Effective Hours |
|-------------|------|---------------|----------------|
| [name] | [discipline] | [days] | [hours] |
| **Total** | | | **[total hours]** |
## Task Board### Must-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|
| SPRINT-001 | [task] | [name] | [hours] | -- | Not Started |
### Should-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|
### Could-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|
### Won't-Have (Explicitly Deferred)- [feature/task] -- deferred because [reason]
## Dependency Map
[Visual or textual representation of blocking chains]
## Capacity Summary
| Tier | Estimated Hours | % of Capacity |
|------|----------------|--------------|
| Must-Have | [hours] | [%] |
| Should-Have | [hours] | [%] |
| Could-Have | [hours] | [%] |
| Buffer (20%) | [hours] | 20% |
| **Total** | **[hours]** | **[%]** |
## Risk Register
| Risk | Prob | Impact | Mitigation | Trigger |
|------|------|--------|-----------|---------|
| [risk] | H/M/L | H/M/L | [plan] | [signal] |
## Definition of Done (Sprint Level)- [ ] Sprint goal is achieved and demonstrable
- [ ] All Must-Have tasks are complete and verified
- [ ] No new Critical bugs introduced
- [ ] Updated tasks reflected in project tracking
- [ ] Sprint retrospective notes captured
## Definition of Done (Task Level)- [ ] Code compiles and runs without errors
- [ ] Feature matches specification / acceptance criteria
- [ ] Tests pass (where testing infrastructure exists)
- [ ] Code reviewed by at least one other developer (teams of 2+)
- [ ] No hardcoded gameplay values (data-driven per coding standards)
- [ ] Known issues documented if task is completed with caveats
Quality Criteria
A successful sprint plan meets all of these:
The sprint goal is a single sentence that is clearly evaluable as done or not done
Every task is estimated at 8 hours or less
Dependencies are mapped and blocking tasks are scheduled before dependent tasks
Must-Have tasks do not exceed 60% of effective capacity
The 20% buffer is applied after all estimation, not before
At least 3 risks are identified with specific mitigation plans
The plan references previous sprint velocity data (if available)
Scope tiers are assigned to every task, not just labeled on the categories
The Definition of Done is specific to this sprint, not a generic template
A solo developer or any team member can look at the plan and know exactly
what they should work on first, second, and third
Example Use Cases
"We need to plan our next 2-week sprint."
Full 7-step workflow. Start by defining the sprint goal against the current
milestone, decompose into tasks, map dependencies, calculate capacity, tier
scope, identify risks, and produce the sprint plan document.
"I'm a solo dev. Help me plan my next week."
Abbreviated workflow: define a focused goal, list 5-8 tasks, apply the solo
dev buffer (30%), and identify 1-2 risks. Solo sprints should be shorter
(1 week) to maintain focus and enable frequent course correction.
"We keep missing our sprint commitments. What's wrong?"
Focus on Step 7 (velocity tracking). Compare planned vs. actual across the
last 3-5 sprints. The pattern will reveal whether the problem is estimation,
scope creep, dependency blocking, or capacity overcommitment.
"We just finished brainstorming. How do we turn this concept into work?"
Use the concept document from game-brainstorm as input. The vertical slice
plan becomes the first sprint goal. Feature tiers from the concept map directly
to sprint scope tiers.
"Our artist is only available 2 days this sprint. How do we plan around that?"
Capacity calculation with constrained resources. Map art dependencies explicitly,
front-load art tasks to the artist's available days, ensure code tasks that depend
on art are scheduled after art delivery, and prepare placeholder assets as a
fallback mitigation.
