スクラムにおいてプロダクトバックログは非常に重要です。プロダクトバックログが頻繁にメンテナンスされているか否か、プロダクトバックログが見える化されているか、プロダクトバックログを中心に、ステークホルダー、プロダクトオーナー、開発チームが十分にコミュニケーションを取れているかどうかで、うまく開発ができているかがわかります。ではプロダクトバックログを作るには何が必要でしょうか。
プロダクトビジョンを考え、プロダクトオーナーを決め（順番は逆でも良いです）プロダクトバックログを作ります。

プロダクトビジョン

　プロダクトのビジョン、すなわち、何を解決したいのか、それはなぜか。それをどうやって解決するのか、結果、何ができるのか。思考法としては、ゴールデンサークルです。
チームで、インセプションデッキを書いてみるのも良いです。
Runnnig Leanで紹介されている、リーンキャンバスを書いてみても明確なビジョンが浮かび上がってくると思います。最初の仮説としては十分な情報だと思います。大切なのは、最初から完璧なビジョンはないということ。ほぼ確実に当たる仮説はないので、走りながら考えて修正を加えていけば良いです。これを、チームの皆が見えるところに貼っておき、皆がいる場で更新できると尚良いと思いますし、難しければ、プロダクトバックログリファインメントの場で更新結果を共有すると良いと思います。
　また、このプロダクトのターゲット（顧客層）を明確にしておく必要があります。この仮説検証はとても大切です。プロダクトバックログアイテムの優先順位をつける前に、ペルソナやユーザの優先順位をつけれるようにしておくと良いです。

プロダクトオーナー

　スクラムではプロダクトオーナーという役割があります。プロダクトオーナーを決めないで走ると、プロダクトバックログの優先順位が決められません。誰に決定権があるのか曖昧になり、議論が長引き、結局何も生み出せないまま開発が進まなかったり、仮説検証を厳密に行えなくなったりします。プロダクトオーナーは必須だと考えます。プロダクトオーナーは、チームのROIの最大化に責任を持つために、良いプロダクトバックログアイテムを作ることに注力する必要があります。そして大切なのは、プロダクト１つにつきプロダクトオーナーは一人であること。忙しいからサブをつけるとかやると、チームはどちらを信じていいかわからなくなります。仮にサブをつけるならサブの人がプロダクトオーナーです。また、プロダクトオーナーが最初にするべきことは、プロダクトバックログを作ることではありません。まずは完了の定義を明確にすることです。完了の定義を明確にし、プロダクトのリリースがスプリント内で収まるのか、スプリントが終わってからどれくらいの作業ボリュームがあるかを把握する必要があります。

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

　プロダクトバックログの作り方は非常に悩むところです。プロダクトに必要な機能を１０〜２０枚、カードに書いてもらいます。その際、テンプレートはあるのですが、テンプレート・ゾンビにならないように気をつけて。
現場では、プロダクトバックログアイテム=ユーザーストーリーという言い方がされますが、ストーリーと書くと、物語しか書いてはいけない、と誤解を生むので私はあまりストーリーという言い方は好きではありません。あくまで”アイテム”のほうが良いと思います。”ストーリー”のテンプレートは、
○○として、✗✗したい、なぜなら△△だからだ
というものがありますが、数枚の”ストーリー”であればいいのですが、これを１０枚書くのは結構しんどいです。追加・更新があった場合にも廃れていきます。あまりテンプレートにこだわらず、✗✗したい、や、✗✗できる、と書くことに注力すると良いと思います。
注意するのは、タスクにならないこと。あくまでプロダクトバックログアイテムなので、例えば、ログイン機能を実装する、認識用データを収集する、解析するというのはタスクなので、このようなタスクを書きたくなったら、「それは何のためにやるんだっけ？」と問いなおすと良いと思います。一段抽象化されます。

プロダクトバックログの分割

　（どの層が優先ターゲットなのか明確にする）または”などの文言がでたらどちらか一方のみをアイテムとして分割する）
・チーム外の人が読んでもわかるような語句を利用する
・最初から細かくしすぎない。細かくするのは優先順位が最も高いプロダクトバックログアイテムからで良い。直近２−３スプリント分、チームが取れるぐらいの分割粒度・量で良い。
薄くスライスされた機能
・まず動かす、そして綺麗にする。（ユーザビリティと機能の分割）
・CRUD（Create, Read, Update, Delete)で分割
・データは既に存在している前提で分割。あとから登録。
・サードパーティーやOSSからコンポーネントを仕入れた想定
・OSやクライアント端末を限定する
・プロダクトバックログアイテムのアクセプタンスクライテリアの条件を絞る
・プロダクトバックログアイテムの接続詞に注意して分割（”且つ”、”または”などの文言がでたらどちらか一方のみをアイテムとして分割する）

プロダクトバックログの管理　

　プロダクトバックログはアナログ管理が一番良いと経験的に思います。理由は、プロダクトのリアルを”感じ取れます”し、プロダクトバックログを中心に”人”が集まれるからなんですね。人が集まると会話が生まれ、よりよいプロダクトにするための議論が始まる。そこで忘れていたものを思い出したり協力・協調・互助が生まれる。人と人が繋がっていく。それがプロダクトを良くする方向性と合致する。もちろん、拠点がわかれていて電子化したほうが効率が良いプロジェクトもあると思います。その際に気をつけることは、シンプルさ。Google SpreadSheetやExcelで管理すると、すぐに複雑になってしまいます。必要最低限の情報のみ記載し、メンテンナンスが簡単であれば良いと思います。JIRAなどのツールは、個人的にはあまりオススメしないです。”ツールに縛られる”と感じることが多いので。

