backlog-refinement

name	backlog-refinement
description	バックログリファインメントを実施する。PBIの詳細化、分割、見積もり、受入基準の明確化、優先順位の確認、Ready判定を行う。プロダクトバックログの継続的な改善時に使用する。

バックログリファインメント実施

"準備"で起動した各サブエージェントを下記の指示通りに利用し、プロダクトバックログリファインメントを実施してください。

準備

• サブエージェントとして、佐藤エージェント(.github/agents/customer.sato.agent.md)をモデル"Claude Opus 4.7"で実行します。
• サブエージェントとして、鈴木エージェント(.github/agents/product-owner.suzuki.agent.md)をモデル"Claude Opus 4.7"で実行します。
• サブエージェントとして、伊藤エージェント(.github/agents/developer.ito.agent.md)をモデル"Claude Opus 4.7"で実行します。
• サブエージェントとして、田中エージェント(.github/agents/developer.tanaka.agent.md)をモデル"Claude Opus 4.7"で実行します。
• サブエージェントとして、高橋エージェント(.github/agents/scrum-master.takahashi.agent.md)をモデル"Claude Opus 4.7"で実行します。
• サブエージェントとして、小林エージェント(.github/agents/reviewer.kobayashi.agent.md)をモデル"GPT-5.5"で実行します。

プロダクトバックログリファインメントは、プロダクトバックログアイテムをより小さく正確なアイテムに 分解し、さらに定義する行為である。これは詳細、並び順、サイズなどを追加する継続的な活動である。 — スクラムガイド 2020

事前確認

1. scrum/product_backlog.csv を読み、現在のプロダクトバックログを確認する
2. scrum/product_goal.md を読み、プロダクトゴールを確認する
3. scrum/definition_of_done.md を読み、完成の定義を確認する

リファインメント対象

対象範囲: 指定がなければ全体を対象とします。

リファインメントの実施

0. Product Goalの作成/更新/確認

鈴木エージェントが主催し、伊藤エージェントと田中エージェントが協力する形で、プロダクトゴールの作成・更新を行ってください：

• プロダクトの長期的なビジョンを表現する
• 佐藤エージェントが顧客の視点からゴールの妥当性を確認します。なお、ユーザサイドの要求事項や依頼事項はscrum/order/orderXXX.md に記録されているものとします。（XXXは連番、最新の番号のファイルのみが対象です。）
• すでに考慮済みの依頼事項しかない場合は、ユーザからの追加要望はないとしてリファインメントを実施してください。
• 内容について高橋エージェントが確認し、スクラムマスターの視点からフィードバックを提供します。

1. PBIの詳細化

鈴木エージェントから佐藤エージェントに説明する形で、対象PBIについて以下を確認・更新してください：

• タイトルが明確か
• 説明が十分に詳細か
• ユーザーストーリー形式で記述されているか
• 佐藤エージェントからのフィードバックがあれば反映します。

2. 完了定義の作成/更新

鈴木エージェントによって、DoD(scrum/definition_of_done.md)を検証可能な形で定義してください：

• 各基準は「はい/いいえ」で判定可能であること
• エッジケースが考慮されていること 伊藤エージェントと田中エージェントに確認し、技術的な観点からの基準も追加してください。 高橋エージェントを使い、スクラムマスターの視点からも確認してください。 最終的に鈴木エージェントの判断によってDoDを作成・更新します。

3. PBIの分割

伊藤エージェントが主導する形で、大きすぎるPBIを分割してください：

• 1スプリント以内に完了できるサイズか評価する
• 大きすぎる場合は独立した価値を持つ単位に分割する
• 田中エージェントの合意が必要です。
• 最終的な分割結果は、鈴木エージェントがレビューします。

4. 見積もり

伊藤エージェントが主導する形で、田中エージェントともにPBIの相対見積もりを行ってください：

• ストーリーポイントで見積もる
• チームの過去の実績（scrum/velocity.csv）を参考にする。（存在しない場合は、独自基準で見積もる）
• 見積もりは開発者のみが行う（他者が指示しない）

5. 優先順位の確認

鈴木エージェントが主導し、佐藤エージェントと協力して、優先順位を確認・調整してください：

• ビジネス価値、リスク、依存関係を考慮する
• Priority: Critical > High > Medium > Low

6. Ready判定

鈴木エージェントが主導し、以下の基準を満たすPBIを「Ready」ステータスに変更する：

• 説明が十分に明確
• 受入基準が定義済み
• 見積もりが完了
• 依存関係が解決済みまたは明確
• 1スプリント以内に完了可能なサイズ

7. リファインメント結果の監査

小林エージェントを使い、リファインメントの結果を監査してください：

• 更新すべきファイルがきちんと更新されているか、抜け漏れが無いかをチェックします。

8. リポジトリへの反映

• 高橋エージェントを使い、必要なファイルをマージして、全てmainリポジトリに反映させます。
• 最後に git pull origin main を実行し、差分を確認・取得します。

記録

• 鈴木エージェントにより、scrum/product_backlog.csv を更新する（詳細化、見積もり、ステータス変更）
• 鈴木エージェントにより、完了したPBIは scrum/product_backlog_done.csv に移動する（元のCSVからは削除する）
• 新規PBIがあればCSVに追加する
• 佐藤エージェントにより、ユーザ要望が取り込まれたと判断した場合、scrum/order/orderXXX.md に記録する（XXXは連番、最新の番号のファイルに追記する形で記録）

注意事項

• リファインメントはスプリント内の継続的な活動である
• 開発者のキャパシティの10%以下を目安とする
• 直近2〜3スプリント分のPBIをReady状態に保つことを目指す
• 記録は必要な要素を落とさずに、一方でできるだけ簡潔に短く記載すること