スクラムマスターを雇う時に聞いてみるとよい質問に答えてみた: PBL のリファインメントと見積りについて
こんにちはこんばんは。スクラムマスターの いのもえ です。
「スクラムマスターを雇う時に聞いてみるとよい 38 個の質問」に答えていくシリーズです。
今回は「プロダクトバックログのリファインメントと見積りについて」のテーマで回答していきます。
他のテーマについては以下からお読み頂けます！
プロダクトオーナーはステークホルダーの要求をプロダクトバックログアイテムに落とし込んでその見積りをチームに求めることになる。その流れでよいか？
要求をプロダクトバックログアイテム（PBI）へ落とし込むことをチームもできるようになったほうが、よりスクラムのメリットを享受できると感じます。
というのも、この状況が続くとプロダクトオーナー（PO）がボトルネックになりますし、チームがステークホルダーと直接やりとりできる機会が少なくなり、結果として多くのアウトカムを得づらい環境に近づくと考えるからです。
PO にはプロダクトの大きな判断（例えば海外進出するぞ！とか）に集中してもらい、ある程度まで（例えば既存機能の改善など）はチームで判断できると良いと考えています。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
望ましいのは、これらの情報をプロダクトオーナーを介さずに得られる状況を作ることだと考えています。
そのため、マーケット状況などをプロダクトオーナーが恒常的に知るために使っているものを教えてもらうのが良いと考えました。
また、もしこれが PBI の作成などに直接紐づくものなのであればプロダクトビジョンやその背景となる課題についてプロダクトオーナーに語ってもらうのが良いのではと思いました。
誰がユーザーストーリーを書くとよいか？
ユーザーストーリー ≒ PBI と想定して回答します
書く分には、誰が書いても良いと思います。不適切な内容だったり、不要な内容であったりするのであれば必要に応じてプロダクトバックログリファインメント（PBR）で改善していけば良いと思います。
「誰が書くとよいか」という論点からは少し外れますが、誰でも理解しやすくするために、課題感（why）は明確にしておくと良いと思います。
よいユーザーストーリーとはどんなものか？どんな構造か？
単体で 1 つのユースケースを表しており、かつ 1 スプリントに確実に収まるサイズ感になっているものが良いと考えています。
「単体で 1 つのユースケースを表す」のは、実現したいユースケースの漏れがないことを確認する、小さい単位でユーザーに触ってもらえる（フィードバックを受けることができる）といったメリットがあります。
「1 スプリントに確実に収まる」のは 1 スプリントで確実に進捗させるというメリットがあります。また、 LeSS ではサイズの目安を「1/4 スプリントに収まる程度」と表現しており、より具体的でわかりやすいので今所属しているチームに説明する場合にはこの表現を利用しています。
「Readyの定義」には何が含まれているべきか？
ユーザーストーリーを時間で見積もらないのはなぜか？
引用している質問は 2016 年以前に書かれたものですが、私が CSM 研修を受けた 2023 年時点では「不確実なまま進む必要がある場合もあるため、 Ready は定義すべきではない（定義してしまうと Ready にするための作業が大きくなりすぎる傾向にあるため）」とはっきり伝えられました。そのため、前半については回答しません。
前提として、見積もり方法についてスクラムでは言及がないため、こちらはスクラムに関する質問ではないと判断しています。そのうえで、私の考えは以下です。
ユーザーストーリーを時間で見積もらないのは、見積もりの精度を求めすぎないためだと考えています。
正確に見積もろうとすると、具体的な設計や計画が必要になっています。加えて、いくら正確に見積もろうとしてもそれが実際にかかったものと一致することは極めて稀です。また、見積もりがコミットメントだと誤解されて、実際にかかったものと差異があったときに責められてしまう場合もあります（転じて、見積もりを大きくしてその状況を回避するようになり、結果的に見積もりは実態とは離れていってしまいます）
そもそも見積もりに時間を使わないことで、数字遊びに近いこのような状況を回避する意図があると考えています。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
チケット = PBI と想定して回答します
PBR で優先順位およびやる/やらないの判断をし、やることになったものは順に対応することになると考えています。スクラムという前提で考えると PBI の数が 200 というのはかなり多い状態に感じるので、「いつかやるかも」レベルの課題感の PBI については削除したり、大きな課題感でまとめて 1 つにしてしまったほうが扱いやすい PBL になるのではと思います（まとめた場合は、着手目処が立ったタイミングで PBR にて分割するイメージです）。
PBR はスクラムイベントではないため具体的な実施タイミングはチームによると思いますが、スプリントプランニングでは最新のプロダクトバックログを利用できる状態を保つべきと考えています。
〆
2023 年に見ると内容が変わりそうな質問が多かったのが印象的なテーマでした。 PBR はスクラムイベントではないせいか具体的な記述も少ないと感じており、面接で深めるには良いテーマかもしれませんね。
他のテーマはこちらから
よろしければサポートお願いします！いただいたサポートは入浴剤や飲み物など、息抜きに使わせていただきます🤗