プロダクトバックログリファインメントはいつ何をするのか

みなさんこんにちは。@ryuzeeです。

プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。

まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。

スプリントでの説明（9ページ）

スプリントでは、（中略）
プロダクトバックログを必要に応じてリファインメントする。

スプリントプランニングのトピック2での説明（10ページ）

開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。

プロダクトバックログでの説明（13ページ）

1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。

またスクラムガイド2017のなかでも記述があります。関係の深い箇所のみ紹介します。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。

これを踏まえて、整理していきましょう。

プロダクトバックログリファインメントでは何をするのか？

スクラムガイドの記述をまとめると、プロダクトバックログリファインメントでは以下のようなことを行うとあります。

プロダクトバックログアイテムを新たに作る
プロダクトバックログアイテムを分割する
プロダクトバックログアイテムを詳細にする
- プロダクトバックログアイテムの説明を追加・更新する
- プロダクトバックログアイテムの並び順を更新する
- プロダクトバックログアイテムのサイズを追加・更新する（見積もる）

ただし例によって例のごとくスクラムガイドには最低限のことしか書いていないので、この記述の背後にある考え方をもとにして、具体的にどんなことをするのかを考える必要があります。

プロダクトゴールを確認する

プロダクトバックログアイテムはプロダクトゴールを達成するためのものなので、議論や作業の前提としてプロダクトゴールに着目する必要があります。スクラムチーム全体がプロダクトゴールに集中していないと、進む方向が定まらず意味のないプロダクトバックログアイテムに取り組んでしまうことにもなりかねません。そうならないよう、プロダクトオーナーは、プロダクトバックログリファインメントに限らず、さまざまなタイミングで繰り返しプロダクトゴールをスクラムチーム全体に定着させなければいけません。

プロダクトゴールの観点では、以下のようなことをします。

現在取り組んでいるプロダクトゴールを確認し、現在どのような状況なのか、プロダクトゴールがいつ頃達成できそうなのかを確認する
必要であれば、プロダクトゴール自体をより洗練したり具体化したりする
現在のプロダクトゴールが達成間近であれば、次のプロダクトゴールを検討する、もしくは検討するための準備をする

今後のスプリントゴールのアイデアを考える

スクラムではプロダクトゴールを達成するために、スプリントごとにスプリントゴールを達成していきます。したがって、スプリントプランニングでプロダクトオーナーがいきなりスプリントゴールのアイデアを持ち込んで、スクラムチームが初見でそれを議論するというような形は考えものです。プロダクトオーナーとしては、数スプリント先くらいまではスプリントゴールのアイデアを持っておき、それはスクラムチームと共有して理解してもらい、フィードバックを受けるようにしましょう。スプリントゴールのアイデアがあれば、プロダクトバックログアイテムの並び替えが容易になります。

プロダクトバックログ全体を手入れする

スプリントゴールのアイデアが考えられていれば、プロダクトバックログアイテムはある程度それに沿って並び替えられるはずです。プロダクトバックログ全体を見ながら、並び順が最新の情報に基づくものになっているかを確認し、そうなっていなければ並び替えましょう。並び順が最新になっていない段階で、上位のプロダクトバックログアイテムの詳細を議論しても仕方ありません。

また、プロダクトバックログアイテムはさまざまなきっかけて増えていきます。たとえば、以下のようなきっかけです。

スプリントレビュー
サポートや営業へのリクエスト
ペルソナの見直し
ユーザーインタビューや観察
メトリクスやログの分析
開発者のペイン
技術要素の変化（バージョンアップ、サポート切れ、セキュリティ対応……）

これを放置しておくと、あっという間にプロダクトバックログが肥大化して、何をするにも時間のかかる手の負えない代物になってしまいます。

こうならないように、プロダクトバックログ全体に目を通し、似たようなプロダクトバックログアイテムを統合したり、不要なプロダクトバックログアイテムを捨てたり、一旦アイスボックス（捨てる前に一時保管する場所）に移したりしなければいけません。

そうやって、プロダクトバックログをいつも整理された状態に保つようにします。

上位のプロダクトバックログアイテムをReadyにする

スプリントプランニングで扱うためには、プロダクトバックログアイテムは1スプリント以内で完成できるサイズになっていなければいけません（間違っても1つのプロダクトバックログアイテムを複数スプリントに渡って開発しようとしないでください）。そのため、大きな関心ごとは、プロダクトバックログの上位にあって、直近数スプリント以内に着手しそうなプロダクトバックログアイテムが、スプリントに持ち込めるくらいの状態（これをReadyと呼びます）になっているかどうかになります。

スクラムチームによっては、プロダクトバックログアイテムがどのような状態になればReadyなのかを明文化することもあります。たとえば、以下のようなものです。

プロダクトバックログアイテムが用意されている
プロダクトバックログアイテムの価値が明確である
開発を進める上での大きな疑問や決定すべき事項がない
開発者全員が何をつくればいいか理解できている
受け入れ基準が明確である
他のプロダクトバックログアイテムとの依存関係が明確である
プロダクトバックログアイテムが見積もられている
パフォーマンスなどの非機能要件が明確になっている
デモの手順が明らかになっている
……

