SKILLKnowledge Work

sprint-planning

プラグイン: Product Management
引数: [sprint name or date range]
ソース: GitHub で見る ↗

説明

スプリント（短期間の開発期間）を計画する — 作業の範囲を決め、チームの対応能力を見積もり、目標を設定し、スプリント計画案を作成します。次のような場合に使用: - 新しいスプリントを開始するとき - バックログ（未実施の作業リスト）をチームの人数や有休休暇・会議の予定に合わせて調整するとき - どの作業を優先（P0）にするか、または伸ばしてもよい目標にするか判断するとき - 前のスプリントから持ち越した作業を処理するとき

原文を表示

Plan a sprint — scope work, estimate capacity, set goals, and draft a sprint plan. Use when kicking off a new sprint, sizing a backlog against team availability (accounting for PTO and meetings), deciding what's P0 vs. stretch, or handling carryover from the last sprint.

ユースケース

新しいスプリントを開始するとき
バックログをチーム体制に合わせるとき
作業の優先順位を判断するとき
前スプリントからの持ち越し作業を処理するとき

本文（日本語訳）

/sprint-planning

見慣れないプレースホルダーが表示された場合や、接続済みのツールを確認したい場合は、CONNECTORS.md を参照してください。

作業範囲の策定、キャパシティの見積もり、明確なゴール設定を通じて、スプリントを計画します。

使い方

/sprint-planning $ARGUMENTS

仕組み

┌─────────────────────────────────────────────────────────────────┐
│                    スプリント計画                                   │
├─────────────────────────────────────────────────────────────────┤
│  スタンドアロン（常に利用可能）                                      │
│  ✓ スプリントゴールと成功基準の定義                                  │
│  ✓ チームキャパシティの見積もり（PTO・会議を考慮）                    │
│  ✓ バックログアイテムのスコープ設定と優先順位付け                     │
│  ✓ 依存関係とリスクの特定                                           │
│  ✓ スプリント計画ドキュメントの生成                                  │
├─────────────────────────────────────────────────────────────────┤
│  スーパーチャージ（ツール連携時）                                     │
│  + プロジェクトトラッカー: バックログ取得・スプリント作成・アイテム割り当て │
│  + カレンダー: キャパシティ計算にPTOと会議を反映                      │
│  + チャット: チームへのスプリント計画の共有                            │
└─────────────────────────────────────────────────────────────────┘

必要な情報

チーム: メンバーは誰で、今スプリントの稼働状況は？
スプリント期間: 何日 / 何週間？
バックログ: 優先順位付けされたアイテムは？（トラッカーから取得・貼り付け・口頭説明、いずれも可）
キャリーオーバー: 前スプリントから未完了のものはある？
依存関係: 他チームにブロックされているものはある？

出力形式

## スプリント計画: [スプリント名]
**期間:** [開始日] — [終了日] | **チーム:** エンジニア [X] 名
**スプリントゴール:** [成功の姿を表す一文]

### キャパシティ
| 担当者 | 稼働日数 | アロケーション | 備考 |
|--------|---------|--------------|------|
| [名前] | [Y] 日中 [X] 日 | [X] ポイント / 時間 | [PTO・オンコール等] |
| **合計** | **[X]** | **[X] ポイント** | |

### スプリントバックログ
| 優先度 | アイテム | 見積もり | 担当者 | 依存関係 |
|--------|---------|---------|--------|---------|
| P0 | [必須リリース] | [X] pts | [担当者] | [なし / X によりブロック] |
| P1 | [リリース予定] | [X] pts | [担当者] | [なし] |
| P2 | [ストレッチ] | [X] pts | [担当者] | [なし] |

### 計画キャパシティ: [X] ポイント | スプリント負荷: [X] ポイント（キャパシティの [X]%）

### リスク
| リスク | 影響 | 対策 |
|--------|------|------|
| [リスク] | [発生する事象] | [対応策] |

### 完了の定義
- [ ] コードレビュー済み・マージ済み
- [ ] テスト通過
- [ ] ドキュメント更新済み（該当する場合）
- [ ] プロダクトサインオフ済み

### 主要な日程
| 日付 | イベント |
|------|---------|
| [日付] | スプリント開始 |
| [日付] | 中間チェックイン |
| [日付] | スプリント終了 / デモ |
| [日付] | レトロスペクティブ |

ヒント

