game-sprint-plan

AlterLab GameForge -- スプリント計画ワークフロー

ゲーム開発のスプリントが失敗する理由は、ソフトウェア開発のスプリントとは異なります。SaaS チームは、要件が不明確で優先順位が変わり続けることに苦労します。ゲーム開発チームは、分野をまたぐ依存関係と、「面白さ」が本質的に予測できないことに苦労します。インベントリシステムの仕様を完璧に定め、仕様どおりに開発しても、プレイテストでゲームをかえって悪くしていると分かることがあります。Supergiant のスプリントモデル（GDC の講演で紹介されています）は、各スプリントに明示的な「発見の時間」を設けることで、この問題に対処しています。つまり、開発したものが機能するかどうかだけでなく、実際にプレイして心地よく感じられるかを試すための時間を確保します。

ゲームのスプリント計画では、構造化された発見の時間、混乱を招かず柔軟に調整できる明確なスコープの段階、そしてアートから統合へと進むパイプラインの順序を尊重する依存関係モデルを組み込む必要があります。このワークフローでは、チームが実行できる具体的なスプリント計画書を作成します。

目的と実行のきっかけ

次の場合に、このワークフローを使用します：

• チームが新しい開発スプリントを始めようとしている
• 個人開発者が、次の1～2週間の作業を整理したい
• スプリントの振り返り後、次のイテレーションを計画するとき
• マイルストーンが近づき、作業を細分化する必要がある
• ユーザーが game-brainstorm または game-design-review を完了し、設計上の決定を実行可能なタスクに落とし込む必要がある

このワークフローで解決する問題：

• 完了したかどうかを評価できない、目標が曖昧なスプリント
• 「数日」と見積もったタスクに、実際には2週間かかること
• アートの完了を待つ必要があるのに、アートとコードのタスクを並行して計画していること
• 毎回のスプリントで、チームのキャパシティを超える作業を約束してしまうこと
• 振り返ると明らかだったリスクが、計画時には見えていないこと
• ベロシティを追跡していないため、毎回のスプリントで見積もりが当てずっぽうになること
• 小さな追加に見せかけたスコープクリープが積み重なり、締め切りに間に合わなくなること

重要なルール

1. 1スプリントにつき目標は1つです。 スプリント目標は、成功を定義する1文です。この目標を達成し、それ以外に何もできなかったとしても、そのスプリントは成功です。タスクリストのすべてを完了しても目標を達成できなければ、失敗です。Hades のアーリーアクセス期間中のスプリント目標は、体験を重視したものでした。「プレイヤーは、死んでも物語が進んでいると感じる」。この明確さによって、「たくさん作業したのに、完成したと感じられるものがない」というアンチパターンを防げます。

2. タスクは最大1日です。 1日を超える見積もりのタスクは、必ずさらに分解します。大きなタスクは複雑さを覆い隠し、見積もりに対する誤った安心感を生みます。1日を超えても分解できないと思われるタスクは、曖昧すぎるか、開発者が作業内容を十分に理解できていないかのどちらかです（後者自体が調査タスクです）。Motion Twin における Dead Cells の開発では、あらゆる作業を1日単位のタスクにしていました。新しいバイオームのような大規模な機能でさえ、明確な完了基準を設けた数十個の1日単位のタスクに分解されていました。

3. 20％のバッファーは必須です。 生の作業可能量を算出したら、そこから20％を差し引きます。これは、会議、コードレビュー、予期しないバグ、ビルドの問題、ハードウェアの問題、そして共同作業に伴う一般的な摩擦を見込むためのものです。バッファーを設けないチームは、常に過剰な作業を引き受け、常に期待を下回る成果しか出せません。個人開発者も例外ではありません。コンテキストの切り替え、調査の寄り道、「ついでにこれを1つだけリファクタリングしよう」といったことも、すべて時間を消費します。

4. 依存関係は最優先で考慮します。 別のタスクにブロックされているタスクは、着手できる状態ではありません。依存関係を明示的に整理し、クリティカルパスを特定して、ブロックするタスクを先にスケジュールします。ゲーム開発で最も一般的な依存関係の連鎖は、次のとおりです。 デザイン仕様 --> アート／オーディオ素材の制作 --> コードへの統合 --> QA による検証。

