初期のプロダクトバックログの作り方

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

別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。

まずはプロダクトゴールを検討する

プロダクトバックログは、プロダクトゴールの実現のために存在します。つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。

リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価します
プロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り返し、ダメなアイデアを早めに捨てる必要があります
ある程度いけそうなアイデアが出てきたら先に進みます

スプリント開始の条件

スクラムでスプリントを開始できるのは、プロダクトバックログが存在する場合のみであるため、スプリントの開始前にスプリントを開始できるだけの量のプロダクトバックログアイテムを含んだプロダクトバックログを作る必要があります。

プロダクトバックログアイテムは最初から多数なくても大丈夫です。最低限第1スプリントを開始するのに十分な量を用意します
- そもそもプロダクトバックログアイテムをすべて開発することはありませんし、初期のものは精度も低いです。したがって、大量に作っても多くの場合にゴミになります
- つまり、完璧なプロダクトバックログなど存在しません（そういうのを期待する人もいますが）。存在するのは変わり続けるプロダクトバックログだけです
作り方はさまざまな方法がありますが、ユーザーストーリーマッピングやペーパープロトタイピングなど、軽量なやり方を活用するのがお勧めです
- 個人的な感覚として、1チームであれば半日〜数日程度で作れるはずです
あとはやりながら追加していきます。スプリントレビューでフィードバックが得られるので、それを選別して追加したり、スクラムチーム内から出たアイデアを追加したりします
- スクラムガイドで明示されていませんが、プロダクトバックログの末尾であれば誰でもプロダクトバックログアイテムを追加できると考えるのが一般的です（一旦パーキングロットのような場所に置いてから判断することもあります）
- プロダクトバックログの並び順を最終決定するのはプロダクトオーナーの責任となります（作業自体は委任できます）。もちろん誰でも順番を提案して構いません

スプリントプランニングで扱うプロダクトバックログアイテムは、スプリントに入る大きさであり、スプリントで扱えるだけの具体性がなければいけません。

つまり第1スプリント開始前に、上位のプロダクトバックログアイテムは具体的かつ1スプリントで作れるサイズにしておかなければいけません。もし項目が大きい場合は事前にリファインメントを行い分割しておきます
- 分割の方法は別の記事で紹介しているのでそちらを参照してください
- もちろん第1スプリントでは、スクラムチームの力量が不明で、実際に1スプリントでどれだけ作れるのか確証が持てないこともあります。そのような場合は、第1スプリント開始前に1つだけ開発して試してみることもあります
1スプリントに投入するプロダクトバックログアイテムの個数は3〜10個程度であることが一般的です。大きなものを1つだけ投入してしまうと、スプリントがギャンブルになる可能性が高くなってしまいます。最大でも全員で着手してもスプリント期間の半分程度の期間でできるようなサイズにしておくのが望ましいと言えます
プロダクトバックログの中位、下位に行くのに従って、プロダクトバックログアイテムの粒度は大きくなっていくのが自然です。これについてはプロダクトオーナーが中心となって（もちろんスクラムチーム全体が協力します）、開発の進行にあわせて、プロダクトバックログをメンテナンスし、項目の並び順を変えたり、分割したりします。また開発者はプロダクトバックログアイテムの見積りを行います（規模を見積もれるのは開発者だけです）

プロダクトバックログの並び順

プロダクトバックログの並び順は、なるべく早く評価や価値のデリバリーができるようにするのが望ましいです。端的にいえばできるだけ最小の手数で上がりたいということになります。

仮説検証の比率が高いプロダクトほどこの原則を優先し、早期のスプリントレビューでプロダクトに対するフィードバックが得られるようにします
プロダクトに投資できる期間が短い場合も同様で、いかに早く一気通貫できるかを考えます
1回目のスプリントレビューで、ステークホルダーから意味あるフィードバックをもらうためには、どの順番にすると良いのかを考えるのがお薦めです。1回目なんて何もないのでステークホルダーをスプリントレビューに呼べない、と思っているのであればその考え方を改めましょう
- 第1スプリントで共通部品とかログイン機能を作っているチームは、それを最初のスプリントレビューでステークホルダーに見せる意味が本当にあるのか考えてください

プロダクトバックログアイテムの書き方

プロダクトバックログアイテムの書き方は、スクラムでは特に決まりはありませんが、受益者側の立場で書くのが分かりやすいです。受益者側の立場での書き方の例としてユーザーストーリーがあります。ユーザーストーリーは「＜人＞として＜機能＞ができる。それによって＜価値＞が得られる」というような書き方をするもので、スプリントレビューのときのデモシナリオにもなることもあります。

もちろんすべてのプロダクトバックログアイテムを必ず受益者側の立場で書かなければいけないわけではありません
- 「システムとしてログを出力できる。それは障害時の原因追求のためだ」のように書くのは無意味です
プロダクトバックログの短いラベルだけでは、開発するもの全てを表すことは不可能です。したがってプロダクトオーナーと開発者のあいだでの会話、補足のドキュメントやUIのラフスケッチ、受け入れ基準の明文化などの活動を通して共通理解を形成するようにします（この共通理解を形成する活動を常に行います）

それでは。