バッファを確保する — キャパシティの 70〜80% で計画する。割り込みは必ず発生します。
スプリントゴールは一つに絞る — 一文で言い表せないなら、スプリントの焦点が定まっていないサインです。
ストレッチアイテムを明確にする — 想定より時間がかかった場合に何を削るか、あらかじめ決めておく。
キャリーオーバーは正直に扱う — 未完了のものがあれば、再コミットする前にその原因を理解する。

原文（English）を表示

/sprint-planning

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Plan a sprint by scoping work, estimating capacity, and setting clear goals.

Usage

/sprint-planning $ARGUMENTS

How It Works

┌─────────────────────────────────────────────────────────────────┐
│                    SPRINT PLANNING                                 │
├─────────────────────────────────────────────────────────────────┤
│  STANDALONE (always works)                                       │
│  ✓ Define sprint goals and success criteria                     │
│  ✓ Estimate team capacity (accounting for PTO, meetings)        │
│  ✓ Scope and prioritize backlog items                           │
│  ✓ Identify dependencies and risks                              │
│  ✓ Generate sprint plan document                                │
├─────────────────────────────────────────────────────────────────┤
│  SUPERCHARGED (when you connect your tools)                      │
│  + Project tracker: Pull backlog, create sprint, assign items   │
│  + Calendar: Account for PTO and meetings in capacity           │
│  + Chat: Share sprint plan with the team                        │
└─────────────────────────────────────────────────────────────────┘

What I Need From You

Team: Who's on the team and their availability this sprint?
Sprint length: How many days/weeks?
Backlog: What's prioritized? (Pull from tracker, paste, or describe)
Carryover: Anything unfinished from last sprint?
Dependencies: Anything blocked on other teams?

Output

## Sprint Plan: [Sprint Name]
**Dates:** [Start] — [End] | **Team:** [X] engineers
**Sprint Goal:** [One clear sentence about what success looks like]

### Capacity
| Person | Available Days | Allocation | Notes |
|--------|---------------|------------|-------|
| [Name] | [X] of [Y] | [X] points/hours | [PTO, on-call, etc.] |
| **Total** | **[X]** | **[X] points** | |

### Sprint Backlog
| Priority | Item | Estimate | Owner | Dependencies |
|----------|------|----------|-------|--------------|
| P0 | [Must ship] | [X] pts | [Person] | [None / Blocked by X] |
| P1 | [Should ship] | [X] pts | [Person] | [None] |
| P2 | [Stretch] | [X] pts | [Person] | [None] |

### Planned Capacity: [X] points | Sprint Load: [X] points ([X]% of capacity)

### Risks
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [What happens] | [What to do] |

### Definition of Done
- [ ] Code reviewed and merged
- [ ] Tests passing
- [ ] Documentation updated (if applicable)
- [ ] Product sign-off

### Key Dates
| Date | Event |
|------|-------|
| [Date] | Sprint start |
| [Date] | Mid-sprint check-in |
| [Date] | Sprint end / Demo |
| [Date] | Retro |

Tips

Leave buffer — Plan to 70-80% capacity. You will get interrupts.
One clear sprint goal — If you can't state it in one sentence, the sprint is unfocused.
Identify stretch items — Know what to cut if things take longer than expected.
Carry over honestly — If something didn't ship, understand why before re-committing.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。

/sprint-planning

見慣れないプレースホルダーが表示された場合や、接続済みのツールを確認したい場合は、CONNECTORS.md を参照してください。

作業範囲の策定、キャパシティの見積もり、明確なゴール設定を通じて、スプリントを計画します。

仕組み

┌─────────────────────────────────────────────────────────────────┐ │ スプリント計画 │ ├─────────────────────────────────────────────────────────────────┤ │ スタンドアロン（常に利用可能） │ │ ✓ スプリントゴールと成功基準の定義 │ │ ✓ チームキャパシティの見積もり（PTO・会議を考慮） │ │ ✓ バックログアイテムのスコープ設定と優先順位付け │ │ ✓ 依存関係とリスクの特定 │ │ ✓ スプリント計画ドキュメントの生成 │ ├─────────────────────────────────────────────────────────────────┤ │ スーパーチャージ（ツール連携時） │ │ + プロジェクトトラッカー: バックログ取得・スプリント作成・アイテム割り当て │ │ + カレンダー: キャパシティ計算にPTOと会議を反映 │ │ + チャット: チームへのスプリント計画の共有 │ └─────────────────────────────────────────────────────────────────┘

必要な情報

チーム: メンバーは誰で、今スプリントの稼働状況は？

スプリント期間: 何日 / 何週間？

バックログ: 優先順位付けされたアイテムは？（トラッカーから取得・貼り付け・口頭説明、いずれも可）

