プロダクトバックログをいい感じに書くためのガイドライン
アジャイルソフトウェア開発のフレームワークの1つである「スクラム」では、製品やサービスの要件をリスト化したものを、「プロダクトバックログ」と呼びます。
正確には違いますが、製品の開発に必要なタスクを並べた、タスクリストのようなイメージです。
アジャイル、スクラムの意味についてはこの場では詳しく述べません。
自分が所属しているチームでもスクラムを採用しており、毎週一回開催される「スプリント計画」にて、次のスプリントで取り組むプロダクトバックログについて話し合っています。
最近の弊チームが抱える課題の1つに、「プロダクトバックログに対する作業量の見積もりが甘く、1スプリント内で完了しない」ことがあります。
この課題を解決するために、まずは「プロダクトバックログの書き方の原則」を振り返り、よりよいプロダクトバックログの作り方について学ぶ必要があると感じたため、まとめてみました。
プロダクトバックログとはそもそも何か？
以下、プロダクトバックログはPBと表記します。
PBとは、プロダクトオーナーが、製品を完成させるために必要な機能を、「ユーザーストーリー」と呼ばれる文章で表現しそれをリスト化したものです。
また、PBは継続的に更新されることが期待されている、「生きたドキュメント」[1]です。
PBの各項目は、「プロダクトバックログアイテム」（以下、PBI）と呼ばれますが、上から順に優先度が高くなるのが定石です。
つまり、実装することにより生まれる価値が高い順番にPBIは並べられなければならない、ということです。
まとめると、PBはプロダクトオーナーが求める要件の一覧であり、PBIは優先度順に並び替えられている必要があります。
プロダクトバックログを書くときのガイドライン
PBの量が増えてきたら、放置せずに洗練させることが大事です。
洗練するために参考になるガイドラインとして、「INVEST」があります。
INVESTは、下記の頭文字をとったものです。
- Independent（独立している）
- Negotiatable（交渉可能）
- Valuable（価値がある）
- Estimable（見積もり可能）
- Size right / Small（適切な大きさ）
- Testable（テスト可能）
上記の原則を守れば、多くの課題を解決することができるので、都度PBを見直しましょう。
PBの内容を振り返る機会を定期的に設けるのもよさそうです。
魅力的なプロダクトバックログで開発を楽しく！ – KRAY Inc.
Readyなものだけに取り組もう
INVESTのほかに、PBを作る際に参考になる観点として、「Readyな状態」を目指すことが下記の記事で紹介されていました。
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話 | Ryuzee.com
個人的には、INVESTをより具体的に表した状態だと思っています。
簡単に「Readyな状態」を定義すると、
開発チームとして必要な情報が揃っている
開発チームとして受け入れ可能な品質
とされています。
個々のPBIについて「Readyな状態」とは、下記の様に説明されていました。
上位の項目については、具体的である（要望ではなく要求でないといけない）
上位の項目については、何をもって完成したのかを判断する基準が明確である。すなわち受け入れ基準やデモのシナリオ、求められる結果が明らかである（これがあればスプリント冒頭で受け入れテストを自動化できる）
上位の項目は開発チームが1スプリント内で完成できるサイズになっている（すなわち継続的に見積りの見直しを行って、過去のベロシティから1スプリントに入らないことが明確であれば、事前にプロダクトバックログ項目を分割しておく必要がある
個人的には、何を持って完成したのか判断する基準を明確化する部分が重要かつすぐに取り入れられそうだと思いました。
再掲ですが、「プロダクトバックログに対する作業量の見積もりが甘く、1スプリント内で完了しない」というのが自チームの課題でした。
個人的には、INVESTの中でもTestable（テスト可能）の項目が徹底できていないと感じています。
テスト可能というのは、「どのような状態になったらそのPBIが完了と言えるのか」つまり受け入れ基準と同義だと考えています。
受け入れ基準が曖昧なままスプリント計画を終わらせてしまい、結局どの範囲までやれば完了なのかが不明なため、スプリントの終盤になって適当に見切りを付けたり足が出たりしていまいます。
受け入れ基準を明確にするために必要なのは、プロダクトオーナーとの対話、チーム内での合意形成だと思います。
今は個人の判断で受け入れ基準が設けられていることが多いので、今後はスプリント計画で受け入れ基準までチーム内で議論するように心がけていきたいです。
まとめ
PBをよりよく作るための観点についてまとめました。
- INVESTであること
- Readyな状態であること
上記の条件を満たすPBの作成を目指すと、よさそうです。
なので、定期的にPBを見直して上記原則に則っているかを確認し、リファクタリングしていきましょう。
Discussion