プロダクトバックログのテンプレートが欲しい
「プロダクトバックログなんて、そんな何個も作るものじゃないでしょ」
とか思っていたときもあったのですが、ここ数年、公私合わせて、年2、3個はプロダクトバックログ（PBL）を作り、その都度フォーマットを作っていたので、 いい加減（自分のためにも）PBLのフォーマットを決め、テンプレートを用意するようにしました。
これが「さいきょうのPBLだ！」
最強なのかはともかく、現時点で一番わかりやすく運用しやすいPBLのフォーマットは、以下のようになりました。
テンプレートにはGoogleスプレッドシートを利用しています。
なぜかというと、現状ではこれが一番全体の把握がしやすく、多くの人が特に追加費用無しでアクセス可能であり、独自カスタマイズを許容できるツールになるからです。
セルに記述するというのも、アイテムを追加する人の心理的障壁を下げていますし、途中を許容しつつ議論ができるのも利点だと思うので、
特に強いこだわりがないのであれば、現状はスプレッドシート一択で良いのではないでしょうか。
PBL項目
スプレッドシートの各項目は以下のような用途を想定しています。
| 項目 | 用途 |
|---|---|
| No | 通番。優先度で前後させても通番を振り直しはしない |
| エリア | 開発範囲を示すときに使う。LeSS Hugeのエリアに相当 |
| ステータス | プロダクトバックログアイテムの状態を表す（詳細は後述） |
| 誰が | 誰のための価値になるものを作るのかを明示する。ユーザストーリのWho |
| 何をしたい | どういったことを実現するのか。ユーザストーリのWhat |
| それはなぜか（価値） | どういう価値が提供されるのか（リリース後に検証する内容）を書く。ユーザストーリのWhy |
| ポイント | ストーリポイントを書く |
| レビューチェック内容 | このアイテムでどういったことを実現するのかを具体的に書く。スプリントレビューの受け入れ基準に相当（How） |
| 備考 | SKIPにした理由や、アイテム分割した際の情報などを書く |
PBLに携わる人数が多ければ、起票者の項目もあると便利です
スクラムでのPBL運用フロー
ではこのPBLをスクラムのイベントに沿って運用するフローを提示してみたいと思います。
1. プロダクトバックログリファインメントを実施
- 各自がプロダクトバックログにTODOでアイテムを追加する（事前記入だったり、時間を取ってやったりする）
- プロダクトバックログリファインメントを実施し、アイテムの上の方から内容を確認していく
- TODOを追加した人から内容の説明を受け、チーム内のゴール認識を合わせる（レビューチェック内容を決める）
- アイテムのストーリーポイントを見積もる
- アイテムの状況に合わせて、ステータスを変更する
- アイテムの粒度が大きすぎたり、不明瞭な場合は、実現可能な粒度にアイテムを分割して、再度内容を精査する
ステータスは以下のような意味合いで利用します。
| ステータス | 意味 |
|---|---|
| TODO | アイテムを起票した状態で、まだチームへの展開が行われていない |
| READY | 展開された内容が、現時点で着手可能 |
| NOT READY | 展開された内容が、まだ着手不可能 |
| DOING | スプリントで実施中 |
| DONE | アイテムが完了している |
| WAIT | 現状議論する段階にない（議論できない） |
| PENDING | どうするかを保留した |
| SKIP | 一旦実施しないこととした |
2. スプリントプランニングを実施
PBL上位のアイテムでステータスがREADYとなっているものからスプリントで実施するアイテムを決め、そのアイテムのステータスをDOINGにする。
選んだアイテムはスプリントバックログ（ホワイトボードを使うのがお奨め）に移動し、タスクを詳細化・細分化する。
3. スプリントレビューを実施
スプリントで作成した成果（プロダクトインクリメント）を、PBLのレビューチェック内容と照らし合わせながらレビューする。
実現できていればステータスはDONEにし、追加で実現したいことが見つかったならPBLに新しいアイテムをTODOで追加する。
4. 繰り返し
これらを繰り返していく。
まとめ
個人的には、価値を生み出す作業にどれだけ注力できるかが、アジャイル開発の目指すところかなと思っているので、それ以外の部分については可能な限り力をかけずに済ませるようにしたいです。
ちょっとでもPBLのフォーマットに迷うくらいであれば、とりあえずこのフォーマットに書き殴ってみて、後で適当なものに切り替えてみるとかはどうでしょうか。
