Agent-almanac plan-sprint

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/plan-sprint" ~/.claude/skills/pjt222-agent-almanac-plan-sprint-862e72 && rm -rf "$T"

manifest: i18n/ja/skills/plan-sprint/SKILL.md

source content

スプリントの計画

チームのキャパシティまでの改善済みバックログアイテムを選択し、明確なスプリントゴールを定義し、選択したアイテムを実行可能なタスクに分解することで、タイムボックス化されたスプリントを計画します。このスキルは、スプリントのイテレーション期間中のチームの作業を導く完全なスプリント計画を作成します。

使用タイミング

Scrumまたはアジャイルプロジェクトでのスプリント開始時
重大なスコープ変更後のスプリントの再計画時
アドホック作業から構造化スプリントサイクルへの移行時
バックロググルーミング後にアイテムがスプリントへの追加準備が完了した時
プロジェクト憲章承認後の最初のスプリントの計画時

入力

必須: プロダクトバックログ（優先順位付き、見積もり済み）
必須: スプリント期間（通常1〜2週間）
必須: チームメンバーとその稼働状況
任意: 過去のスプリントベロシティ（完了したストーリーポイントまたはアイテム数）
任意: スプリント番号と日付範囲
任意: 前のスプリントからの繰り越しアイテム

手順

ステップ1: バックログアイテムのレビューと改善

現在のBACKLOG.mdを読みます。バックログ上部付近の各候補アイテムについて、以下を確認します:

明確なタイトルと説明
受け入れ基準（テスト可能な条件）
見積もり（ストーリーポイントまたはTシャツサイズ）
未解決のブロッカーがないこと

これらの要素が欠けているアイテムを改善します。スプリントキャパシティの半分より大きく見積もられているアイテムを、より小さく管理しやすいものに分割します。

期待結果： バックログ上位10〜15件のアイテムが受け入れ基準と見積もりを持つ「スプリント準備完了」状態になっている。

失敗時： アイテムに受け入れ基準がない場合は今すぐ書きます。アイテムが見積もれない場合は改善の会話をスケジュールし、準備完了のアイテムのみ選択します。

ステップ2: スプリントゴールを定義する

スプリントが何を達成するかを述べる1つの明確なスプリントゴール（1文）を書きます。ゴールは以下であるべきです:

スプリント期間内で達成可能
ステークホルダーにとって価値がある
テスト可能（スプリント終了時に達成されたか確認できる）

**Sprint Goal**: [One sentence describing the objective]

例：「二要素認証を使ったメール確認でユーザーがパスワードをリセットできるようにする。」

期待結果： スプリントゴールが1つの明確でテスト可能な文として表現されている。

失敗時： 一貫したゴールが生まれない場合、バックログの優先順位がばらばらである可能性があります — 1つの価値ある成果に集中するようプロダクトオーナーに相談します。

ステップ3: チームのキャパシティを計算する

各チームメンバーの利用可能な人日を計算します:

## Team Capacity
| Team Member | Available Days | Overhead (%) | Net Capacity |
|-------------|---------------|-------------|--------------|
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| **Total** | | | **[Sum] person-days** |

オーバーヘッドは会議、レビュー、アドホックリクエストを考慮します（通常15〜25%）。

ストーリーポイントを使用する場合：前のスプリントのベロシティをキャパシティとして使用します。最初のスプリントの場合は、理論上の最大値の60〜70%を使用します。

期待結果： キャパシティが人日またはストーリーポイントで計算され、仮定が文書化されている。

失敗時： 過去のベロシティがない場合、保守的に計画します — キャパシティの60%で計画し、スプリント後に調整します。過少コミットして達成する方が、過剰コミットして失敗するよりも良いです。

ステップ4: アイテムを選択してスプリントバックログを構成する

キャパシティに達するまでプロダクトバックログの上位からアイテムを選択します。各選択アイテムをタスクに分解します（各2〜8時間）:

# Sprint Plan: Sprint [N]
## Document ID: SP-[PROJECT]-S[NNN]

### Sprint Details
- **Sprint Goal**: [From Step 2]
- **Duration**: [Start date] to [End date]
- **Capacity**: [From Step 3] person-days / [N] story points
- **Team**: [List team members]

