agile-review について
スプリントの成果記録と指標を整理し、客観的なステークホルダー向けレビューとデモ資料を作成するスキルです。計画と実績を比較し、差異を記録して、次のサイクルに向けたフィードバックを集めます。
主な機能
- 01スプリント成果の集約
- 02計画と実績の比較
- 03ビジネス価値に沿ったデモ構成
- 04デリバリー、品質、フロー指標の記録
- 05ステークホルダーのフィードバック収集
活用シーン
- 01スプリント終了時のデモ準備
- 02未達項目とその扱いの説明
- 03数値を改変せずにスプリント指標を振り返る
- 04フィードバックをバックログのアクションに反映
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ djalmajr/ skills --skill agile-reviewインストール後、Claude Code で/agile-reviewを入力して読み込まれたか確認します。
同梱ファイルtemplates/review.md
詳細
スプリントレビュー
このスキルを使用して、スプリントでの成果を、ステークホルダー向けの明確で客観的なレビュー/デモ形式にまとめます。
言語
成果物はユーザーの言語で作成してください。文法を正しく使い、必要な発音区別符号や文字体系固有の文字も適切に使用してください。ユーザーの言語が不明な場合は、出力を生成する前に確認してください。テンプレートは英語です。見出しと内容を対応する言語に翻訳してください。
プロジェクトルート
このスキルは、エージェントの現在の作業ディレクトリではなく、プロジェクトルート(作業を行うリポジトリ)からの相対パスに成果物を作成します。
- プロジェクト内から実行する場合は、このスキルに記載されている相対パスを使用してください。
- 別のディレクトリから実行する場合(例:兄弟リポジトリから実行する場合、またはプロジェクトが別の場所にある場合)は、すべての成果物パスの先頭に
<project-root>/を付けてください。 - プロジェクトルートが曖昧な場合は、書き込みを行う前にハーネスの質問ツールを使用してユーザーに確認してください。
プロンプト
CLAUDE.md/AGENTS.md(「Skill Prompting Conventions」)に記載されたプロジェクト全体の規約に従ってください。以下の判断が必要な箇所では、ハーネスの構造化質問ツール(Claude Code のAskUserQuestion、Codex のask_user_question、または OpenCode のquestion)を使用してください。
| 判断事項 | 構造化質問にする理由 | 推奨される選択肢 |
|---|---|---|
| 対象者 | デモの内容を左右するため | チームのみ · ステークホルダー · 混在 |
| デモの範囲 | 成果物の分岐を決めるため | 完了した項目のみ · 進行中の項目も含める |
自由記述のプロンプト(構造化ツールは使用しません):
- ステークホルダーの名前
- デモのナレーション文
中断なしモード:ユーザーがスキル実行中の確認を明示的に無効にしている場合は、すべての構造化プロンプトを「未解決の質問」(または同等の項目)に記載し、処理を続行してください。
目的
- スプリントで提供した成果をまとめる
- 成果をスプリント計画時のコミットメントと比較する
- スコープの変更、逸脱、決定事項を明らかにする
- 提供した価値を客観的に示すデモを準備する
- 次のサイクルに活かすため、ステークホルダーからのフィードバックを集める
- デモとそれに続くレトロスペクティブの根拠となる、定量的なスプリント指標(デリバリー、品質、フロー、プロセス)を把握する
使用するタイミング
- スプリント終了時、レトロスペクティブの前
- ステークホルダーに成果を見せる必要があるとき
- プロダクトが正しい方向に進んでいるか検証する必要があるとき
- スプリント計画からレトロスペクティブまでのサイクルを締めくくるとき
- チームがスプリントの数値(ベロシティ、ブロッカー、完了率)を必要としているとき。これらはここで収集します
プロセス
1. 成果をまとめる
以下の情報を収集します。
- スプリントで完了したイシュー
- 生成されたステータス完了レポート
- 期間中のステータスチェックポイントと統合レポート
- 登録されたスコープの変更
提供した各項目について、次の内容を記録します。
- 期待されていたこと(スプリント計画より)
- 実際に提供した内容
- 関連する逸脱(ある場合)
2. デモを準備する
技術的な順序ではなく、ビジネス価値に沿ってデモを構成します。
- 影響から始めます:「これでチームはXができるようになりました」
- スライドではなく、動作するフローを見せます
- 関連する技術的な要素(パフォーマンス、セキュリティなど)があれば、背景情報として含めます
3. 未提供の項目を特定する
計画されたものの提供できなかった各項目について、以下を記載します。
- 理由:ブロッカー、優先順位の変更、想定より大きなスコープ
- 今後の扱い:バックログに戻す、次のスプリントに含める、破棄した
4. スプリント指標を収集する
スプリントの成果物(計画、ステータス確認、クローズ、課題、git)から、レビューの指標セクションを記入します。数値を捏造したり、丸めたりしないでください。
- デリバリー: 計画数と完了数、スプリント中に追加された項目、延期された項目
- 品質: スプリント中/デリバリー後のバグ、終了時点の lint/型チェック/テスト
- フロー: ブロッカー(件数と平均継続時間)、ストーリーあたりの平均所要時間、再オープン件数
- プロセス: 実施したステータス確認と予定数、クローズ件数とデリバリー件数
- 傾向: データがある場合は、前回のスプリントとの比較
- レトロの注目点: 良かった点を1つ、注意すべき点を1つ、アクションの提案を1つ
少人数でのレビュー(個人作業の週)はこのセクションを短くしてもかまいませんが、計画数/完了数/ブロッカーは必ず記載してください。
5. フィードバックを収集する
ステークホルダーからの質問やフィードバックを記録します。
- 必要な調整
- 新たに確認されたニーズ
- 優先度の変更
6. 成果物を生成する
以下のテンプレートを使用してレビューを記録します。planning/sprints/sprint-review-YYYY-MM-DD.md に保存します(または、個人で行う簡易サイクルの場合はインラインで提示します)。
テンプレート
このスキルの成果物のベースとして templates/review.md を使用します。
ルール
- レビューには、完了したことを記載します。進行中のことではありません。進行中の作業状況については、
/agile-statusを使用してください。 - 未完了の項目とその理由を正直に記載します。削除した項目を隠すと信頼が損なわれます。
- デモは検証可能でなければなりません。ステークホルダーが実際の成果を確認できる必要があります。
- 収集したフィードバックは、必ずバックログ項目またはアクションに反映してください。会議メモだけで終わらせてはいけません。
- スプリントレビューはレトロに情報を提供します。レビューを実施しないと、レトロで重要な情報が失われます。
- この成果物の指標は振り返りのためのものであり、評価のためのものではありません。見栄えをよくするために数値を操作してはいけません。
フローとの関係
flowchart LR
A["/agile-sprint"] --> B[execution]
B --> C["/agile-status"]
C --> D["/agile-review"]
D --> E["/agile-retro"]
一連のフローでは、スプリントレビューが実行とフィードバックをつなぎます:計画 -> 実行 -> ステータス -> レビュー(デモ + 指標)-> レトロ。
スプリント中のステータス追跡には、/agile-status を使用してください。スプリントの定量的な数値は、このレビュー成果物に記録します。