なお、今スプリント内のプロダクトバックログリファインメントで、次のスプリントで着手しそうなプロダクトバックログアイテムのリファインメントを慌ててやらないようにしてください（生煮えのまま時間切れとなり、見切り発車に繋がりやすいためです。自転車操業とも言います）。2〜3スプリント前くらいから準備しておくことをお勧めします。

プロダクトバックログリファインメントの実施タイミング

スクラムガイドの記述で明示されているのは、

スプリントのなかで実施する
スプリントプランニング中に実施することもある
継続的な活動である

です。スクラムでは5つのイベント（スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ）を定めていますが、プロダクトバックログリファインメントはスクラムイベントではありません。

スクラムイベントではないので実施のタイミングは特に決まっていませんし、回数も決まっていません。自分たちに合うように実施のタイミング、実施の回数、やり方を考えてください。

実施タイミングの例をいくつか挙げておきます。組み合わせ可能なものもあります。

毎日デイリースクラムが終わったあとに最大30分で行う
毎週金曜日の15:00-18:00に行う
スプリントの中間日に2時間行い、スプリントレトロスペクティブが終わったあとに1時間行う
スクラムチームが集まっているタイミングで随時必要に応じて行う
1つのプロダクトゴールを達成したタイミングで、まとめて時間を取って行う

どれくらいの時間をプロダクトバックログリファインメントに使うかは、スクラムガイド2020では記述はありませんが、スクラムガイド2017では「開発チームの作業の10%以下にすることが多い」とされています。開発の時間を取るためにプロダクトバックログリファインメントの時間をなるべく減らしたい衝動に駆られるかもしれませんが、準備が不十分なプロダクトバックログアイテムをスプリントに投入すれば結局ムダが発生します。スクラムチームとして、どのくらいの時間をプロダクトバックログリファインメントに使うと良さそうかは検査と適応の対象なので、色々と実験をしてみて自分たちに適切な時間配分を探すとよいでしょう。

プロダクトバックログリファインメントは誰がやるのか

スクラムガイド2020では「スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する」とあります。スクラムガイド2017では「プロダクトオーナーと開発チームが協力して行う継続的なプロセスである」とあります。

スクラムマスターの責任を念頭におくと、プロダクトバックログリファインメントは、プロダクトオーナーと開発者が協力して行う取り組みであり、必要に応じてスクラムマスターが支援することになります。それぞれの責任がどんなことをするのかの例を以下で簡単に紹介します。なお、プロダクトオーナーはプロダクトバックログの管理に責任を持ちますが作業自体は委任できます。したがってチームによって作業内容は変わる可能性があります。

プロダクトオーナー
- プロダクトゴールを洗練する
- 今後のスプリントゴールのアイデアを共有する
- 新しいプロダクトバックログアイテムを作る
- 不要なプロダクトバックログアイテムを削除する
- プロダクトバックログアイテムの並び順を決定する
- プロダクトバックログアイテムの内容や要求を明確にする
- ビジネスの価値やステークホルダーのニーズに関する情報を提供する
開発者
- 新しいプロダクトバックログアイテムを作る
- プロダクトバックログアイテムの内容や要求を明確にする
- プロダクトバックログアイテムの詳細化や分割の提案をする
- プロダクトバックログアイテムを見積もる
- プロダクトバックログアイテムに対して技術的な観点からフィードバックを提供する
- プロダクトバックログアイテムの実装に関する疑問点や懸念を挙げる
- プロダクトバックログアイテムの並び順を提案する
- 不要なプロダクトバックログアイテムを挙げる
スクラムマスター
- プロダクトバックログリファインメントを効果的に進行する手助けをする
- 必要に応じて、プロダクトオーナーと開発者とのコミュニケーションを促進する
- スクラムのプラクティスや価値観に沿うようにする

これは、プロダクトバックログリファインメントを常にプロダクトオーナーと開発者全員が揃って同期的にやらなければいけないというわけではありません。スクラムチームとして協力して行う、つまりスクラムチーム全員がプロダクトバックログに注意を払い、最新に保つように必要な作業を行うことを意味します。

プロダクトオーナーはプロダクトバックログアイテム供給マシーンではありません。プロダクトバックログリファインメントをすべてプロダクトオーナーにやってもらうことはできません（そもそも見積りは開発者しかできません）。

またプロダクトオーナーと、開発者のうち一部の人たちだけでプロダクトバックログリファインメントをやるのも機能しない可能性があります。時間効率を考えるとこのようなやり方をしたくなるかもしれませんが、残りの人たちに中身を伝える時間が結局必要になりますし、スプリントで着手してみたら一部の人にとってはReadyでないことがわかる可能性もあります。 スクラムチームとして、プロダクトバックログ全体に対する共通理解が重要です。