謎のイベント「リファインメント」とは何か

これは豆蔵デベロッパーサイトアドベントカレンダー2024第16日目の記事です。

アジャイルグループの石田です。今回は、「リファインメント」に関する話題です。

みなさん、リファインメントしてますか？スクラムガイドにその言葉はあるものの、スクラムイベントの中には入っていないし、どういうものなのかもイマイチはっきり書いていなくて、スクラム初心者にとっては最も謎なイベントなのではないかと個人的には思っています。

今回はそんなリファインメントについて考えてみたいと思います。

リファインメントという言葉自体、英単語の中でもあまり馴染みのあるものではありません。そこでまずは、そもそもの意味での「refinement」とは何なのか、英和辞典で確認してみましょう。

スクラムで使うリファインメントという意味では、プロダクトバックログアイテムの「洗練」「改善」「改良」あたりが適合するでしょうか。

では次に、スクラムガイドの記載についてです。例によって最新の2020年度版から見てみましょう。それは、プロダクトバックログの項目の中の一段落として記載されています。

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

リファインメントは、プランニングをする前の準備としての、プロダクトバックログアイテムの分割、詳細の追加、見積もり、並び替えをする活動です。
また、スプリントプランニングの項目の中にも、次のような記載があります。

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

「リファインメントをする場合がある」とあるため、リファインメントはスクラムの中でしてもしなくてもいい活動、と捉えてしまうかもしれませんが、それは違います。この「場合がある」は、「プランニングの中でもする場合がある」とかかっています。通常リファインメントは、そのバックログの開発にとりかかる前のスプリント中（プランニング前）に実施されます。

ちなみにこの文章は、原文である英語版では以下のように書かれています。

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

英語では、「refinement」という名詞ではなく、「refine」という動詞で記載されています。

ですので、この文の訳としては、

スクラムチームはスプリントプランニングの中で、プロダクトバックログをより洗練させることもある。

とした方が、しっくりくる気がします。

前文の中でも、

プロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。

とあるように、プランニング時にはリファインメントが終わり、準備ができている必要があります。
ですので、プランニングの中でもリファインメントをすることがある、という表現は間違っていて、プランニング中の開発者とプロダクトオーナーの会話を通じて、準備が終わっているバックログアイテムがより洗練される、という意味での「refine」なのではないかと思います。

スクラムガイド2020の中では、「スプリントプランニングのときには（バックログアイテムの）選択の準備ができている」以上の、スプリント中のいつ、どれくらいの時間実施するかについては記載されていません。この部分については、2017に少し記載があります。

いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。

いつどうやってやるかはチームで決めてね、という若干投げやりな感じではあります。プランニングやレトロスペクティブのように、明確に実施タイミングが決まっているわけではありません。これが、リファインメントがスクラムイベントとしては定義されていない理由なのでしょう。

実施方法としては、毎日30分ずつする、決まった曜日に2-3時間まとめてする、人がいるタイミングで随時する、というふうに、スクラムチームならではのやりやすい方法を探ることになります。

実施時間の目安は、開発チームの作業の10%以下とされています。逆に言えば、10%程度は開発ではなくリファインメントに時間を使っても良いとも言えます。
どうしても開発に使う時間を増やしたいと思ってしまうかもしれませんが、結果的にはしっかりリファインメントを行うことが、次スプリント以降の開発のやりやすさ、スピードに関わってきます。

プロダクトバックログの詳細を書く、と言っても、どこまですればリファインメントが終わりになる（プランニングが可能になる）のか、チームの中で認識を合わせておく必要があります。そこで効果を発揮するのが、「Readyの条件」（準備完了の条件）です。

プロダクトバックログがどのような状態になっていればプランニングが開始可能なのか、チームで話し合って決めておきます。こうすることで、本来開発の中ですればいいことまでリファインメントでやってしまい、時間をかけすぎてしまうことを防ぎます。

例えば、

• デザインが決まっていること
• 受け入れ条件を開発者みんなが理解していること
• 見積もりがされていること

などが考えられます。

スクラムガイドの中では「完成の定義」という言葉がよく出てきますが、これはプロダクトバックログアイテムを完了とするための基準になります。
「Readyの条件」で始まり、「完成の定義」で終わる、とセットで考えるといいでしょう。

リファインメントは、スクラムイベントではないし、開発作業とも言えないし、いつやりなさいとも言われていないし、スクラム初心者にとってはやはり謎な部分が多いと思います。
しかしリファインメントを通してバックログアイテムを洗練させ、開発をスムーズに開始するためにも、今日もリファインメントに取り組んでいきましょう。