プロダクトバックログリファインメント

PBIを確認し、今後のスプリントで着手可能にするためには、スプリントごとにプロダクトバックログリファインメントを行う必要があります。

プロダクトバックログリファインメントで行う主な作業は
(1) 大きなPBIの分割
(2) 各PBIを着手可能にする
(3) 見積もる

経験的プロセス管理の観点から、Scrumでは、プロダクトバックログリファインメントの細かい how（どう行うか）を規定しません。ただし、Sprintの全体時間のうち 10%を超えないようにすることを推奨しています。プロダクトバックログリファインメントは大抵、Sprintの最中に実施されます。

リファインメントは プロダクトオーナーや、ビジネス分析グループなしには完了できません。彼ら抜きで完了させてしまうことは、情報の分散や伝達ロスによる リーン的ムダ を増大させます。
また、スクラムはチームを方式検討/テストなど役割で分担することを禁止しているので、チームの一部ではなく、チーム全員がプロダクトバックログリファインメントに取り組みます。

プロダクトバックログリファインメントの概要

多くの場合、プロダクトバックログリファインメントは以下の3つのやり方で実施されます。

• 全体プロダクトバックログリファインメント（全チームで共有）
• チームレベル プロダクトバックログリファインメント
• 複数チーム プロダクトバックログリファインメント

全体プロダクトバックログリファインメント

LeSSのルールを読んでいると以下のような疑問が湧くでしょう。
どのチームがどのPBIの詳細化を行うべきか？
共通理解、協力、やり方の統一、見積もり基準の統一、専門性と俊敏性のバランスが、スケーリングにより難しくなるのではないか？
全体プロダクトバックログリファインメントがこれを解決します。

個別チームのプロダクトバックログリファインメントの前に、チームの代表者によって全体プロダクトバックログリファインメントを行うことで、どのチームがどのPBIに取り組むのが良さそうか考えたり、各PBIについて理解を深め、粒度を揃えたりできます。全体プロダクトバックログリファインメントには、PO、その分野の専門家、各チームの代表者（または全員）が参加します。
コスト対効果の観点で全員が出る必然性はありませんし、規模を少人数にとどめるためにも、代表者に任せるのが大抵は望ましいです。

全体プロダクトバックログリファインメントでは以下を行います

• 大きなPBIの分割
• PBIに対する、簡単な分析と基本的な理解
• 見積もり
• 一緒にまとめてやるほうが良さそうな、関係性の深いPBIたちを分類する

チームレベルプロダクトバックログリファインメント

リファインメントは ユーザ/顧客/ステークホルダーと一緒に実施するのが理想的です。新たに見積もったものや分割したものなど、プロダクトバックログに行った変更点はプロダクトオーナーに伝えましょう。

複数チームプロダクトバックログリファインメント

複数チームプロダクトバックログリファインメントは、複数チームが、同じ時間、同じ場所で実施するプロダクトバックログリファインメントです。
参加者は、話題になるであろう分野に詳しい人と参加チームの全員です。

全体プロダクトバックログリファインメントとの違いは何でしょうか？全体プロダクトバックログリファインメントは 全チームが参加しますが、 複数チームプロダクトバックログリファインメントは 2チームぐらいの少数チームで行います。
複数チームプロダクトバックログリファインメントは 代表者だけより、全員が出るほうが望ましいです。

複数チームプロダクトバックログリファインメントを行うことで、結びつきの強いPBIに複数チームで取り組むための、共通理解を深めたり、 協力のチャンスを開拓したりすることができます。

複数チームプロダクトバックログリファインメントは、チームレベルプロダクトバックログリファインメントを補完したり、（場合によっては）置き換えたりする事ができます。