はじめに

SHIFT ASIAでプロジェクトマネージャー/スクラムマスターを務めているSONICです。

スクラムを導入したプロジェクトでプロダクトバックログリファインメント（以下、リファインメントという）を実践されている方は多いと思いますが、スクラムガイドラインにおける記載は少なく、実務でどのように適用していけばよいか分からないと感じている人も多いのではないでしょうか。
私もスクラムのプロセスに慣れていなかった頃は、リファインメントの意義やプラクティスを理解できていなかったため、リファインメントを適切に実践できていませんでした。

しかしながら、スクラムサイクルを何度も経験する中で、スクラムが機能しなくなる一つの原因が「リファインメントを適切に実施していないこと」にあると気づきました。

こちらの記事を訪れた皆さんのなかにも、リファインメントについて学んだ上で実際にプロジェクトに適用してみたものの、いつ・どの程度までリファインメントを行えばわからないという方もいらっしゃるのではないでしょうか。

そこで本記事では、うまくリファインメントを活用できず悩んでいる方や、あるいはスクラムで発生するトラブルを未然に防ぎたいという方に向けて、私自身も経験したリファインメントの実践方法や運用のポイントについて詳しく解説します。
本記事で取り上げるリファインメントの活用方法を通じて、あなたのスクラムチームの開発オペレーション改善につながれば幸いです。

なお、本記事ではスクラムに関連する専門用語が多く登場するため、スクラムについておさらいしたいという方は以下の記事も併せてご参照ください。

スクラムとは｜スクラムの定義や特徴、体制とチーム内の役割
スクラムイベントとは｜スクラムにおけるスプリントと4つのイベント
スクラムの3つの作成物｜プロダクトバックログ、スプリントバックログ、インクリメントについて

リファインメントとは

リファインメントとは、プロダクトバックログアイテムのユーザーストーリーとその重要度を見直すことで、スプリントプランニングでスプリントバックログを作成しやすくするための見直し作業です。

具体的には、スクラムチームとステークホルダーが一丸となって、プロダクトバックログアイテムに記載するユーザーゴールやストーリーを再考したり、何がユーザーにとって重要なのかを見直したりすることを指します。

リファインメントを行うことで、ユーザーに提供すべき価値をより深くスクラムチームに浸透させることができ、同時にデベロッパー（開発者）が具体的な実装方法や実装に必要な工数の見積りを検討するきっかけにもなります。

リファインメントの目的

リファインメントの目的は、スプリントプランニングの時点でデベロッパーがスプリントバックログを作成するための選択を行えるようにすることです。

スプリントバックログを作成する時点でユーザーストーリーが不明瞭な場合、デベロッパーがユーザーにどのような価値を届けるべきかが曖昧になってしまい、実装方法を検討したり見積りを行ったりすることが出来なくなってしまいます。
その結果、スプリントバックログが適切に作成できず、スプリントの完了基準が不完全な状態でスプリントが始まってしまいます。

私が過去に担当した案件では、プロダクトオーナーが他のプロジェクトにも参加しており、多忙さからプロダクトバックログのユーザーストーリーの記載が曖昧なままでした。

スクラムマスターの経験者であれば一度は経験すると思いますが、デベロッパーがユーザーゴールやストーリーを理解しないままスプリントが始まってしまうと、スプリント中に実装に関する不明点が生じることになり、そのたびにデベロッパーは質問文を作成したり、着手するタスクを切り替えたりすることで生産性が落ちてしまいます。
生産性が落ちることによって、完了の定義（品質基準）を満たせないままスプリントが終了してしまう可能性が高くなります。

そのプロジェクトでは、結果的にデベロッパーのユーザーゴールの理解不足に起因して負のサイクルに陥ってしまいました。そして次第に進捗報告や対策検討の比重が高まりリファインメントに割くことができる時間が減ってしまい、次のスプリント以降でも同じような負のサイクルに見舞われるということを経験しました。

こうした状況のなかで、日々忙しいプロダクトオーナーに向けて私が行ったことは、プロダクトバックログアイテムの情報を基に、各アイテムのユーザーゴールやストーリーの仮説を立て、実装要件を抽出し、スプリントレビューのタイミングで時間が余ったときにプロダクトオーナーにレビューしてもらうというサイクルを取り入れたことです。

その結果、プロダクトオーナーとステークホルダーは短い時間で認識の齟齬を確認し修正することができ、スプリントプランニングまでに着手予定のプロダクトバックログがデベロッパーにとって比較的着手しやすい状態になりました。また、手戻りが減ったことにより生産性も向上しました。

