sprint-brief について
エンジニア、デザイナー、プロダクトマネージャー向けに、スプリント情報を簡潔なブリーフへまとめるスキルです。目標の明確さ、クリティカルパス、リスク、持ち越し項目、容量に対するスコープを確認します。
主な機能
- 01スプリント目標の具体性を確認
- 02チケットをテーマ別に整理
- 03クリティカルパスを特定
- 04リスクとブロッカーを提示
- 05持ち越し項目と容量を評価
- 06基準に沿ってブリーフを採点
活用シーン
- 01チーム向けスプリントブリーフの作成
- 02スプリント目標の実現可能性確認
- 03開始前の依存関係の洗い出し
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mohitagw15856/ pm-claude-skills --skill sprint-briefインストール後、Claude Code で/sprint-briefを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/goal-writing.mdworked-example.mdtemplates/brief-one-pager.md詳細
スプリント概要スキル
エンジニア、デザイナー、PM など、すべてのチームメンバーが3分以内で読めて、何をなぜ行うのかを正確に理解できる、明快で把握しやすいスプリント概要を作成します。
必要な入力
以下の情報が提供されていない場合は、ユーザーに確認してください。
- スプリント名と番号
- スプリント目標(1~2文。曖昧すぎる場合は指摘してください)
- チケット一覧と担当者(または作業の説明)
- 把握している依存関係やブロッカー
- 前回のスプリントからの持ち越し項目(ある場合)
プロセス
- スプリント目標を読み、具体的かつ測定可能か確認します。曖昧すぎる場合は指摘してください
- チケットをテーマまたは機能領域ごとに分類します
- クリティカルパスを特定します。スプリント目標を達成するために完了必須のチケットはどれですか?
- リスクを指摘します。受け入れ条件が不明確なチケット、デザインが不足しているチケット、未解決の依存関係などです
- 持ち越し項目を記載し、今スプリントの目標に影響するかどうかを示します
- 検証 — チケットの範囲とチームのキャパシティを考慮して、スプリント目標が達成可能か確認します。クリティカルパスの項目だけでスプリント期間を使い切る場合は、作業過多と指摘してください。
出力形式
スプリント[番号]概要 — [日付]
スプリント目標:[1~2文。具体的かつ測定可能] このスプリントが重要な理由:[四半期 OKR とのつながりを2~3文で説明]
開発する内容:
- [テーマ1]:[チケットと担当者]
- [テーマ2]:[チケットと担当者]
クリティカルパス:[ほかのすべてが依存する2~3件のチケット]
指摘すべきリスク:
- [リスク1+軽減策]
- [リスク2+軽減策]
前回のスプリントからの持ち越し:[一覧+今の目標への影響]
完了の定義:[スプリントの成功に関する、具体的で合意済みの基準]
詳細資料
このスキルには補助ファイルが含まれています。利用可能な場合は活用してください。
references/goal-writing.md— 方向性を示すスプリント目標の書き方。出力の作成時に適用してください。このファイルには、上記の手法の概要では簡略化されている調整基準や判断の指針が記載されています。templates/brief-one-pager.md— 品質チェック項目を盛り込んだ、記入式の成果物テンプレートです。生成を依頼するのではなく、自分で文書を作成したいユーザーに案内してください。
評価基準(0~40)
このスキルの出力は、渡す前に採点してください。32点以上が公開可能な品質です。
| 評価項目 | 0 | 5 | 10 |
|---|---|---|---|
| 目標の採点可能性 | 目標が作業一覧、または曖昧な方向性(「X を進める」など)で、スプリント終了時に誰も評価できない | 目標が1つの成果を示しているが、合否の基準が曖昧(数値、日付、観察可能なテストがない) | 目標が1つの成果を示し、最終日にチームの誰もが適用できる明確な合否テストがある |
| クリティカルパスの精度 | クリティカルパスがない、または「重要なチケット」としか書かれておらず、どの遅延が致命的か判断できない | クリティカルパスのチケットは示されているが、順序や目標達成が不可能になる日付・条件が示されていない | チケットが依存関係の順に示され、目標達成が不可能になる期限と、ほかのボード項目との「致命的」対「許容可能」の明確な区分がある |
| 実行可能なリスク対応 | リスクが懸念事項の一覧にとどまり、軽減策も担当者もない | 各リスクに軽減策または担当者はあるが、対応が一般的(「注意深く監視する」など) | すべてのリスクに、準備完了期限と明確な担当者1名を定めた具体的な軽減策があり、目標を脅かすのか、単にチケットに影響するのかが明示されている |
| キャパシティの正直な評価 | 持ち越しが影響を示さずに記載され、ボードの作業過多が見えないままになっている | 持ち越しが目標に与える影響は示されているが、概要では対処されていない。作業過多をリスクとして指摘するだけで、そのままにしている | 持ち越しの工数をキャパシティと照合し、範囲を削減する項目、目標の縮小、またはチームが明示的に合意した作業過多の受け入れのいずれかを示している |
品質チェック
- スプリントゴールが具体的で、スプリント終了時に合格/不合格を判定できる
- クリティカルパスの項目が明示されている。「重要なもの」だけでは不十分
- すべてのリスクに、緩和策または担当者が設定されている(「これはリスクです」だけでは不十分)
- 持ち越し項目が、今スプリントのゴールへの影響と関連付けられている
- 完了の定義が、タスクリストではなく、合意済みの基準になっている
アンチパターン
- スプリントゴールをタスクリストとして書かないでください。ゴールは、合格/不合格を判定できる、成果に焦点を当てた単一の文でなければなりません
- クリティカルパスを明示しないままにしないでください。「重要なチケット」はクリティカルパスではありません
- 緩和策や担当者を設定せずにリスクを列挙しないでください。対応策のないリスクは、単なる心配事のリストです
- 持ち越し項目が、今スプリントのキャパシティとゴールに与える影響を無視しないでください
- タスクの完了と成果の基準を混在させた完了の定義を書かないでください。どちらも観察可能で、スプリント開始前に合意されている必要があります
コメント
Markdown 対応