トップページ > コンテンツ > プログラミング効率化 > プログラムを作る上での考え方 > アジャイル開発の考え方 > プロダクトバックログ

バックログ概要

バックログにはビジネス価値や作業コスト等から優先順位をつけた要求事項の一覧を記載する。
要求にはユーザーストーリーの他、技術的負債の解消、バグ修正、知識獲得、リリース時の顧客からのフィードバック、振り返り時のフィードバック等がある。
なお、内容や優先順位の入れ替えがあり一貫性を保てないため、要求定義書にはならない。
受入条件やストーリーポイント(※1)等も表現する。

項番	要求	受入条件	ストーリーポイント	優先度
ストーリー1	xxxx	・XXXできること。	3	高
ストーリー2	yyyy	・yyyできること。	5	中
ストーリー3	…	…	…	…

(※1)
ストーリーポイントとは、そのストーリーを実現するのに必要な作業量や難易度を、開発チームがフィボナッチ数がかかれた数値で相対見積を行ったもの。見積はプランニングポーカーの形で実施する。

あるチームが1スプリント内で実施できたストーリーポイントの合計がベロシティとなる。ベロシティはよく生産性と混同されがちであるが、別物である。(あくまでどのくらいできるかの目安・尺度にすぎない。ベロシティの元となるストーリーポイントは絶対指標ではなく相対見積もりである。そのため、仮に生産性として扱おうと、知らず知らずの内に数値改ざん等に走ってしまう恐れがある。)

バックログアイテムの分割ポイント

INVESTを意識すると良い。

Independent	他のバックログアイテムに依存しないようにする
Negotiatable	交渉可能な状態となっている。作業タスクレベルに細分化するのではなく、実現方法はベストな方法を議論できる余地を残しておく。
Valuable	価値がわかるようにする。
Estimable	見積可能な状態にする。見積可能なレベルまで具体化することが重要
Size right / Small	1つのバックログは適切な大きさで細分化する。荒すぎると1スプリント内で1つも終わり切らず、どの程度の成果を発揮できたのかを図ることができない。また、見積を行うことが困難になる。逆に細かすぎるとバックログアイテムのビジネス価値がわからなくなる恐れがある。
Testable	テストが実施できるようにする。テストできるレベルまで必要条件を具体化することが重要

参考URL

プロダクトバックログの考え方については、 次のサイト にも目を通しておきたい。