私が例として挙げた「負のサイクルの発生」を未然に防止するためにも、リファインメントは非常に重要なスクラムイベントです。たとえプロダクトオーナーが忙しい場合でも、スクラムマスターを中心に、スプリントプランニングの際にデベロッパーがスムーズにプロダクトバックログアイテムを選択できるように工夫しましょう。

リファインメントの実施方法

リファインメントのイベントゴールは、スプリントプランニングのタイミングで、デベロッパーがスプリントバックログの作成のためのアイテム選択を行えるようになることです。

そして、スプリントプランニング中のプロダクトバックログアイテムの選定に最低限必要な情報は、アイテムごとのユーザーゴール・ストーリーと実装要件の仮説です。

したがって私の考えでは、リファインメントのポイントは「いかに効率的かつ漏れのないように、プロダクトバックログの各アイテムのユーザーゴール・ストーリーや実装要件の洗い出しを行うか」にあります。

このポイントに基づき、参加者と開催時間、リファインメントの対象の３つに分けて解説します。

１．参加者

リファインメントの参加者は、理想的にはスクラムチームとステークホルダーの全員です。

ステークホルダーとデベロッパーが参加することで、ビジネス面と技術面の両方向からユーザーゴールと実装要件を洗い出すことができます。

また、ステークホルダーとプロダクトオーナーが参加することによって、両者間の優先順位についての認識をすり合わせられる機会にもなります。

さらに、ステークホルダーが出席していることから、デベロッパーからプロダクトオーナーへの質問に対する回答の品質も向上し、コミュニケーションコストの削減にもつながります。

２．開催時間

スプリントのインターバルによって確保すべき時間は異なります。１週間のインターバルでは１～２時間程度の時間を確保しておくことが一般的なようです。私のプロジェクトでは１週間のインターバルを取ることが多く、おおむね１～２時間程度の時間があればユーザーストーリーと実装要件についての洗い出しができています。

しかし、本質的なイベントゴールは、直近で着手するプロダクトバックログアイテムがスプリントプランニングで選定できる状態になっていることです。

そのため、スクラムチームの成熟度によっては開催時間を延ばしたり、事前に各自でユーザーストーリーや実装要件の仮説や質問事項を整理したりといった対応も必要になります。

３．リファインメントの対象

リファインメントのイベントゴールは、スプリントプランニングのタイミングで、デベロッパーがスプリントバックログの作成のための選択を行えるようになることです。

よって、リファインメントの対象になるプロダクトバックログアイテムは、直近で着手する予定のアイテムになりますが、スプリントが乱れてしまって次のリファインメントが実施できない場合に備えて、最低限直近のスプリント２回分をリファインメントの対象とするとよいでしょう。

リファインメントをうまく運用するための３つのポイント

リファインメントに明確なルールはなく、スクラムガイド2020においてもその目的を示す程度の記述に留まっています。

しかし、私自身の経験から、リファインメントを上手く活用するために必ず押さえておくべきポイントが３つありますので、参考としてこちらでご紹介します。

１．少なくとも着手２週間前には、プロダクトバックログアイテムのブレイクダウンを完了させておく

ブレイクダウンとは、プロダクトバックログアイテムのユーザーゴール・ストーリーを詳細化することを指します。

具体的には、デベロッパーが「ユーザーがシステムの利用を通じて何をしたいのか」をイメージでき、またスプリント中にデベロッパーからの質問が出ない程度にまで、プロダクトバックログアイテムをいくつかの詳細なタスクに分割したり実装要件をタスクチケットに記載したりすることです。

スプリントプランニングのタイミングでデベロッパーがユーザーストーリーを理解できない場合、適切な実装工数の見積ができず、またスプリント中に質問事項が発生することによって前述したような負のサイクルが発生してしまいます。

ブレイクダウンの過程でデベロッパーから質問が出てくることもありますので、プロダクトオーナーが質問に回答する時間を確保するため、少なくとも着手２週間前のタスクまでは事前にブレイクダウンを完了させておくことをおすすめします。

２．リファインメントを定期化する

スクラムガイド2020では、リファインメントは定期的に開催すべきイベントとして特に規定されていません。

しかしながら、リファインメントを不定期開催にすると、いつまでもスクラムチームでリファインメントが習慣化されず、結果としてプロダクトバックログアイテムが適切にブレイクダウンされていない状態が常態化してしまうということを、私自身も何度も経験しました。

