プロダクトバックログには何を書くべきか？

はじめに

通常、スクラム開発ではプロダクトマネージャー（スクラム的にはプロダクトオーナー）がプロダクトバックログアイテム（以下バックログ）を作成して、開発チームに実装を依頼します。
バックログは、開発プロセスの中で何度も読み直され、議論される重要な要素ですが、何を書くべきかはあまりはっきりと決まっておらず、開発組織によって千差万別です。
そこで、今回は10年以上スクラム開発を実践してきた中でたどり着いた、最適なバックログの構成についてご説明しようと思います。

この記事は以下のような悩みを抱えている方に読んでいただけると幸いです

・現在のバックログがイマイチ使いづらくて問題意識を持っている方
・バックログのメンテナンスに時間がかかって疲弊している方
・開発依頼をするときに開発チームに何を伝えたらいいかわからず悩んでいる方

バックログの構成

結論を先に申し上げると、現在私がスクラム開発するときにバックログに記載する項目は以下の5項目です。

# タイトル
<ユーザー>として<達成したいゴール>したい

## ユーザーストーリー
<ユーザー>として<達成したいゴール>したい。なぜなら<得られる利益>だからだ

## デザイン
* [画面 A](figmaのリンク)
* 画面 B
    * [状態1](figmaのリンク)
    * [状態2](figmaのリンク)

## 受け入れ基準
* 要件（機能要件・非機能要件）
    * 対象画面
        * 対象要素
            * 仕様
* （備考）

## メタ情報
* ストーリーポイント
* ステータス
* バックログ種別
* 優先順位
* エピック
* OKR

タイトル

バックログをカンバン形式で管理するときに表示されるタイトルですが、私はここに、バックログを通じて達成したいアウトカム、プロダクトゴールを記述します。
「OO機能の開発」や「XX画面の実装」といった、アウトプットに基づいた記述は禁止にしています。
それは開発チームのみなさんにも顧客に提供するアウトカムをしっかりと理解したうえで実装してほしいからです。また、優先順位をつけるときに、アウトプットが記載されていると、直感的に並び替えができないことも理由の一つです。

プロダクトゴールの記述はテンプレートを決めています。

<ユーザー>として<達成したいゴール>したい

プロダクトゴールをテンプレート化することで視認コストが下がり、バックログごとの比較が容易にできるようになるためです。

タイトルに記述するプロダクトゴールは次の項目で説明する「ユーザーストーリー」から<理由>を取り除いたものです。
<理由>をつけてしまうと、タイトルが長くなりすぎ、一覧性が低下してしまいます。また、見たい場合は、詳細を開いて見てもらえば十分と考え、<得られる利益>は省略しています。

ユーザーストーリー

ユーザーストーリーはバックログのビジネス価値を端的に表現したものです。
上述のタイトルに<得られる利益>を追加した次の形で記述されます

<ユーザー>として<ユーザーが達成したいゴール>したい。なぜなら<ユーザーが得られる利益>だからだ。

ユーザーストーリーは「なぜやるのか」、「何をしたいのか」をビジネス観点から端的にまとめたものです。そのため、<ユーザーが得られる利益>はしっかりと深堀って考えましょう

【しっかり深堀れていない例】
<一般ユーザー>として<ホーム画面を高速化したい>。なぜなら<ユーザーは素早くサービスをつかいたい>だからだ。
🤔 それっぽく見えるけど、本当かな一般論の可能性がありそう

【しっかり深堀れている例】
<一般ユーザー>として<ホーム画面を高速化したい>。なぜなら<ホーム画面をX%高速化すると滞在時間がX%向上するから>だからだ。
😀 顧客とビジネスへの利益が具体的に書かれている

背景や前提知識が必要な場合は、ユーザーストーリーの欄に記載します。
ユーザーストーリーは価値提案の結論ですが、その過程や背景を説明しないと理解が難しいケースがしばしばあります。
ユーザーストーリーはこのバックログに関するコンテクストを全く知らない人であっても、その重要性と何をしたいかを理解できるようにすることが目的です。

価値の高いユーザーストーリーを発見するためのプロセスとTIPSについては以下の記事にまとめてあります。
ご興味ある方はぜひ呼んでみてください。

どのようにして質の高いユーザーストーリーを作成するか

デザイン

デザインには、修正対象となる画面のfigmaのリンクをすべて記載します。<バリデーションエラー発生時>など状態を保つ場合はそれらもすべて列挙します

【例】

ユーザー一覧画面

ユーザー編集画面
* 初期状態
* バリデーションエラー時

figmaから新デザインの画面をエクスポートし、メモを加えてバックログにアップロードしたりする運用法を見かけたりもしますが、私はfigmaのリンクに統一しています。

バックログの作成からリリースまでのライフサイクル中にデザインが更新されることはしばしばあり、そのときにバックログを更新するのを忘れてしまい、古い情報のまま残ってしまうことがあるからです。
逆に、デザイン変更時のバックログ修正を徹底すると修正工数がそれなりに掛かってしまいます。
そこで、デザインのSSoT(信頼できる唯一の情報源)をfigmaに決めてしまったほうが効率的に運用ができると考えています。

受け入れ基準

受け入れ基準には、**「このバックログをリリースしてよい」と判斷できる基準を書きます。**基本的には私はここに具体的な仕様を記載します。