キャリーオーバー: 前スプリントから未完了のものはある？

依存関係: 他チームにブロックされているものはある？

出力形式

## スプリント計画: [スプリント名] **期間:** [開始日] — [終了日] | **チーム:** エンジニア [X] 名 **スプリントゴール:** [成功の姿を表す一文] ### キャパシティ | 担当者 | 稼働日数 | アロケーション | 備考 | |--------|---------|--------------|------| | [名前] | [Y] 日中 [X] 日 | [X] ポイント / 時間 | [PTO・オンコール等] | | **合計** | **[X]** | **[X] ポイント** | | ### スプリントバックログ | 優先度 | アイテム | 見積もり | 担当者 | 依存関係 | |--------|---------|---------|--------|---------| | P0 | [必須リリース] | [X] pts | [担当者] | [なし / X によりブロック] | | P1 | [リリース予定] | [X] pts | [担当者] | [なし] | | P2 | [ストレッチ] | [X] pts | [担当者] | [なし] | ### 計画キャパシティ: [X] ポイント | スプリント負荷: [X] ポイント（キャパシティの [X]%） ### リスク | リスク | 影響 | 対策 | |--------|------|------| | [リスク] | [発生する事象] | [対応策] | ### 完了の定義 - [ ] コードレビュー済み・マージ済み - [ ] テスト通過 - [ ] ドキュメント更新済み（該当する場合） - [ ] プロダクトサインオフ済み ### 主要な日程 | 日付 | イベント | |------|---------| | [日付] | スプリント開始 | | [日付] | 中間チェックイン | | [日付] | スプリント終了 / デモ | | [日付] | レトロスペクティブ |

ヒント

バッファを確保する — キャパシティの 70〜80% で計画する。割り込みは必ず発生します。

スプリントゴールは一つに絞る — 一文で言い表せないなら、スプリントの焦点が定まっていないサインです。

ストレッチアイテムを明確にする — 想定より時間がかかった場合に何を削るか、あらかじめ決めておく。

キャリーオーバーは正直に扱う — 未完了のものがあれば、再コミットする前にその原因を理解する。

How It Works

┌─────────────────────────────────────────────────────────────────┐ │ SPRINT PLANNING │ ├─────────────────────────────────────────────────────────────────┤ │ STANDALONE (always works) │ │ ✓ Define sprint goals and success criteria │ │ ✓ Estimate team capacity (accounting for PTO, meetings) │ │ ✓ Scope and prioritize backlog items │ │ ✓ Identify dependencies and risks │ │ ✓ Generate sprint plan document │ ├─────────────────────────────────────────────────────────────────┤ │ SUPERCHARGED (when you connect your tools) │ │ + Project tracker: Pull backlog, create sprint, assign items │ │ + Calendar: Account for PTO and meetings in capacity │ │ + Chat: Share sprint plan with the team │ └─────────────────────────────────────────────────────────────────┘

Output

## Sprint Plan: [Sprint Name] **Dates:** [Start] — [End] | **Team:** [X] engineers **Sprint Goal:** [One clear sentence about what success looks like] ### Capacity | Person | Available Days | Allocation | Notes | |--------|---------------|------------|-------| | [Name] | [X] of [Y] | [X] points/hours | [PTO, on-call, etc.] | | **Total** | **[X]** | **[X] points** | | ### Sprint Backlog | Priority | Item | Estimate | Owner | Dependencies | |----------|------|----------|-------|--------------| | P0 | [Must ship] | [X] pts | [Person] | [None / Blocked by X] | | P1 | [Should ship] | [X] pts | [Person] | [None] | | P2 | [Stretch] | [X] pts | [Person] | [None] | ### Planned Capacity: [X] points | Sprint Load: [X] points ([X]% of capacity) ### Risks | Risk | Impact | Mitigation | |------|--------|------------| | [Risk] | [What happens] | [What to do] | ### Definition of Done - [ ] Code reviewed and merged - [ ] Tests passing - [ ] Documentation updated (if applicable) - [ ] Product sign-off ### Key Dates | Date | Event | |------|-------| | [Date] | Sprint start | | [Date] | Mid-sprint check-in | | [Date] | Sprint end / Demo | | [Date] | Retro |

Tips

Leave buffer — Plan to 70-80% capacity. You will get interrupts.

One clear sprint goal — If you can't state it in one sentence, the sprint is unfocused.

Identify stretch items — Know what to cut if things take longer than expected.

Carry over honestly — If something didn't ship, understand why before re-committing.