そうならないための対策として、プロジェクトのスプリントインターバルが１週間の場合は、あらかじめリファインメントのための定期のミーティングを30分間設置することにしています。

一方で、それが無駄なミーティングになってしまわないように、着手２週間以内のタスクブレイクダウンが済んでいれば、必ずしも30分間という時間にはこだわらずに早めに終了するようにしています。
これによって、スプリント内のアクションを習慣化しつつ、過剰なミーティングを避けるようにバランスをとることができています。

このように、リファインメントを定期化することで、臨時ミーティングの調整コストやリファインメントを開始するときのミーティングゴールを説明するコストなども省けるため、生産性をより高い状態で保つことができていると実感しています。
そのため、リファインメントはスプリント毎に定期的に行い、スクラムチームの習慣にしていきましょう。

３．タスク管理ツールは「タスクチケットの順番入れ替え機能」があるものを選ぶ

これまでにスクラムに関する様々な記事を読んできましたが、プロダクトオーナーによるプロダクトバックログアイテムの優先順位の見直しは、リファインメントの際に行うこととされているケースが多いようです。

しかしながら、リファインメントで優先順位の順番を見直し、コミュニケーションを取ってしまった場合、ユーザーゴールやストーリーを検討する時間がなくなってしまいます。

そのため、私がおすすめしているやり方は、タスク管理ポリシーに以下の2つを加え、また、それを実現するためにタスク管理ツールにドラッグ＆ドロップによるタスクチケットの順番入れ替え機能があるツールを選定しておくことです。

• スクラムチームはプロダクトバックログアイテムを上から順番に着手する
• デベロッパーがタスク起票を任された場合を除いて、タスクの順番の入れ替えはプロダクトオーナーのみが行うことができる

このようなタスク管理ポリシーを設定することで、プロダクトオーナーが優先順位を決めるための作業は、任意のタスクチケットの順番を上下するだけとなります。

任意のタイミングかつ、わずかな時間で優先順位の変更を表現できるようになるため、プロダクトオーナーはステークホルダーからの優先度の変更の要望にも迅速に答えられ、コミュニケーションミスやコストもかからずにデベロッパーに優先順位を伝達できるようになります。

リファインメントの時間をユーザーストーリーと実装要件のブレイクダウンにフォーカスできるように、タスク管理ツールは「タスクチケットの順番入れ替え機能」があるものを選定するようにしましょう。

まとめ

本記事では、スクラムのリファインメントについて、自身の経験を含めご紹介しました。さいごに、まとめとしてそれぞれのポイントについて振り返りましょう。

リファインメントの概要と目的

リファインメントとは、プロダクトバックログアイテムのユーザーストーリーとその重要度を見直すことで、スプリントバックログを作成しやすくするための見直し作業です。

スプリントプランニングの時に、デベロッパーがスプリントバックログ作成のための選択をスムーズに行えるようにすることで、スクラムが負のサイクルに陥ってしまうことを未然に防ぎましょう。

リファインメントの実施方法

リファインメントのポイントは、「プロダクトバックログのアイテムごとのユーザーストーリーや実装要件の洗い出しや検討を、いかに効率的かつ漏れなく行うか」です。
そのために、おすすめの参加者と開催時間は下記の通りです。

1. 参加者は、理想的にはスクラムチームとステークホルダーの全員
2. 開催時間は、スプリントのインターバルによって異なる。インターバルが１週間であれば１～２時間程度※ただし、直近で着手するプロダクトバックログアイテムがスプリントプランニングで選定できる状態になっていなければ、開催時間を延ばすか、もしくは事前にユーザーストーリーや実装要件の仮説や質問事項を整理することで会議の効率性を高める対応が必要になる

リファインメントをうまく運用するためのポイント３つ

1. 少なくとも着手２週間前には、プロダクトバックログアイテムのブレイクダウンを完了させておく
   理由：プロダクトオーナーが質問事項に回答するための時間を確保するため
2. リファインメントは定期化する
   理由：プロダクトバックログアイテムがリファインメントされていない状況を確実に避けるため
3. タスク管理ツールは「タスクチケットの順番入れ替え機能」があるものを選び、タスク管理ポリシーに以下の２点を加える

• スクラムチームはプロダクトバックログアイテムを上から順番に着手する
• デベロッパーがタスク起票を任された場合を除いて、タスクの順番の入れ替えはプロダクトオーナーのみが行うことができる理由：プロダクトオーナーがステークホルダーからの優先度の変更の要望にも迅速に答えられようにし、また、コミュニケーションミスなくデベロッパーに優先順位を伝達できるようにするため