sprint-planning

スプリント計画スキル

未整理のバックログ項目を、明確な目標、ベロシティに合わせて調整したスコープ、チームがすぐに使える成果物を備えた、実現可能なスプリントにまとめます。

Brain の読み込み／書き込み

professional-brain（brain/）がある場合は、すでに把握していることを再確認するのではなく、そこにある情報を基に計画します。

• 最初に読む： 優先度の高い decisions/（チームが重要だと合意した内容）、機能に関する entities/、およびスプリントで検証できる未解決の hypotheses/ を確認します。python3 ../professional-brain/scripts/brain_query.py ./brain "<sprint goal>" を実行し、各事実の出典タグを引き継ぎます。
• 📥 Brain への提案： 計画を作成した後、スプリントのコミットメント（目標＋コミット済みスコープ）を出典タグ付きの decisions/ レコードとして記録することを提案します。内容を提示して承認を得てから、../professional-brain/scripts/brain_write.py … --commit で書き込みます（追記専用で、デフォルトはドライランです）。

アクションの提案

スプリントの内容が合意されたら、action-runner に引き渡します。action-runner はリスク評価付きのプレビュー（ドライラン）を行い、接続済みのアクション MCP を通じて承認されたアクションのみを実行し、実施内容を Brain に記録します。一般的なアクションは、コミット済みのバックログ項目ごとにチケットを作成することと、スプリントのマイルストーンを設定することです（🟡）。このスキルは提案を行い、実行の可否を判断して実行するのは action-runner です。決して、通知せずに実行することはありません。

このスキルが生成するもの

• スプリント目標 — チーム全体が目指せる、成果を重視した簡潔な一文
• スプリントバックログ — 優先順位、ストーリーポイントの見積もり、受け入れ基準を含むユーザーストーリーのリスト
• キャパシティ計画 — 休日、会議、集中作業時間を考慮したチームの稼働可能時間の内訳
• スプリント計画アジェンダ — 時間配分を含む、構成された2時間の会議アジェンダ
• リスクフラグ — スプリントを頓挫させる可能性のあるブロッカーや依存関係

必須の入力

まだ提供されていない場合は、以下を確認します。

• スプリント期間（1週間または2週間）
• チームの人数とベロシティ（スプリントあたりの平均ストーリーポイント）
• 対象とするバックログ項目またはエピックの上位3～5件
• 把握している欠勤、休日、チームイベント
• 前回のスプリントで未完了となった項目（持ち越し）

スプリント目標の定式化

次の構成を使用します。

「このスプリントでは、[成果Xを実現]し、[ユーザー／ビジネス上のメリット]につなげます。達成度は[成功指標]で測定します。」

スプリント目標をタスクリストとして書いてはいけません。常に成果を最初に示します。

ストーリーポイントの調整

複雑さ	ポイント	説明
ごく簡単	1	内容が明確で、不確定要素がない
小	2	単純で、作業量も少ない
中	3	ある程度複雑だが、進め方は明確
大	5	複雑で、設計または調査が必要
非常に大	8	不確実性が高く、分割が必要な場合がある
エピック	13+	大きすぎるため、スプリント前に分割が必須

8ポイント以上と見積もられた項目にはフラグを付け、分割を推奨します。

キャパシティの計算式

Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
Focus hours/day: 6 (accounting for meetings, Slack, admin)
Availability factor: 0.7–0.85 depending on holidays/events
Story points to commit = Historical velocity × Availability factor

プログラムによる補助

このスキルには、キャパシティを手作業で見積もる代わりに計算する、Python 標準ライブラリのみを使用したスクリプトが付属しています。チームの数値がわかっている場合は必ず使用してください。稼働可能時間とコミット率80％のルールを一貫して適用します。

# Quick estimate from flags
python3 scripts/capacity_calculator.py --team 5 --days 10 --velocity 30 --availability 0.8 --carryover 5

# Detailed estimate from per-member availability (JSON via stdin or --input file.json)
echo '{"sprint_days":10,"historical_velocity":40,"carryover_points":8,
       "members":[{"name":"Ada","available_days":10},{"name":"Linus","available_days":7}]}' \
  | python3 scripts/capacity_calculator.py --input -

スクリプトは、集中作業に使える時間、実際の稼働状況に合わせて調整されたベロシティ、推奨コミット量（ベロシティの80％を上限とする）、および持ち越し項目を差し引いた後の新規作業に使える残りのキャパシティを返します。最初にスクリプトを実行し、推奨数値に収まるようにスプリントバックログを作成してください。結果をほかのツールに渡すには --json を追加します。

出力形式

スプリント [N] — [Start Date] から [End Date] まで

スプリント目標：

[Goal statement]

チームのキャパシティ： 利用可能なストーリーポイントは [X]（チームメンバー [Y] 人、稼働率 [Z]% に基づく）

スプリントバックログ：

優先度	ストーリー	ポイント	担当者	受け入れ条件
1	[Story title]	[N]	[Team member]	[When X then Y]

前回のスプリントからの持ち越し：

• [Item] — 持ち越しの理由：[brief explanation]

リスクと依存関係：

• [Risk description] → 軽減策：[action]

スプリント計画のアジェンダ：

• 00:00–00:10 — スプリント目標とチームのキャパシティを確認
• 00:10–00:40 — バックログ項目を確認し、見積もりを確定
• 00:40–01:20 — ストーリーを割り当て、依存関係を特定
• 01:20–01:50 — 各ストーリーの受け入れ条件を確認
• 01:50–02:00 — スプリントのコミットメントを確定して終了