5. スコープの段階分けによって柔軟性を確保できます。 スプリント内のすべての項目が同じ優先度とは限りません。Must／Should／Could／Won't の段階を使い、状況が変わったときに何から削るべきかをチーム全員が把握できるようにします。水曜日に Could-Have を削るのは、健全なスコープ管理です。金曜日に Must-Have を削るのは、危機的な状況です。

6. 希望的な速度より、実際の速度を正直に見積もります。 チームが直近3回のスプリントで平均30ストーリーポイントを完了しているなら、今スプリントで45ポイントを計画するのは、野心的なのではなく、現実離れしています。期待する速度ではなく、実際の過去の速度を使います。Larian による BG3 のマイルストーンベースの開発がうまくいったのは、速度を徹底的に記録し、それに応じてスコープを調整したからです。さらに残業を重ねたからではありません。

7. デザインの柱と整合させます。 すべてのスプリント目標は、デザインの柱に結び付いています。どの柱にも貢献しないスプリント目標がある場合、チームはインフラに取り組んでいる（問題ありませんが、その旨を明示します）か、ビジョンから逸脱しています（議論のために取り上げます）。Supergiant のスプリント目標は、機能の一覧ではなく、常にプレイヤー体験を表す文で定義されています。「武器システムを実装する」ではなく、「プレイヤーが、選んだ武器の重みを感じる」です。柱の策定方法については docs/game-design-theory.md を、分野横断の連携ルールについては docs/collaboration-protocol.md を参照してください。

スプリントのコンテキスト（自動入力）

これらの値は、スキルの内容が Claude に届く前に、シェルによる前処理で自動的に挿入されます。 リアルタイムのプロジェクトデータを提供し、記憶や推測ではなく、コードベースの実際の状態に基づいて スプリント計画を開始できるようにします。

• 最近のコミット：!git log --oneline -20 2>/dev/null || echo "No git history"
• 未解決の issue：!gh issue list --limit 10 --state open 2>/dev/null || echo "No GitHub issues accessible"
• 前回のスプリント：!cat production/session-state/last-sprint.json 2>/dev/null || echo "No previous sprint data"
• チームのベロシティ：!cat production/session-state/velocity.json 2>/dev/null || echo "No velocity data"
• アクティブなブランチ：!git branch --list 2>/dev/null | head -10 || echo "No branches detected"
• 未コミットの変更：!git status --short 2>/dev/null | wc -l || echo "0"
• 最後のタグからの日数：!git log --tags --simplify-by-decoration --pretty="format:%ar" 2>/dev/null | head -1 || echo "No tags — no milestone history"
• 現在のマイルストーンファイル：!ls production/milestones/ 2>/dev/null | tail -3 || echo "No milestone directory"

この自動入力データを使って、スプリント計画の判断に役立ててください。最近のコミットから、 最近完了した作業や、コードベースで活発な領域がわかります。未解決の issue は バックログ候補になります。前回のスプリントデータとベロシティの JSON により、 データに基づくキャパシティ計画が可能になります（ステップ 5 とステップ 7 を参照）。 アクティブなブランチからは、現在進行中で、このスプリントに持ち越される可能性のある作業がわかります。 最後のタグからの日数は、前回の正式なマイルストーンからどれくらい経過したかを示し、 スプリントの範囲を調整するのに役立ちます。

ベロシティデータが利用できない場合（初回のスプリント）は、慎重に計画し、 このスプリントで基準値を確立してください。前回のスプリントデータがある場合は、 計画と完了実績を比較し、今回のスプリントでのコミットメントを調整してください。

ワークフロー

ステップ 1：スプリント目標の定義

スプリント目標は、タスクリストの要約ではありません。ゲームの設計の柱や現在のマイルストーンに 結び付いた、スプリントの戦略的な目的です。

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]
-------------------------------------------------

ステップ 2：タスクの分解