### Sprint Backlog
| ID | Item | Points | Tasks | Assignee | Status |
|----|------|--------|-------|----------|--------|
| B-001 | [Item title] | 5 | 4 | [Name] | To Do |
| B-002 | [Item title] | 3 | 3 | [Name] | To Do |
| B-003 | [Item title] | 8 | 6 | [Name] | To Do |
| **Total** | | **16** | **13** | | |

### Task Breakdown

#### B-001: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (4h, [Assignee])
- [ ] Task 2: [Description] (2h, [Assignee])
- [ ] Task 3: [Description] (4h, [Assignee])
- [ ] Task 4: [Description] (2h, [Assignee])

#### B-002: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])

#### B-003: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])
- [ ] Task 4: [Description] (3h, [Assignee])
- [ ] Task 5: [Description] (4h, [Assignee])
- [ ] Task 6: [Description] (2h, [Assignee])

### Risks and Dependencies
| Risk | Impact | Mitigation |
|------|--------|-----------|
| [Risk 1] | [Impact] | [Mitigation] |
| [Risk 2] | [Impact] | [Mitigation] |

### Carry-Over from Previous Sprint
| ID | Item | Reason | Remaining Effort |
|----|------|--------|-----------------|
| B-XXX | [Item] | [Reason] | [Hours/points] |

期待結果： キャパシティまでのアイテムが選択され、各アイテムが時間見積もり付きのタスクに分解されたスプリントバックログ。

失敗時： 合計ポイントがキャパシティを超える場合、最も優先度の低いアイテムを削除します。キャパシティを10%以上超えないようにします。依存関係が順序付けをブロックする場合、アイテムを並べ替えるか延期します。

ステップ5: コミットメントを文書化して保存する

スプリント計画を

SPRINT-PLAN.md

（アーカイブ用には

SPRINT-PLAN-S[NNN].md

）に書き込みます。以下を確認します:

スプリントゴールが選択されたアイテムで達成可能
チームメンバーが過剰割り当て（100%超）でない
アイテム間の依存関係が正しく順序付けられている
繰り越しアイテムがキャパシティに考慮されている
すべての受け入れ基準がバックログアイテムからコピーされている

最終検証を実行します:

# Check that total task hours align with capacity
grep -A 100 "Task Breakdown" SPRINT-PLAN.md | grep -o '([0-9]*h' | sed 's/[^0-9]//g' | awk '{sum+=$1} END {print "Total hours:", sum}'

期待結果： 完全なスプリントバックログとタスク内訳を含むSPRINT-PLAN.mdが作成されている。合計時間は利用可能な人日×8時間の80%以下であるべきです。

失敗時： コミットメントがゴールに整合しない場合、ステップ4のアイテム選択を見直します。タスク時間がキャパシティを超える場合、最後のアイテムを削除するか、タスクをより細かく分解します。

バリデーション

よくある落とし穴

スプリントゴールなし: ゴールがなければ、スプリントはタスクの袋に過ぎません。ゴールはスプリント中のスコープ決定のための焦点と根拠を提供します。
過剰コミット: 100%キャパシティで計画すると、中断、バグ、オーバーヘッドが考慮されません。予期せぬことへのバッファを残すために70〜80%で計画します。
タスクが大きすぎる: 8時間を超えるタスクは複雑さを隠し、進捗追跡を困難にします。タスクが2〜8時間になるまで分解します。
繰り越しの無視: 前のスプリントからの未完了アイテムは今のスプリントのキャパシティを消費します。キャパシティ計算で明示的に考慮します。
アイテムリストとしてのスプリントゴール: 「B-001、B-002、B-003を完了する」はゴールではありません。ゴールは成果を説明します：「ユーザーがメール確認でパスワードをリセットできる。」
タスクの担当者なし: キャパシティの競合を早期に把握するために、計画時にすべてのタスクに担当者が割り当てられるべきです。
受け入れ基準のスキップ: 受け入れ基準のないタスクはテストできません。バックログアイテムからタスク内訳セクションに受け入れ基準をコピーします。