プロダクトバックログリファインメントってどうやるの？

こんにちはこんばんは。スクラムマスターの いのもえ です。

先日、チームのレトロスペクティブでプロダクトバックログリファインメントでは何をするべきか？という話になりました。
たしかに、プロダクトバックログリファインメントはスクラムイベントではなく、スクラムガイドでも具体的な記載が少ないアクティビティだと感じています。
「これが正解だ」というわけではありませんが、今の考えを基にプロダクトバックログリファインメントのありたい姿や、そうなっているかのチェックリストを作ってみました。
試験的に有料コンテンツ（課金ではなく拡散でも OK ）として公開してみますので、興味を持っていただけましたらぜひ課金または拡散をお願いします！

用語定義

この記事では以下の通りに読み替えてください。

PBR = プロダクトバックログリファインメント
PBL = プロダクトバックログ
PBI = プロダクトバックログアイテム
チーム = LeSS における「チーム」のこと。プロダクト開発者たち。

プロダクトバックログのありたい姿

PBR は「PBL の refinment」ですから、まずは PBL のありたい姿を考えます。
私の解釈では 直近 2-3 スプリントは明確になってて、それ以降は粗くて OK （粗い部分では現在と矛盾しているのも OK ） です。

以下の記事の 29 ページ目のイメージです。なぜそのようにしたほうが良いのか、わかりやすい解説が 26 〜 29 ページに載っています。

プロダクトバックログ Deep Dive

プロダクトバックログアイテムのありたい姿

PBR で触るのは具体的には PBI ですから、 PBI のありたい姿も考えておきます。
私の解釈では 以下の次の点を満たせば OK です。

- 各 PBI が提供する価値が明確になっている
- PBI それぞれで価値が提供できる状態になっている
- 大体 1/4 スプリント以下で終わるくらいのサイズになっている

※直近 2-3 スプリントに対応するアイテムについて

そのように考える理由は、簡単には以下の通りです。

• 取り組む内容に明確な優先順位をつけるため

  • 価値が明確になっていれば、特に価値が大きいものやリスクが高いものを優先して取り組むことができる。 1 つの PBI に複数の要素があると、優先したいこととそうでないことが混ざりあわざるを得ない

• 各スプリントで確実に顧客に価値を届けるため（もしくは顧客に価値を届けられるか検証するため）

  • アイテムごとに価値がない状態（例えば「要件定義」「実装」などプロセスごとに PBI を作っている場合）にはスプリントで価値を提供できない可能性がある

  • アイテムのサイズが大きすぎると 1 スプリントに終わらない可能性が出てくる

  • アイテムのサイズが小さすぎると PBL の管理が大変すぎる

プロダクトバックログリファインメントのありたい姿

リファインメントの目的

スクラムにおける PBR の目的は、 PBL の最新化です。
私の解釈では、 PBR を通して PBL が以下の状態になっていれば OK です。