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

前提：どんな人に読んで欲しくてどんな行動をして欲しいか

プロダクトマネージャー勉強中の人が、この情報をもとにプロダクトバックログの作成を見直して欲しい

スクラム開発中に、次のスプリントでやる内容を決めたり、今後の見通しを決めたりするときにはプロダクトバックログが必要です。

プロダクトバックログとは、大きなロードマップの一部として完了・完成させるべきタスク、フィーチャー、アイテムを含む番号付きリストです。

https://asana.com/ja/resources/product-backlog

まずは、プロダクトバックログを作るにあたり、「どんなことを成し遂げたいのか」「ユーザーにどんな行動を起こして欲しいのか」をまとめるために、Epicを作成することが大事です。
そこで、Epic、User Story、Featureの基本的概念をまとめます。

Epic　User Story　Feature

1. Epic

英訳：叙述詩

プロダクトバックログを考えるときには「大きなストーリー」と考えておけばよいと思います。ここでは、提供側目線（自分）で成し遂げたいことを「〜したい」という言葉で書きあらわせばよいです。

2. User Story

ユーザーが価値を感じるストーリーが書ければよいです。ここでは機能名が文中に入っても問題ありません。ユーザー目線で書くことが大事です。
この内容は「ユーザーにどんな行動を起こして欲しいか」の内容ですので、開発者と共通認識にすることも大事となります。また、この価値を感じてもらえる内容がMVPとなっているかが肝心です。

3. Feature

英訳：特徴

機能名のことです。ユーザーストーリーを実現するために必要な機能名を書きます。

backlog.co.jp

私が実践しているbacklogでの管理方法

backlogでは、２階層でしか管理ができません。（親チケットと小チケット、孫チケットはありません）

そこで、Feature(機能)を親チケットとし、その子チケットにタスクやバグを分解して作成しています。

タスクには下記のようなタイトルをつけて、管理しています。

• ライブラリ

• UIデザイン

• UI設計

• AA (Adobe Analytics)

こうすることにより、検索にも引っ掛けやすく、機能チケットを親としているので、スクラムでの価値検討もしやすくなるというメリットがあります。

まとめ

是非上記考え方を取り入れて、プロダクトバックログを作成してみてください！
では、おつかめ！