スプリント目標を実装可能なタスクに分解します。各タスクは、1 人で 1 日以内に完了できる 大きさにしてください。

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

ステップ 3：依存関係のマッピング

ゲーム開発における依存関係は、1 つの機能に複数の専門分野が関わるため、 ほとんどのソフトウェア開発より複雑です。

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

ステップ 4：スコープの段階分け

すべてのタスクをスコープの段階に割り当てます。これは、現実が計画と食い違ったときに スプリントの失敗を防ぐ、圧力を逃がす仕組みです。

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
-------------------------------------------------

ステップ 5：キャパシティの算出

チームが実際にどれだけ作業できるかを判断します。どれだけ作業してほしいかではありません。

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%)
-------------------------------------------------

ステップ 6：リスクの特定

このスプリント固有の上位 3～5 件のリスクを挙げ、軽減策を定義します。

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] |
-------------------------------------------------

ステップ 7：ベロシティの追跡

前回のスプリントで計画した作業と実際の完了状況を比較し、 今後の見積もりを調整します。

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

📋 ソロ開発者／カンバンモード

すべてのプロジェクトにスクラムが必要なわけではありません。ソロ開発者や 2 人のチームでは、スプリントのセレモニー（計画会議、朝会、自分自身との振り返り）にかかる負担が、その価値を上回ることがよくあります。カンバンなら、プロセス上の負担を抑えながら、同じワークフローの規律を保てます。

スクラムではなくカンバンを使う場合：

• ソロ開発者、またはスプリントのセレモニーが自分自身との対話になってしまう 2 人チーム
• タスクの規模が予測しにくいプロジェクト（クリエイティブな作業、R&D 中心のプロトタイピング）
• 作業が計画的な一括単位ではなく、継続的に発生する保守フェーズ
• スプリント計画の負担が、スプリント自体よりも常に長くかかる場合

カンバンボードの構成：

Backlog --> In Progress (WIP limit: 2-3) --> Testing --> Done

WIP（進行中の作業）制限は、重要な制約です。ソロ開発者の場合、WIP 制限を 2～3 にすると、「10 件に着手して何も完了しない」というアンチパターンを防げます。ペアで作業する場合は、WIP 制限を 3～4 にするのが適切です。WIP 制限を増やしたくなったら、カンバンを機能させる規律を避けようとしているのかもしれません。 分野別スイムレーン： ボードを、コード、アート、オーディオ、デザイン、ビジネスなど、分野ごとの水平スイムレーンで整理します。これにより、コンテキストスイッチが可視化されます。「進行中」列にコード、アート、ビジネスのカードが1枚ずつある場合、同時に3回分のコンテキストスイッチの負担が発生しています。可能であれば、分野ごとに作業をまとめて進めてみてください。

週次レビューの頻度： スプリントの振り返りの代わりに、毎週レビューを行います（個人開発者の場合は、15分間の自己振り返りだけでも構いません）。

• 今週、完了に移ったものは何ですか？
• 3日を超えて進行中のままのものは何ですか？その理由は何ですか？
• WIP制限は守られていますか？それとも、都合よく破っていませんか？
• バックログには今も実際の優先順位が反映されていますか？それとも、ずれてきていますか？

ツールのおすすめ：

• HacknPlan -- ゲーム開発向けに特化しており、分野別のカテゴリーに対応しています
• Codecks -- カードゲームのメタファーを使っており、見た目にも楽しく、小規模チームに適しています
• GitHub Projects -- 無料で、リポジトリと連携でき、コード中心のプロジェクトに適しています
• Notion -- 柔軟性があり、カンバンとドキュメントを1か所にまとめたい個人開発者に適しています

MoSCoWの適用比率

各スプリント（または週次カンバンレビュー）で、計画した作業の配分が以下の割合に従っているか確認します。

優先度	目標割合	目的
必須（Must）	キャパシティの60%	スプリントの成功を定義する中核となる成果物
すべき（Should）	キャパシティの25%	スプリント目標を強化する価値の高い改善
できれば（Could）	キャパシティの15%	仕上げやストレッチ目標。余裕がないときは最初に削減
対象外（Won't）	キャパシティの0%	明示的に延期した項目。例外なく、このスプリントには含めません

