プロダクトバックログアイテムの粒度の考え方

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

今日はTwitter経由で頂いた質問に回答したいと思います。質問は以下になります。

プロダクトバックログアイテムの粒度について教えてください。
ECサイトだとして、「購入者が販売商品を購入できる」というユースケースの場合、PBIに入れるユーザーストーリーとしては、「購入したい商品を検索し商品を確認できる」「購入したい商品を買い物カゴに入れる」「買い物カゴの商品を購入する」のような粒度で良いのでしょうか？
それとももっと細かいレベルまで分割すべきでしょうか？「購入者は購入したい商品の値段を確認できる」とか「購入者は購入したい商品の名称を確認できる」みたいなレベル感でしょうか？
複数画面をまたがり使用するデータベーステーブルはいつ決めてどうストーリーポイントを決めるのでしょうか？

それでは考えていきましょう。

1つのプロダクトバックログアイテムを複数のスプリントにまたがって開発することはない

スクラムガイド2020には以下の記述があります。

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

これは「スクラムチームが1スプリント内で完成できるプロダクトバックログアイテムは、スプリントプランニングで選択できる準備ができているとみなす」ということです。つまり、1スプリントに収まらないサイズの場合、スプリントで選択するためには、リファインメントを行って、プロダクトバックログアイテムが指すスコープを小さくしたり、複数のプロダクトバックログアイテムに分割したりしなければいけません（なお、スプリントプランニングのなかでリファインメントをすることもありますが、頻度や量が多い場合は事前準備が不足しています）。

一方で、すべてのプロダクトバックログアイテムが細かい粒度である必要はない（やめろ）

プロダクトバックログアイテムは順番に並んでいて、上位のものほど着手するのが早くなります。すなわち下位になればなるほど着手時期が遅くなったり、そもそも着手すらしなかったりします。当面やらないことをわざわざ小さいサイズに分割してしまうと、プロダクトバックログアイテムの数が膨大になってしまって、並べ替えもできません。そもそも作らないので分割するだけ時間のムダです。

すなわちプロダクトバックログアイテムの粒度は上位ほど細かく、下位ほど粗くなります。 そして、下位のものを上位に持っていく過程で、必要に応じてリファインします。直近2～3スプリント分くらいまでは1スプリントで扱えるサイズになっているとやりやすいと思います。

なお、スプリントで着手するプロダクトバックログアイテムは、1スプリントに収まるサイズになっていなければいけませんが、例えば、1スプリントに投入するプロダクトバックログアイテムが20個も30個もあるという場合はどうでしょうか？すなわちプロダクトバックログアイテムが極小サイズということですが、結論から言うと、これもよくありません。スプリントゴールの焦点がぼやけている可能性が高いですし、スプリントレビューでインクリメントを見せてフィードバックを貰うのが難しいかもしれません。

スプリント期間の長短によってプロダクトバックログアイテムの大きさは変わる

これは「1スプリントに収まるサイズ」という前提から当然のことですが、スプリント期間が短ければ、その期間内で完成できるもののサイズは小さくなりますし、逆にスプリント期間が長ければ完成できるもののサイズは大きくなります。

もちろんスクラムチームとして大きいプロダクトバックログアイテムを扱えるのか？という問題は別で残りますが、プロダクトバックログアイテムがスプリントの長さの影響を受けることは押さえておきましょう。

そもそもスクラムチームごとに能力は異なる

プロダクトバックログアイテムのサイズに大きく影響する要素の1つに、スクラムチームの能力があります。洗練されたスクラムチームで技術力も十分あり、継続的に技術的負債を返済するような取り組みをしているようなチームであれば、1スプリントのなかで多くのインクリメントを作れます。一方で、技術力に課題があったり、レガシーコードだったり、スクラムチームとしてあまり機能していなかったりすると、1スプリントで完成するインクリメントはごくわずかかもしれません。

前者のチームであれば、相対的に少々大きいプロダクトバックログアイテムでもスプリント内で完成できるでしょうし、後者のチームであればプロダクトバックログアイテムをだいぶ小さくしないとスプリント内で完成しないかもしれません。

スクラムチームは成長する

前述のとおりスクラムチームごとに能力は違いますが、スプリントレトロスペクティブなどを活用しながら改善したり、技術習得をしたりすることで、スクラムチームの能力は緩やかに上がっていくことがよくあります（成長の時間を取ってスクラムチームの成長にきちんと投資をしている場合）。

その結果、ある時点ではそのスクラムチームで扱えなかった大きさのプロダクトバックログアイテムが、成長とともに扱えるようになります。

スクラムでは何度も同じコードや同じテーブルに手を入れる

従来の開発スタイルでは、最初に要件を全部かためて設計・実装し、動いている箇所は触らないというのが多かったですが、アジャイルな開発ではこれは通用しません。つまりプロダクトバックログアイテムを実現するときに必要であれば、既存のコードやテーブルスキーマに何度も手を入れます。 これらの作業はプロダクトバックログアイテムを実現するHowにすぎないので、テーブルスキーマの作成のような作業がプロダクトバックログアイテムになることはありません（つまり単体でテーブルスキーマを作ることに対して、ストーリーポイントで見積もることはありません）。

アジャイルでのデータベース設計については、そーだいさんの記事がお勧めです。

ということで質問に対する回答は？

そろそろ回答はおわかりかと思いますが、どの粒度で分割すべきかは状況次第です。 作ろうとしているプロダクトの内容だけでは、プロダクトバックログアイテムをどこまで分割すべきかは決まりません。 スクラムの基本は透明性、検査、適応なので、プロダクトバックログアイテムをどう扱い、改善していくとよいかをスクラムチームで話し合って、より良い分割方法、より良い粒度を見つけてください。