昔から常にバックログは批判にさらされ続けている。Mary Poppendieck氏は、要求される目的を満たさないならば製品バックログは廃止するべきだと主張する。同様に、Jeff Patton氏もフラットなバックログはシステムの高いレベルのビューを伝えるのに失敗していると述べた。彼は、代わりにストーリーマップを使うべきだという。さらに、Serge Beaumont氏はバックログを分割するという面白い方法を提案し、バックログに意味を持たせた。それはフローにマッピングすることにより、バックログの存在価値を上げるものである。
Serge氏によれば、準備完了へのフローでプロダクトオーナは新しい(NEW)ストーリーを選び、準備完了(READY)状態にする、という。準備完了になって初めて、チームはストーリーに取り組み、完了(DONE)状態への処理を開始することができるようになる。
Serge氏はバックログを以下の4つの区分に分割することにより、フローを一貫したものに保つことができるという。
- 現在スプリント工程にあるもの、
- 準備完了(Ready)のもの、
- 準備完了に向けて準備中のもの、そして
- その他、つまり新規(New)のもの。
"新規(New)" と "準備完了(Ready)" は優先バッファにあり、"準備中"と"スプリント工程" は 進行中のものである。
- 優先バッファ: New - プロダクトオーナはまだこれらのバックログに取り掛かっていない。ここは、優先順位をつけ、わずかな価値しか与えないであろうバックログを取り除くのに絶好の場所である。このリストはビジネスの経験、利益の評価、ビジネスの緊急度などを基に優先順位付けされるべきである。
- 進行中: 準備中 - これがコアとなるリストであり、プロダクトオーナはここのバックログを準備完了(READY)状態にするために多くの時間を費やす。Serge氏によれば、ここでプロダクトオーナは自身のキャパシティに応じて多くのバックログを処理しなければならない。この区分のバックログのリストがどの程度のサイズになるかは、プロダクトオーナのベロシティにもよるだろう。プロダクトオーナは、バックログを精錬し準備完了(READY)状態にするために、それぞれのバックログに対して質問をしたり回答を求めたりしなければならない。
- 優先バッファ: 準備完了 - 準備完了(READY)バッファは、1.5 – 2イテレーション程度で終えられるバックログの、優先順位づけされたリストとなるべきである。そうすればチームは作業が早く完了した場合、イテレーション以外に新たに別のバックログに取り掛かることができる。準備完了バッファに2イテレーション以上のボリュームがあるバックログを置いておくのは無駄の原因となる、とSerge氏は言う。
- 進行中: スプリント工程 - これは現在のスプリントで実装されているバックログをさす。
このようにバックログを4つの区分に分割することにより、新規(NEW)から準備完了(READY)、完了(DONE)へとバックログの状態を遷移させるフローにぴったり添うようになる。この方法は、いずれの区分であれ、つみあがった在庫を減らす手助けになる。そしてそれぞれの区分でチームとプロダクトオーナの容量に応じてバックログを引き出すことができるようになるだろう。