スクラム開発に関して勉強していると「プロダクトバックログ」という言葉を耳にすることが多いと思います。
私のチームのプロダクトバックログって、
もう少し良い物にできると思うんだけど、何が足りないのかな？
とも坊「もっと良いプロダクトバックログを」は永遠のテーマだよね。
プロダクトバックログの基本ルールや失敗例、ノウハウを解説するよ！
・「プロダクトバックログ」とは何か理解できる
・プロダクトバックログの作り方や記載するべき観点を理解できる
・失敗例やノウハウを知ることができ、より効果的なプロダクトバックログが作成できるようになる
プロダクトバックログの他にはどんな作成物があるか知りたい方は、以下の記事をご確認ください。
プロダクトバックログ（PBL）とは？
プロダクトバックログとは、プロダクトの開発・改善に必要なタスクが優先順位が高い順に並べられた一覧です。
また、プロダクトバックログは、スクラムチームが行う作業が記載された唯一の情報源です。
プロダクトバックログは、スクラムチームやステータクホルダーがプロダクトバックログを共有することで、作業の優先順位や価値を知ることができ、共通のプロダクトゴールを目指すことができるようになります。
また、プロダクトバックログに登録されているタスクをプロダクトバックログアイテム（PBI）と呼びます。
管理者は誰か？
プロダクトバックログの管理者はプロダクトオーナーです。
ステークホルダーやスクラムチームの要求を取捨選択し、プロダクトバックログアイテムとして登録します。
プロダクトバックログの管理業務は他の人に委託することもできますが、プロダクトバックログアイテムの内容や受け入れ基準、作業の優先順位付けなど、プロダクトバックログにおける最終的な責任を負うのはプロダクトオーナーです。
いつ作成するのか？
プロダクトバックログは、スプリントプランニングまでに次のスプリントで必要な分が作成できていればOKです。
事前準備の段階では、大きな粒度でプロダクトバックログアイテムを登録しておき、スプリント0のタイミングでスプリント1で実施するプロダクトバックログアイテムの分割や詳細化を実施します。
基本的に直近の2、3スプリント分のプロダクトバックログが実行可能な状態になっているように準備しましょう！
プロダクトバックログの分割や詳細化はこの記事の後半で解説します。
とも坊スプリント開始前の準備期間を「スプリント０」と呼ぶよ
プロダクトバックログ作成前の事前準備
プロダクトバックログは、これから開発するプロダクトのゴールや作業の価値や優先順位が示されたものあり、以下の式で表すことができます。
プロダクトバックログ = プロダクトゴール + プロダクトバックログアイテム
また、スクラムチームとステークホルダーでプロダクトに対する共通認識を持つことも大切です。
プロダクトバックログの作成へ向けて、プロダクトゴールとプロダクトバックログアイテムとして登録する内容を事前準備に検討しましょう！
プロダクトゴールを決める
プロダクトを開発するにあたり「プロダクトゴール」が必要です。
プロダクトゴールを明確にすることでプロダクトの方向性を共有することができ、プロジェクトに関わるメンバーの行動の迷いや無駄な衝突を取り除き、チームの自己管理化やコラボレーションを促進します。
プロジェクトの目的やゴールを整理するプラクティスとして「インセプションデッキ」というものがあります。
・インセプションデッキ
インセプションデッキは、プロジェクトメンバーがプロジェクトの概要を把握し、目的やゴールに対する共通認識をもつためのドキュメントです。
テンプレートとして用意されている「10個の質問」に答える形で整理していきます。
インセプションデッキの作り方は、以下の記事で詳しく解説しています。
プロダクトバックログアイテムに登録する内容を整理する
プロダクトを開発するにあたり「どのような顧客（ペルソナ）に、どのようなサービス（価値）を提供するか」を検討する必要があります。
ユーザーに提供する価値を整理するプラクティスとして「ユーザーストーリーマップ」というものがあります。
・ユーザーストーリーマップ
ユーザーストーリーマップは、プロダクトを利用するユーザー目線で、プロダクトを通してどのような価値が提供されるかを時間軸と優先順位の観点でマッピングしたものです。
ユーザーストーリーマップの作り方は、以下の記事で詳しく解説しています。
プロダクトバックログの作り方
前提として、スクラムガイドではプロダクトバックログの作り方は定義されていません。
スクラムチームが自分たちで、自分のチームに合った管理方法を検討することが重要だと考えられているからです。
とはいえ、はじめてのスクラム開発ではある程度の型やフォーマットを知りたいと思うはず。
実際私がそうでした（笑）
ここでは、私の周りでよく利用されているものを紹介します。
スプリントを繰り返しながら、ご自身のチームに合わせてカスタマイズしていってください。
管理方法・ツールを選ぶ
プロダクトバックログの管理方法は以下があります。
・付箋を利用したアナログ管理
・ツールを利用したデジタル管理
おすすめはアナログ管理です。
理由：プロダクトバックログを中心にスクラムチームや関係者が集まる場ができるため。
プロダクトバックログを前に人が集まると必ず会話が生まれ、よりよいプロダクトを開発するための議論がはじまります。その結果、ユーザーに最も価値のあるプロダクト開発につながります。
近年はリモートワークが主流になりつつあるため、デジタル管理に役立つツールも紹介します。
プロダクトバックログを作成するツールとしてよく利用されるものは以下3つです。
・JIRA
アジャイル開発で最も使われているツールです。
プラグインなども豊富で、バーンダウンチャートやストーリーポイントの入力、AC、時間の予実管理など、アジャイル開発で必要な機能が備わっています。
markdownに対応していたり、Jenkinsやslack、ChatWork、スプレッドシート、gmailなどの外部サービスとの連携が豊富です。
本格的なアジャイル開発ツールとしてはJiraの方がおすすめですが、社内ツールとの連携を重視する場合はbacklogがおすすめです。
Trelloは、カンバンツールとしておすすめです。またボードのデザインもオシャレです。
タスク登録時に添付されている画像もカンバンボードに表示されるため、より視覚的にタスクの内容を判断することができます。
紹介した3つのツールは全て無料でお試しすることができます。
実際に触ってみてから使いやすいと感じたツールの有料プランを利用するようにしましょう。
どれもアジャイル開発に有効なツールですが、ツールを使うことが目的にならないように注意しましょう！
プロダクトバックログアイテムを作成する
ユーザーストーリーマップから初回の開発スコープ（MVP）が決定したと思います。
以下5つのステップでプロダクトバックログアイテムを完成させましょう！
プロダクトバックログアイテムを書き出す
ユーザーストーリーマップを元にプロダクトバックログアイテムを書き出します。
この時に書き出した内容がタスクにならないように注意しましょう。
・悪い例
- アカウント作成機能を実装する
- 認証機能を実装する
・良い例
- サイトに訪れた人がアカウントを作成することができる
- アカウント登録済みの人がログインすることができる
プロダクトバックログアイテムを並び替える（優先順位を決める）
プロダクトバックログは、優先順位が高いものから順に並べます。
書き出したプロダクトバックログアイテムを以下の観点で優先順位を決定し、並び替えて行きましょう！
【並び替えの観点】
・顧客への価値（ROI）が高いものか
・リリースするまでの時間が肝か
・リスクを最小化できるか
・発生するコストを抑えられるか
プロダクトバックログの優先順位を検討するモデルとして「狩野モデル」「MOSCOW」などがあります。また、プロダクトバックログアイテムの優先順位を決定をするのはプロダクトオーナーです。
開発内容を詳細化する
プロダクトバックログアイテムを見て開発者はプロダクト開発します。
そのため、プロダクトバックログアイテムを実施することで「誰がどのような価値を得られるのか」を明確にすることが大切です。
プロダクトオーナーと開発者の認識齟齬が起こらないように、以下の観点を記載するようにしましょう。
【プロダクトバックログアイテムに記載する観点】
・実施理由
このプロダクトバックログアイテムを実施することで、
誰が、どのようなことをできるようになり、その結果どのようになるか（価値があるか）
・アウトプットのイメージ
開発者全員が何を作れば良いか理解できる情報。
・参考資料や補足情報
事前にステークホルダーと合意している仕様
画面や表示文言のイメージ
外部システムのIF仕様書
ユーザーが想定している業務フロー
・特記事項
KPIやリスク
受け入れ基準を決める（AC：Acceptance Criteria）
何を持ってこのプロダクトバックログアイテムが達成されたかを判断するために、プロダクトオーナーが達成条件を設定します。ここに記載されたことをクリアすることでプロダクトバックログアイテムが完了となります。
ポイントを見積る
プロダクトバックログアイテムの内容と受け入れ条件が明確になったら、開発者がプロダクトバックログアイテムの見積りを実施します。
相対見積りで実施し、具体的な意味を持たない仮想単位「ポイント」を使って見積りを実施します。
ポイントの見積り方法として「プランニングポーカー」というものがあります。
以下の記事で詳しく解説しています。
プロダクトバックログが準備完了（Ready）の状態
「プロダクトバックログアイテムを登録する」で説明した5つの内容を満たしたプロダクトバックログは、スプリントで実行できる状態になっており、これをプロダクトバックログがReadyである（準備ができている状態）といいます。
【Readyな状態】
・プロダクトバックログ全体として優先順位が高い順に並べられている
・上位のプロダクトバックログアイテムは具体的かつ達成可能な情報が揃っている
・何を持ってこのプロダクトバックログアイテムが完成するかの基準が明確になっている
・見積りが完了している
ただし、はじめから全てのプロダクトバックログアイテムをReadyにする必要はありません。
全てのプロダクトバックログアイテムまでReadyの状態にすると変化が起こった時に多くのものがムダになります。また、メンテナンス性が悪化し、プロダクトバックログ全体の見通しがしにくい状態となります。
そのため、直近の2,3スプリントで対応する予定のアイテムがReadyであれば十分です。
開発初期のプロダクトバックログは上記の図のように、優先順位が高いアイテムほど詳細化されており、優先順位が低いアイテムは粗い状態となります。
プロダクトバックログアイテムをReadyにしておくことで、プロダクトオーナーやステークホルダーにとっては予測制度が向上します。
また、Readyの状態はスクラムチームごとに異なります。チームの成熟度によって、自分たちのチームではどこまで準備すればReadyの状態と言えるのかを検討しましょう！
スプリントバックログに関しては、以下の記事で解説しています。
プロダクトバックログのリファインメント
スクラムイベントの「リファインメント」を通して、プロダクトバックログのリファインメントを実施しましょう！
具体的には以下のようなことを実施します。
【リファイメントでやること】
・新たなプロダクトバックログアイテムの追加や見積り
・不要なプロダクトバックログアイテムの削除
・既存のプロダクトバックログアイテムの再見積り
・プロダクトバックログアイテムの優先順位の最新化
・直近のスプリントで対応予定のReadyな状態になっていないプロダクトバックログアイテムの詳細化
・大きすぎるプロダクトバックログアイテムの分割
また、プロダクトバックログをリファインメントをする際は、以下の「INVEST」を意識してみましょう。
・Independent（独立している）
・Negotiable（交渉可能）
・Valuable（価値がある）
・Estimable（見積り可能）
・Size right / Small（適正な大きさ）
・Testable（テスト可能）
スクラムイベントのリファインメントは、以下の記事で解説していますのでご確認ください。
プロダクトバックログアイテムの粒度
プロダクトバックログアイテムの粒度に悩む方も多いと思います。
例えReadyな状態になっていたとしても、プロダクトバックログアイテムが大きすぎると以下のようなことがおこります。
・スプリントで完了しない
・ベロシティが不安定
インクリメントの量が安定しないため、今後の見通しを立てにくくなってしまいます。
そのため、プロダクトバックログの粒度としては、1日、2日程度で終わるサイズ感を目安とし、大きすぎるアイテムは分割するようにしましょう。
プロダクトバックログアイテムの分割
では、大きすぎるプロダクトバックログアイテムをどのように分割すれば良いでしょうか？
以下の観点で分割を検討してみてください。
・ペルソナ（利用者）によって分割
・業務フローのステップごとに分割
・must要件とwant要件で分割
・”など”、”かつ”、”または”という言葉が出てきたら分割
・機能とユーザービリティで分割（動くPBIと綺麗にするPBIで分ける）
・CRUD（Create, Read, Update, Delete）で分割
・OSやクライアントの端末などプラットフォームごとに分割
・受け入れ基準の条件で分割
・spike（技術検証）と機能実装で分割
・テストシナリオやケース観点で分割
失敗例・アンチパターン
本記事で説明していることをすべて実践できている人はほとんどいないと思います。
より良いプロダクトバックログへ向けて、まずはご自身のチームのプロダクトバックログ以下のアンチパターンにいくつ当てはまっているか確認しましょう！
理想を追い続けるのではなく、良くないところを直していくスタイルです（笑）
【失敗例・アンチパターン】
・プロダクトバックログアイテムに優先順位がついていない
・プロダクトに対する優先順位ではなく、作業としての優先度で並んでいる
・フォーマットで記載しているだけで、実際には何の理由も説明されていない
・第三者が読んでわかる文章になっていない
・ワクワクしない、退屈なプロダクトバックログになっている
・ユーザーストーリーではなく、タスクが登録されている
・画面単位でプロダクトバックログアイテムが作成されている
・受け入れ条件が記載されていない
・プロダクトバックログが見える化されていない
・更新内容がチームメンバーに共有されていない
・定期的なリファイメントが実施されていない
・スプリントレビューのフィードバックが１つも登録されていない
・開発者からの要求やレトロでのアクションアイテムが1つも登録されていない
・プロダクトオーナーではなく、スクラムマスターがプロダクトバックログを管理している
・将来の準備や技術的な調査など、spikeが1つ登録されていない
・1つのプロダクトバックログアイテムがスプリント中に完了しない粒度になっている
・プロダクトバックログアイテムが細かすぎて価値が理解しにくい
・決まったフォーマットで作成されており、チーム内で議論が発生しない
より良いプロダクトバックログにするためのノウハウ
・まずはプロダクトゴールから考える（インセプションデッキ）
・みんなでプロダクトバックログアイテムの候補を検討する（ユーザーストーリーマップ）
・プロダクトバックログを前にたくさん会話する（共通理解、議論誘発のため）
・なるべく早く仮説を検証できるようにMVPを特定する
・自分のチームのニーズに合わせて、記載内容をカスタマイズする
・Just in Timeのプロダクトバックログ作りを心がける（はじめから全て作成しようとしない）
・小まめにプロダクトバックログを手入れする（我が子のように愛情を注ぐ）
「プロダクトバックログ」まとめ
[ポイント]
・プロダクトバックログは、プロダクトの作成・改善に必要なタスクが優先度順に一覧で並べられたもの。
・PBLを作成する前にプロダクトゴールや初回リリースで提供する価値（MVP）を整理しておく必要がある。
・PBIは「実施理由」「参考資料/補足情報」「受け入れ基準」を共有し、PO – 開発者で共通認識が持てるようにする。
・PBLは、直近のスプリントを開始できるだけのPBIの作成が出来ていればOK。
・直近のPBIが「分割&詳細化」「受け入れ基準の明確化」「優先度順に並んでいる」「見積りが完了している」状態がPBLが「Ready」の状態である。
参考資料
スクラム関連のおすすめ記事
スクラム開発をもう少し勉強したい！と思った方は、以下の記事がおすすめです。
実際に私が読んだ本の中で「絶対に損しない」初心者が読みやすい本をピックアップしてレビューしています。
教本選びのご参考になれば幸いです。
本を読んでいる暇がない！活字は少し苦手。。。という方は、動画教材がおすすめです。
通勤中や就寝前などに必要なセクションのみ選択して学習できるため学習効率が非常に高いです。
また、近年アジャイル人材の需要が高まっています。
アジャイル人材の需要や年収などを以下の記事にまとめていますので、学習のモチベーション維持にお役立てください。
コメント