sprint-planner

sprint-planner スキルの概要

sprint-planner は、Agile / Scrum の大まかなスプリント案を、ストーリーポイント・キャパシティ・スプリントゴール・バックログ表・リスク・Definition of Done を備えた構造化済みのスプリント計画に落とし込むための軽量プランニングスキルです。ゼロから体裁を組み立てるよりも速く、再利用しやすい計画フォーマットが必要なエンジニアリングマネージャー、スクラムマスター、テックリード、小規模プロダクトチームを率いる創業者、そして個人で実務を進めるコントリビューターに特に向いています。

sprint-planner が最も力を発揮する場面

sprint-planner が特に強いのは、すでに候補タスクがあり、それを現実的なスプリント計画として整理したいときです。あらかじめ用意された計画フレームにより、次のような作業を一貫した形で進められます。

• 修正 Fibonacci によるストーリー見積もり
• チームキャパシティの算出
• ベロシティを踏まえたコミット判断
• スプリントゴールの草案作成
• バックログの整形
• リスクと依存関係の洗い出し

そのため、出力の型を毎回そろえたい場合は、単なる「plan my sprint」という汎用プロンプトより実用的です。

sprint-planner を導入すべき人

次のようなニーズが継続的にあるなら、sprint-planner の導入価値があります。

• バックログ項目をスプリントバックログに落とし込みたい
• 作業をすばやく見積もり、または再見積もりしたい
• スコープがチームキャパシティに見合っているかを確認したい
• チームがそのままレビューできる計画成果物を出したい
• 自前でプロンプトテンプレートを作らずに、案件横断で計画を標準化したい

一方で、Jira との深い連携、履歴分析、自動 issue 同期まで求めるなら、このスキル単体では軽量すぎます。

導入前に実際のユーザーが気にすること

sprint-planner を評価する人が主に見ているのは、たいてい次の3点です。

1. 通常のプロンプトより時間短縮になるか
2. 実際に使えるスプリント計画成果物が出るか
3. 不完全なバックログメモからでも機能するか

結論としては、チーム規模、スプリント期間、候補ストーリーについて最低限の文脈を渡せるなら、概ね「はい」です。構造はこのスキルが与えてくれますが、出力の質はやはり入力の質に左右されます。

通常のプロンプトと比べた主な違い

Project Management 向けの sprint-planner の価値は、隠れたロジックや専用ツールにあるわけではありません。明確な前提を持つ、規律ある計画テンプレートにあります。

• 修正 Fibonacci 見積もり: 1, 2, 3, 5, 8, 13, 20
• チーム人数・営業日・稼働時間・focus factor を使うキャパシティ整理
• 明示的な sprint goal
• 明示的な dependencies と risks
• 明示的な definition of done

この構造があることで、計画レビュー時の「抜け漏れ」を減らしやすくなります。

sprint-planner スキルの使い方

sprint-planner のインストール方法

リポジトリに含まれているのは SKILL.md のみなので、インストール方法は利用中の skills 対応クライアントに依存します。GitHub ベースでは、よくある導入パターンは次のとおりです。

npx skills add Shubhamsaboo/awesome-llm-apps --skill sprint-planner

クライアント側で別の import フローを使う場合は、以下を指定してください。

Shubhamsaboo/awesome-llm-apps/tree/main/awesome_agent_skills/sprint-planner

インストール後は、依頼内容がスプリント計画、ストーリー見積もり、スプリントキャパシティ、スプリントバックログ作成に明確に関係している場面で呼び出すのが基本です。

リポジトリで最初に読むべきもの

このスキルはかなりシンプルです。まず SKILL.md を読めば、実用上必要な挙動はほぼ把握できます。

確認順としては、次の3つに注目してください。

1. When to Apply
2. Sprint Planning Framework
3. Output Format

補助スクリプトや追加ルール、参照ファイルはないため、導入判断は「このフレームワークが自チームの計画スタイルに合うかどうか」でほぼ決まります。

sprint-planner に必要な入力情報

このスキルが最も機能しやすいのは、次の情報を渡したときです。

• sprint 番号または計画期間
• sprint の長さまたは日付
• チーム人数と役割
• わかっていれば想定 focus factor
• 直近 3-5 sprint のベロシティ
• 候補バックログ項目
• 大まかな優先度
• 既知の依存関係
• どうしても外せない納期・コミット事項

これらがなくてもスプリント案の下書き自体は作れますが、見積もりとコミットの精度は急激に落ちます。

