プラクティス名（別名）
プロダクトバックログリファインメント （PBR、バックロググルーミング、バックログ管理）
プラクティスの目的・狙い
- PBIをスプリントに投入できる記載粒度（Readyな状態）に整える
- 検討内容や新たな知見を反映し、PBLを最新化する
どんな時に使うか
- 直近のスプリントで対象になりそうなPBIを詳細化したい時
- フィードバックに基づいて要件/見積/優先順位を見直したい時
実施手順
- PBRの実施タイミングは特に定められていない（が、定期的な開催推奨）
- 出席者はPO,DEV,SM（と必要に応じて対象PBIに関係するステークホルダー）
- PBLの記述をベースに、DEVが不明点や仕様をPO（＆ステークホルダー）に確認する
- 確認結果はPBLに反映するが、書ききれない場合は別途設計メモなどに残す
- 直近で投入対象になりそうなPBIはDEVが実作業に入れるレベルまで詳細化しておく
| パターン | 具体的な作業内容 |
|---|---|
| 追加 | 新たな要望やアイデアをPBIとして追加する |
| 更新 | 記述を詳細化する、変更点を反映する、ACを追記する、等 |
| 分割 | 大きすぎるPBI（エピック）を複数のアイテムに切り分ける |
| 統合 | 重複する内容や一度に処理できるPBIを１つにまとめる |
| 削除 | 不要、または価値が低いと判断されたPBIを捨てる |
| 見積もり | コスト（作業量）を見積もる、実績に基づき再見積もりする |
| 並び替え | PBIの優先順位を入れ替える、PBIに依存関係がないかチェックする |
アレンジ例
- PBRを定期イベント化する（例：スプリントレビュー後に行う、など）
アンチパターン
- 会議に必要なステークホルダーが出席しておらず、POの持ち帰り確認が増える
- 優先順位の低いPBIに関しても詳細しようとする（ムダになる可能性が高い）
参考情報
定番、AgileStudioのアジャイルプラクティスマップから。
こぼれ話（私的コメント）
PBRのタイムボックスについて、スクラムガイド2017では、「開発チームの作業の10％以下にすることが多い」という記述がありました。これを多いと見るか、少ないと見るかは現場によるかもしれません。ウォーターフォール開発における要件定義～詳細設計に相当すると考えると少し足りない気もしますが、アジャイル開発の場合はDEVが手を動かせる程度まで話を詰めたら後は実物で確認しよう、というスタンスで臨んだ方が良さそうです。またPOがボトルネックになりやすい作業でもあるので、PO-DEVの人数比によっても適正な時間配分は変わってきそうです。