プロダクトバックログリファインメント
はじめに
はじめまして。 IT エンジニア部の與野と申します。 新卒で入社してもうすぐ 2 年が経とうとしています。 ブログを投稿するのが初めてで、拙いところもあると思いますがよろしくお願いします。
この記事は約半年間、社内向けにアジャイルコーチの雨宮さんが実施したアジャイルトレーニングを受けて、 自分が気になったトピックについてまとめたものです。
記事について
プロダクトバックログリファインメント（以下リファインメント）*1 の有用性の説明をするとともに実施方法についても言及します。
また、最後にアジャイルトレーニングを受けた感想も一緒に残したいと思います。
リファインメントとは？
まずはスクラムガイドではどのように定義されているか見てみましょう。
スクラムガイド（2017 年版）のプロダクトバックログの項に登場します。
プロダクトバックログに含まれるアイテムに対して、 詳細の追加、見積り、並び替えをすることを、 プロダクトバックログのリファインメントと呼ぶ。 これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。 プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。 いつどのようにリファインメントをするかは、スクラムチームが決定する。 リファインメントは、開発チームの作業の 10%以下にすることが多い。
最新のスクラムガイド（2020 年版）でもプロダクトバックログの項にて確認できます。
リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。 作業を行う開発者は、その作業規模の評価に責任を持つ。 開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。
以上のことから、スクラムガイドではプロダクトバックログアイテム（以下 PBI）の詳細・見積もり・優先順位付けを PO と開発チームが協力して決めていく作業だと分かります。
また、開発チームの作業の 10％以下（２週間スプリントなら半日〜１日程度）というところからもスクラムにおけるリファインメントの重要度が分かるかと思います。
リファインメントが必要な理由
自分も何度か経験がありますが、スプリント期間中に仕様の漏れが判明して、その仕様を詰めるために PO と何度も確認したことはありませんか？
リファインメントを定期的に実施しなければスプリント期間中、開発に集中出来なくなってしまいPBIを完了することが出来なくなったり、リリース作業が遅れてしまう問題が発生してしまいます。
UI デザイナーによるワイヤーフレーム作成や、エンジニアチームによる調査タスクなど、スプリントが開始される前に必要な準備を Ready として定義し、 開発着手前に済ませておくことが大切です。
そうすることによってスプリントをスムーズに開始出来、開発者は仕様の確認をする回数が減り、集中してPBIに取り組むことが出来ます。
しかし、リファインメントを実施せずにスプリントプランニングに入ってしまうと、プランニング時に仕様が固まりきっておらず、今回のスプリントで開発する PBI を選択できなくなってしまいます。
ですので定期的にリファインメントを実施して PBI が Ready な状態になっているかを確認することが重要です。
（Ready な PBI とは 仕様が⼗分に検討されており、Done や受⼊基準が明確で、独⽴しており、⾒積もりがなされている、適切な規模の PBI を指す）
「Ready なバックログ項目がなければ、開発チームはビーチに行ってよい」 by Jim Coplien
と言われている通り、次スプリントで取りうる PBI を Ready の状態にするためにリファインメントを定期的に実施しましょう。
リファインメントの実施
リファインメントの実施はスプリント中盤や最終日の 1 日前や 2 日前に実施するチームが多いみたいです。 会議に参加するのは PO とエンジニアチームですが、会議を 数日に分割し一部の PBI を PO と数人のエンジニアで実施することもあります。 PO がメンバーを招集し、以下のことを確認します。
- PBI の追加・変更・削除
- PBI の分割・粒度の変更
- PBI の明確化・詳細化
- PBI の並び替え（優先順位付け）
- Ready/Done 条件の定義（DoR/DoD）
- 受入基準（A/C）の定義
- PBI の見積もり
PBI の追加・変更・削除
PBI の追加・変更・削除を行う
PBI の粒度調整・分割の変更
次に取りうる PBI の粒度を INVEST*2 で確認し、PBI の規模が大きい場合、分割して 1 つの PBI を小さくする。
PBI を 1 スプリントに収まるサイズを目安に分割する。
PBI の明確化・詳細化
PBI の詳細を書く。 必要があれば仕様をまとめ、仕様書を作成する。
PBI の並び替え（優先順位付け）
どの PBI を優先すべきかはプロダクト観点・技術的観点から考える必要がある。
Ready/Done 条件の定義（DoR/DoD）
Ready 条件を満たせているか確認する。
（ここで言う Ready は先に実施しておかなければならない作業がないかを確認する）
エンジニア観点での Done 条件は『ユニットテストがされているか』など。
受入基準（A/C）の定義
PO 観点での受入基準は『プレビュー押下時に入力内容を確認できる』など。
PBI の見積もり
PBI の仕様を確認し、規模を算出する。
ここで重要なのは時間（Hour）で考えるのではなく、規模（Point）で考えることを意識する。
まとめ
ここまでリファインメントの役割、リファインメントしなかった場合に陥ってしまう問題、実施方法について説明してきました。
変化の早い現代では日々要求が変更されます。 それに伴い、リファインメントはますます重要度を増しています。 しかし、スクラムガイドでは公式のスクラムイベントとして定義されておらず、多くのチームはスプリントプランニングと同時にリファインメントを実施されているのではないでしょうか。
スプリントプランニングとリファインメントをまとめて実施すると、スプリントプランニングが肥大化してしまいます。 定期的にリファインメントを実施することによって、会議に拘束されるメンバーの時間を最適化しましょう。
今回の記事でリファインメントを実施できていないチームや、リファインメントを実施するメリットがいまいちわかっていない方の助けになれたらと思います。
最後に
約半年間アジャイルトレーニングを受けて、スクラムや他のアジャイルの手法についてよく学べました。しかし、実践してみなければ理論だけではなかなか難しそうだとも同時に感じました。 「スクラムは理解は容易だが、習得（実践）は難しい」と言われる所以だと思います。
自分はこれまでスクラムの体制で開発をしていましたが、トレーニングを受けて会議体の意義やスクラムでするメリットを改めて感じることが出来ました。 特にリファインメントについて、自分は元々ストーリーポイントを時間で考えてしまっていたので、「規模・大きさで計測する」ということをメリットも含めて学ぶことが出来ました。
例えば、A 点から B 点まで移動にかかる時間を考えるのではなく、距離で考えると言った感じです。 そうすることにより、同じような機能を作るときに同じポイントをつけることが出来*3、 結果としてチーム全体で取ることの出来るポイントの総数が増えてチームの成長が実感出来ると言う流れです。
実際にやってみることがスクラムでは大事だと思うので、実践して自分なりの開発フローを構築していきたいと思います。
最後に、不思議な質問をしても理解するまで付き添ってくれた雨宮さんに感謝します。
*1:少し前までリファインメントはグルーミングと呼ばれていましたが、現在はグルーミングという言葉は非推奨になっております。
*2:INVESTは
Independent：独立している
Negotiable：調整可能である
Valuable：ビジネス価値がある
Estimable：見積もり可能である
Small：手ごろなサイズである
Testable：テストが可能である
の頭文字を取った単語です。
より詳しくはwikiを参照してください。
https://ja.wikipedia.org/wiki/INVEST
*3:『同じような機能』なので規模は同じ。
時間で考えた場合、既に経験があるためポイントを前回よりも下げてしまう。
こうしたときの問題は、チームが取れるポイントが上がらないため、成長を感じる事ができない。