ガイドライン

• 受け入れ条件のないストーリーには必ず異議を唱え、明確に指摘してください
• チームには、利用可能なキャパシティの100%ではなく80%をコミットするよう推奨してください
• ベロシティのデータがない場合は、開始時の目安として5人のチームで20～30ポイントを想定してください
• 担当者が不明確なストーリーは、ブロッカーとして明示してください

詳細資料

このスキルにはサポートファイルが付属しています。利用可能な場合は使用してください。

• references/capacity-honesty.md — キャパシティの正直な把握 — チームが自分たちに都合よく解釈してしまう数値について説明しています。出力の作成時に適用してください。上記の手法の概要では簡略化されている、調整方法と判断の指針が記載されています。
• templates/planning-worksheet.md — 品質ゲートが含まれた、記入式の成果物テンプレートです。生成を依頼するのではなく、ユーザー自身が文書を作成したい場合に案内してください。

評価基準（0～40）

このスキルの出力は、引き渡す前に採点してください。32点以上が出荷可能な品質です。

評価項目	0	5	10
スプリント目標の質	目標が「ストーリー1～8を実施する」といったタスクリストになっている、または目標がまったくない	成果を意識しているものの曖昧で、スプリント終了時に合否を判定できない	ユーザーまたはビジネスへのメリットと成功指標を含む単一の成果文で、スプリント終了時に明確に判定できる
キャパシティの正直な把握	コミットメントが理論上のキャパシティの100%を想定している。持ち越しを考慮していない	稼働可能時間は調整しているが、80%のコミット比率を考慮していない、または新しい作業を取り込む前に持ち越しポイントを差し引いていない	実際の稼働可能時間（休日、会議、集中作業時間）を反映し、まず持ち越しを差し引いたうえで、調整後のベロシティの80%を上限としてコミットメントを設定している
ストーリーの準備状況	ストーリーに受け入れ条件、見積もり、または担当者がない	ほとんどのストーリーに見積もりと担当者があるが、8ポイント以上のストーリーが分割されていない、または受け入れ条件がテストできない	すべてのストーリーに担当者が1人、適切に調整されたポイント数、テスト可能な受け入れ条件がある。8ポイント以上のストーリーはすべて分割対象として指摘されている
リスクと依存関係の洗い出し	リスクや依存関係が挙げられていない	「遅れる可能性がある」などの一般的なリスクのみで、軽減策や担当者がない	具体的なブロッカーとチーム間の依存関係が挙げられ、それぞれに具体的な軽減策と担当者が設定されている

品質チェック

• スプリント目標が成果に焦点を当てている（「Xを実装する」ではなく、「ユーザーがYできる」のような内容）
• チームのキャパシティが、理論上の100%ではなく実際の稼働可能時間に基づいて計算されている
• すべてのストーリーに受け入れ条件がある（ないものは指摘する）
• 8ポイント以上のストーリーは分割対象として指摘されている
• 前回のスプリントからの持ち越しがキャパシティに反映されている

アンチパターン

• スプリント目標をタスクリストにしないでください。目標は成果に焦点を当て、スプリント終了時に合否を判定できるものである必要があります
• 利用可能なキャパシティの100%にコミットしないでください。予定外の作業に対応する余裕を確保するため、常に80%を推奨してください
• 受け入れ条件のないストーリーをスプリントに持ち込まないでください。コミットする前にブロッカーとして指摘してください
• 8ポイント以上と見積もられたストーリーは、先に分割せずにスプリントに入れないでください
• キャパシティの計算で持ち越し項目を無視しないでください。持ち越し項目もキャパシティを消費するため、新しい作業を取り込む前に必ず考慮してください

実行

チームのトラッカー（Jira、Linear、GitHub Projects）にアクセスできる、ツール使用エージェントまたはコンピューター操作エージェント向けです。ツールにアクセスできないランタイムは、このセクションを無視してドキュメントを提出してください。このブロックが従うルールについては、SKILLSPEC.md §5 を参照してください。

前提条件

• 上記のスプリント計画が作成され、人間によって明示的に承認されていること。レビューされていないドラフトからスプリントを作成してはいけません。
• トラッカーへのアクセスはエージェントの環境ですでに認証済みで、対象のボード／プロジェクトはユーザーが指定していること。
• 実行予定の変更を一覧にしたドライランが提示され、確認済みであること。

許可される操作

• 承認済みの名前と日付で、スプリント／イテレーションのコンテナーを作成します。
• 承認済みの計画に記載された項目のみを、承認済みの既存のバックログ項目からスプリントに移動します。
• それらの項目に、承認済みの値でストーリーポイントの見積もりを設定します。
• スプリントの目標を、スプリントの説明またはピン留めコメントとして投稿します。
• それ以外の操作は禁止です。新しい課題の作成、何かの削除またはクローズ、項目の説明の編集、他のスプリントへの変更は行いません。

検証

• トラッカーからスプリントを再読み込みし、項目数と合計ポイントが承認済みの計画と一致すること、移動したすべての項目がスプリントに含まれていること、スプリントの日付が一致することを確認します。
• 検証の概要（項目、ポイント、日付）をユーザーに返信します。

ロールバック

• 取り消す場合は、項目をバックログに戻し、空になったスプリントのコンテナーを削除します。
• 計画内の項目が存在しなくなっている、または承認後に変更されている場合、トラッカーが操作を拒否した場合、あるいはボードに日付が重複するアクティブなスプリントがある場合は、作業を中止して人間に確認を求めます。