sprint-planner 利用時の最小実用プロンプト

最低限でも使えるプロンプトは、たとえば次のような形です。

Use sprint-planner.

Plan Sprint 12 for a 2-week product sprint.
Team: 4 engineers, 1 designer shared at 30%, 1 QA shared at 50%.
Velocity over last 4 sprints: 24, 26, 21, 25 points.
Candidate work:
- User login bug fixes
- Add password reset flow
- Payment retry handling
- Admin audit log page
- Improve test coverage for checkout
Known dependency: design approval for audit log.
Need a realistic sprint goal and backlog with points, owners, dependencies, risks, and definition of done.

この程度でも、初回ドラフトとしては十分なスプリント計画を得られます。

ラフなメモを強いプロンプトに変える方法

より良いプロンプトでは、各ストーリーに「計画判断に必要な信号」が入っています。バックログ項目ごとに、できるだけ次を含めてください。

• ユーザーまたは事業上の成果
• おおよその複雑さ
• ブロッカー
• 想定オーナー
• 緊急度
• 分割可能かどうか

たとえば、次のように書くよりも、

Build notifications

こちらのほうが有効です。

Build email notifications for failed payments.
Scope includes trigger, template, resend logic, and admin visibility.
Backend-heavy, medium risk, depends on payment event reliability.
Preferred owner: Priya.

このようにすると見積もり精度が上がり、sprint-planner が「今スプリントに入れるべき仕事」と「後ろ倒しにすべき仕事」を分けやすくなります。

実運用チーム向けの、より良いプロンプトテンプレート

Use sprint-planner to create a realistic sprint plan.

Sprint details:
- Sprint number/name: Sprint 18 - Checkout Stability
- Dates: May 6 to May 17
- Sprint length: 10 working days

Team and capacity:
- 5 engineers
- 1 QA at 50%
- 1 PM full-time
- Focus factor: 0.7
- Planned time off: Alex 2 days, Mina 1 day

Historical velocity:
- Last 5 sprints: 28, 24, 30, 26, 27

Backlog candidates:
1. Fix duplicate charge bug in retry flow
2. Add payment failure status in order history
3. Improve refund admin filters
4. Write integration tests for payment webhooks
5. Investigate slow checkout API
6. Prepare feature flag rollout for new processor

Constraints:
- Duplicate charge fix is highest priority
- API investigation should only be included if capacity allows
- Refund filter work depends on backend schema update

Output:
- sprint goal
- capacity and committed points
- sprint backlog table with points, owner, dependencies
- risks and mitigation
- definition of done

このレベルまで具体化すると、sprint-planner usage は汎用の計画プロンプトより明確に実務向きになります。

スプリント計画中におすすめの進め方

sprint-planner を使う実践的なワークフローは、次の流れです。

1. 候補バックログ項目を貼る
2. 初回見積もりとキャパシティ確認を依頼する
3. 過剰コミットになっている項目を見直す
4. 大きすぎるストーリーを分割させる
5. スプリントゴールを確定する
6. 最終版の sprint backlog table を再生成する
7. 出力を tracker や planning doc に転記する

コミット内容の最終決定者としてではなく、計画を前に進めるファシリテーターとして使うのが適切です。

sprint-planner の見積もりとキャパシティの扱い方

このスキルに組み込まれている計画前提は、シンプルですが実用的です。

• Story points は修正 Fibonacci 値を使う
• Capacity は team size、days、hours、そして 0.6-0.8 前後の focus factor から計算する
• Velocity は直近 3-5 sprint を基準にする

つまり、sprint-planner は厳密な納期予測よりも、相対的で現実的な計画づくりに向いています。velocity を渡さない場合、見た目は整っていても運用上の信頼性が低い計画になりやすい点には注意が必要です。

出力品質を上げる実践的なコツ

sprint-planner の結果を良くしたいなら、次を意識してください。

• チーム人数だけでなく、直近 velocity も渡す
• 休暇や兼務メンバーを明記する
• must-have と nice-to-have を分ける
• 不確実要素を明示する
• 8 points を超える項目は分割を依頼する
• スコープでもめそうなら、保守的な案と攻めた案の両方を出させる

細かな説明文を増やすより、こうした情報を足すほうが、コミットの現実味は大きく改善します。

sprint-planner が向かないケース

主なニーズが次のいずれかなら、sprint-planner は避けたほうがよいです。

• 長期ロードマップ計画
• ポートフォリオレベルの優先順位付け
• 多数チームをまたぐ release train 調整
• 厳格な承認フローが必要な高度規制下の開発
• プロジェクトシステムの自動更新