必須タスクがキャパシティの60%を超えている場合、重要な作業を詰め込みすぎており、予期せぬ事態に対応する余地がありません。できれば対応したいタスクが15%を超えている場合、基盤が固まる前に仕上げに時間をかけすぎています。スプリント計画でこれらの割合を明示的に記録し、振り返りの際に確認してください。

スコープチェックの統合

スプリントのベロシティデータから、チームが計画した作業を一貫して完了できていないこと（完了率が3回以上連続して75%未満）が示された場合、これはスコープクリープの兆候です。次のスプリントを計画する前に、以下を行います。

• /game-scope-check を実行し、プロジェクト全体のスコープが当初の見積もりを超えて拡大しているか評価します
• 現在の機能リストと、当初定義した垂直スライスを比較します
• 初期計画後に追加され、ほかの項目でスコープを同等に縮小していない機能を特定します
• 次の計画セッションの前に、追加した各機能について、明確に削除するか維持するかを決定します

出力形式

このワークフローでは、スプリント計画書を作成します。完全なテンプレートについては templates/sprint-plan.md を参照してください。

# 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

品質基準

スプリント計画が成功しているといえるのは、以下のすべてを満たす場合です。

• スプリント目標が、達成か未達成かを明確に評価できる1文になっている
• すべてのタスクの見積もりが8時間以下である
• 依存関係が整理され、ブロッキングタスクが依存するタスクより先に予定されている
• 必須タスクが実効キャパシティの60%を超えていない
• 20%のバッファが、すべての見積もりの後に適用されている
• 具体的な軽減策を含むリスクが少なくとも3つ特定されている
• （利用可能な場合）計画に前回のスプリントのベロシティデータが記載されている
• スコープ階層がカテゴリーだけでなく、すべてのタスクに割り当てられている
• 完了の定義が一般的なテンプレートではなく、このスプリントに固有のものになっている
• 個人開発者やチームメンバーが誰でも計画を見て、最初に何に取り組み、次に何に取り組み、その次に何に取り組むべきかを正確に把握できる

使用例

1. 「次の2週間のスプリントを計画する必要があります。」 7ステップすべてのワークフローです。まず現在のマイルストーンに沿ってスプリントの目標を定め、タスクに分解し、依存関係を整理し、キャパシティを算出して、スコープを優先度別に分類し、リスクを特定して、スプリント計画書を作成します。

2. 「私はひとりで開発しています。来週の計画を立てるのを手伝ってください。」 簡略化したワークフローです。重点的な目標を設定し、5～8個のタスクをリストアップして、ひとり開発向けのバッファ（30％）を適用し、1～2個のリスクを特定します。集中力を維持し、頻繁に軌道修正できるよう、ひとり開発のスプリントは短め（1週間）にするのがよいでしょう。

3. 「スプリントのコミットメントを何度も達成できません。何が問題なのでしょうか？」 ステップ7（ベロシティの追跡）に焦点を当てます。直近3～5回のスプリントについて、計画と実績を比較します。その傾向から、見積もり、スコープの拡大、依存関係によるブロック、キャパシティの過剰な割り当てのどれが問題なのかが明らかになります。

4. 「ブレインストーミングを終えたところです。このコンセプトをどうすれば作業に落とし込めますか？」 game-brainstormのコンセプトドキュメントを入力として使用します。垂直スライスの計画を最初のスプリント目標とします。コンセプト内の機能の優先度は、スプリントのスコープの優先度にそのまま対応します。

5. 「今回のスプリントでは、アーティストが2日しか作業できません。それを踏まえてどう計画すればよいでしょうか？」 リソースに制約がある状態でキャパシティを算出します。アートの依存関係を明示的に整理し、アーティストが作業できる日にアートタスクを前倒しで配置し、アートの納品に依存するコードタスクは納品後にスケジュールして、予備策としてプレースホルダーアセットを準備します。