受け入れ基準に何を書くべきかについては、以下の記事で紹介しているので、もしご興味があれば呼んでみていただけると嬉しいです。

開発チームが喜ぶ「受け入れ基準」の書き方

メタデータ

メタデータはバックログの管理を容易にするための項目であり、バックログの本文自体に書き込むものではありません。バックログ管理ツールはプロパティやカスタムフィールドを用意してくれていることが一般的ですので、それらを設定して使用します。
設定するのは次の6項目です。

ストーリーポイント
ストーリーポイントはバックログの規模を表現する指標です。バックログの内容を開発チームに伝達し、開発チームがプランニングポーカーを実施することで見積もられます。整数値を入力します。

ステータス
バックログがライフサイクルのどこにいるのかを管理するものです。以下の項目を選択肢として持ちます。

INBOX : とりあえず思いつたものを登録する場所。プロダクトマネージャーに限らず誰でも、どのような粒度でも、フォーマットもあまり気にせず起票できます。“INBOX”はすぐにバックログで溢れかえります。私がおすすめしている整頓方法は、「一定期間経ったバックログを無制限に削除する」 というものです。本当に重要でしたら、必ずもう一度起票されます。そうでないのであれば、無視して問題ないという割と荒っぽいルールですが、とても有用です。
グルーミング中 : グルーミングとはバックログのストーリーポイントを見積もれる程度まで細分化、具体化するプロセスのことです。プロダクトマネージャーは”inbox”にあるバックログから重要で優先度の高いバックログを選び、グルーミングを実施します。その間、そのバックログはこのレーンに置かれます。開発チームのリファインメントとストーリーポイントの見積もりが完了すると次の”開発中”レーンに移します。
リリース待ち : 開発準備が整っているもの、開発中のもの、リリースを待っているものがこのレーンに置かれます。開発管理の都合上、これらを分離してステータス管理したくなる場合もありますが、多くの場合、開発チームがスクラム開発で使用するプロジェクト管理ツール(Github Projectなど)は別で用意してあるので、バックログ管理側では持つ必要性がない場合が多いです。
完了 : リリースが完了したもの、開発を取りやめたものなど、役割を終えたバックログを置くレーンです。

バックログ種別
バックログは大きく5つの種別に分けることができます。

フィーチャー : 新しい機能を追加するときに使います。
変更 : 顧客からの改善要望など既存の機能を修正するときに使います。
不具合対応 : 意図しない挙動や仕様と異なる挙動を修正するときに使います。
技術的な改善 : ミドルウェアのアップグレード、技術的負債の解決など仕様に影響を与えない技術的な改善活動に使います。
知識の獲得 : 他のバックログのための調査活動やプロトタイピングなどなにか意思決定をするにあたって必要な情報や知識を学習する必要があるときに行うときに使います。

完了したバックログの種別で集計して振り返りに活用したり、バックログの種別によって、バックログの記述形式を少しずつ調整してコミュニケーションを効率的にしたりと活用します。

優先順位
各バックログの優先順位です。高・中・低といったラベルではなく”ステータス”ごとのバックログの並び順で優先順位を整理します。上が優先度が高く下が低いです。プロダクトマネージャーが主にメンテナンスするのは”グルーミング中”の優先順位です。 バックログの価値やチームの状況を適切に反映して定期的に整理してください。“リリース待ち”レーンについてはスプリントプランニングにて決定されます。“INBOX”レーンと”完了”レーンについては優先順位の整理は不要です。

エピック
バックログがエピックの一部である場合、そのエピックバックログを紐づけます。これは当該バックログをなぜ実装する必要があるのか、目標を見失わないようにする目的と、エピックバックログでフィルタリングしたときに、ヌケモレがないか管理するときに便利なので入れてあります。

OKR
バックログをリリースすることで達成しようとしているOKR（Objective and Key Results）を選択します。目標管理としてOKRを使っていない場合は、短期的なプロダクトの目標と読み替えてください。
バックログ単体では提供価値を説明できるが、会社や部門レベルの目標と紐づいていなかったり、説明が難しかったりするバックログの開発が優先される現場をしばしば見かけます。そういった動きに自覚的になるために、すべてのバックログがどの目標（O）や主要な結果（KR）に影響を与えようとしているのかを明らかにします。どのOKRにも紐づかないバックログも当然あります（不具合対応など）。その場合は”OKRなし”を選択しましょう。“OKRなし”のバックログ開発が続く場合は黄色信号です。OKRプロセスやバックログの優先順位選定プロセスを見直す必要があるかもしれません。

おわりに

いかがでしたでしょうか。以上でバックログに何を書けばいいのか詳しく説明させていただきました。
より詳しいことを知りたい方はスクラム開発の書籍を参照されてみてください。
私のおすすめは、「エッセンシャルスクラム」です。

https://www.shoeisha.co.jp/book/detail/9784798130507

もう一本記事を読んでいただけると嬉しいです

このサイトではプロダクトマネジメント、組織マネジメントに役立つ情報を毎週発信しています。
この記事が面白かった、ためになったと思う方は、以下のリンクからもう一本記事を読んでいただけると大変嬉しいです！！

【本記事と関連する記事】

どのようにして質の高いユーザーストーリーを作成するか

開発チームが喜ぶ「受け入れ基準」の書き方

【私の記事一覧】

記事一覧

では、また！