これは計画フォーマットを整えるスキルであって、プロジェクト運用プラットフォームではありません。

sprint-planner スキル FAQ

sprint-planner は通常の sprint planning prompt より良いか

一貫性を重視するなら、たいていは yes です。sprint-planner には、capacity、story points、sprint goal、backlog、risks、definition of done を毎回同じ型で整理する仕組みが最初から入っています。通常のプロンプトでも近い結果は出せますが、その構造を毎回自分で思い出して書き直す必要があります。

sprint-planner は初心者にも向いているか

はい。特に、Scrum の基本は理解しているが、もっと整った計画フローがほしいチームには向いています。初心者にとって使いやすい足場を与えてくれます。ただし、細かな見積もり判断やチーム固有の planning policy まで自動で教えてくれるわけではないので、経験者のレビューは引き続き重要です。

sprint-planner は履歴データなしでも使えるか

使えますが、出力品質は落ちます。過去 velocity、休暇、現実的な focus factor を省くと、計画はきれいに見えても楽観的すぎる内容になりがちです。初めてのチームなら、保守的なコミット案を出させ、不確実性を明示するよう求めるのが安全です。

sprint-planner は Jira などの PM ツールと連携するか

単体ではしません。リポジトリ上で確認できるのは SKILL.md ファイルのみで、スクリプトやコネクタはありません。生成した sprint backlog は、Jira、Linear、GitHub Issues、Notion、または既存の planning system に手動で移す前提で考えてください。

sprint-planner をインストールしないほうがよいのはどんなときか

計画支援より自動化を重視している場合、あるいはチームが sprint ベースで開発していない場合は、sprint-planner を入れても噛み合いにくいです。Kanban 専用チームでも、短期計画テンプレートとして流用しない限り、相性はあまり良くありません。

sprint-planner スキルを改善する方法

sprint-planner に渡すバックログ入力の質を上げる

sprint-planner を最も手早く改善する方法は、呼び出す前にストーリーの質を上げることです。弱い入力は、もっともらしいだけの「偽の精度」を生みます。

次のような入力を優先してください。

• 明確な story title
• business value
• dependencies
• acceptance notes
• owner のヒント
• 既知の不確実要素

避けたいのは、こちらです。

• 曖昧な task 名
• bugs と projects が優先度なしで混在している状態
• risk や urgency の記載がない状態

大きすぎる、または曖昧なストーリーは分割させる

よくある失敗パターンは、大きすぎるストーリーが分割されないままスプリントに入ることです。どれか1つでも広すぎると感じたら、次のように依頼してください。

Use sprint-planner, but first split any story larger than 8 points into smaller backlog items with clearer dependencies.

同じ大きなストーリーを再見積もりするより、まず分割させたほうがコミット品質が改善することは少なくありません。

体裁だけでなく、トレードオフ判断まで求める

sprint-planner の弱い使い方は、「整った backlog を出して」で止めてしまうことです。より良い追加入力は、たとえば次のようなものです。

Review the proposed sprint backlog and identify which items should be deferred if we cap commitment at our average velocity.

こうすると、単なる文書整形ではなく、実際の計画支援として機能しやすくなります。

不確実性・制約・現実の人員事情を足す

質の低いスプリント計画の多くは、運用上の文脈不足から生まれます。次のような情報は、きちんと伝えてください。

• vacations
• support rotation
• on-call load
• release deadlines
• external approvals
• cross-team dependencies

チームがこれから実際に過ごす1週間・2週間を反映しているほど、sprint-planner のガイドは信頼しやすくなります。

初稿のあとに必ず反復する

最も効果的な sprint-planner usage は、反復前提です。

1. 初回プランを生成する
2. 見積もりと owner を問い直す
3. リスクの高い項目を外すか分割する
4. sprint goal を絞り込む
5. 最終版を再生成する

最初の出力はファシリテーション用の下書きとして扱ってください。多くのチームにとって、本当の価値が出るのは2回目の調整です。

sprint-planner 用に自チームの定番プロンプトを作る

毎 sprint 使うなら、チーム標準の wrapper prompt を保存しておくと便利です。たとえば次のような既定値を含めます。

• 標準の sprint length
• 通常の focus factor
• definition of done のバリエーション
• owner の命名形式
• よく使う risk category
• 好みの出力 table column

これにより手戻りが減り、sprint-planner をチームや案件をまたいでも安定して使いやすくなります。