ストーリーポイントとベロシティ

　プロダクトバックログアイテム毎にストーリーポイントという相対的な数値をつけ、アイテムの大きさや複雑さをざっくりと数値化します。これは開発チームが行います。１スプリントでどのくらいのストーリーポイントを開発チームが消化できたか、という数値を、ベロシティといいます。このベロシティというチームの速度を計測して、あとどれくらいで残りのバックログが消化でききるかを予測したりします。あまりイノベーティブなプロダクトでない場合はこの方法での速度計測がうまくいきます。イノベーティブなことをやっていると見積もり自体うまくいかないことが多いですからベロシティは狂いまくります。それだけチャレンジしてるということですし、それを見える化すると、プロダクトオーナーと開発チーム、ステークホルダーにも難しさがありありと感じ取れる、すなわちリアルですよね。全然間に合わねー、ってことがわかってもいいことですし、全然予測できねーなー、っていうのがわかってもいい。逆にベロシティが狂いまくるから見える化しても意味がないということはなくて、そこから見えるもの、感じ取れるものがあるはずです。見える化は、スクラムマスターが最初は主導し、徐々に開発チームに委譲していくと良いと思います。ベロシティというチームの速度を計測して、あとどれくらいで残りのバックログが消化でききるかを予測したりします。あまりイノベーティブなプロダクトでない場合はこの方法での速度計測がうまくいきます。イノベーティブなことをやっていると見積もり自体うまくいかないことが多いですからベロシティは狂いまくります。それだけチャレンジしてるということですし、それを見える化すると、プロダクトオーナーと開発チーム、ステークホルダーにも難しさがありありと感じ取れる、すなわちリアルですよね。全然間に合わねー、ってことがわかってもいいことですし、全然予測できねーなー、っていうのがわかってもいい。逆にベロシティが狂いまくるから見える化しても意味がないということはなくて、そこから感じ取れるものがあるはずです。見える化は、スクラムマスターが最初は主導し、徐々に開発チームに委譲していくと良いと思います。

アクセプタンス・クライテリア（受け入れ条件）

　プロダクトバックログアイテムには、アクセプタンスクライテリア（受け入れ条件）を記載する必要があります。本来、スプリントレビューにて各プロダクトバックログアイテムのアクセプタンスクライテリアが満たせているかを確認しますが、これができなくなり、なんとなくレビューしてなんとなくOK、なんとなくNGということになりかねません。検査と適応がしづらくなります。アクセプタンスクライテリアを記載し、そこから何がNGだったのか、次はどうするか、を学んでいくことが大切です。結構面倒なのでサボられがちですが、頑張りどころです。（偉大なスクラムマスターが厳密にルールを守るように言ってくれると思います）
　アクセプタンスクライテリアには、考えやすい観点があります。Given, When, Thenです。振る舞い駆動開発(BDD)のときのテストケースの書き方でもあります。
Given: 前提条件、環境、データなどを示します。
When: アクション、✗✗したとき、などを示します。
Then:Givenの条件で、Whenを実行したときの結果を記します。

ユーザーストーリーマッピング

　プロダクトバックログをただ一列に並べるのも良いですが、ユーザがプロダクトを使う流れでプロダクトバックログを表現する方法もあります。これがユーザーストーリーマッピングです。詳しくは左記のURLに記載があります。これはプロダクトバックログを作る手段のみならず、プロダクトの全体像を見るために、思考を整理するためにも良い方法だと思います。注意点は細かく作りすぎないこと。常に優先順位を気にかけてください。優先順位の高いもののみ、細かくします。リファインメントで徐々に増やしたり分割したりしていきましょう。

プロダクトバックログから必要なチームが構成されることもある

　まずはじめに開発チームがあるのではなく、「このプロダクトバックログを効率的に実現するにはどのようなチーム構成が良いだろう？」という切り口で考えることもあります（もちろんそうするべきという訳ではなくあくまで一案です）。ただし、プロダクトバックログアイテム毎にチーム編成が異なるのではありません。チームはあくまで一度組んだら少なくとも3ヶ月は同じメンバーで構成されるのが、チーミングの観点から望ましいです。最初に選んだアイテムから、チームが結成されて、そのチームが続いてくというイメージです。 

プロダクトバックログ・アンチパターン

これまでの経験から以下のようなアンチパターンがあると考えます。

・優先順位がついていない
・優先順位ではなく、優先度がついている。
・チーム外の人が読んでわかる文章になっていない
・タスクが記載されている
・アクセプタンスクライテリアがない
・見える化されていない
・更新が共有されていない（一方的な共有はNG）
・開発チーム内で優先順位をつける努力をしていない（最終的な優先順位決定はプロダクトオーナーの責任だが、チーム内でまず優先順位を決めるのはOK）
・リファインメントされていない
・振り返り（レトロスペクティブ）の結果のアクションが１つも入っていない
・スクラムマスターがプロダクトバックログを管理している