プロダクトバックログは手つかずのまま残って山積みになりメンテナンスできなくなる可能性がある。一般的な対処方法は定期的にレビューを行い、対応しないアイテムは捨てるようにすることだ。しかし、Neil Killick氏はこのようなやり方で要求を管理する場合の効率性について疑問を呈している。
氏によれば、この方法は、
- イノベーションを阻害する
- 製品全体のビジョンが損なわれる
- “要求のブラックホール”が生まれる
- メンテナンスのオーバーヘッド(コストや非効率性)が発生する
- 機能をリリースするまでに時間がかかるようになる
- プロダクトオーナーが依存性を理解し難くなる
- 優先順位付けに対するプロダクトオーナーの役割が軽くなる
氏はこの方法がどのようにイノベーションを阻害するのか次のように詳述する。
この方法の問題は、事前に定義された仕様書から製品を作る場合の問題と同じです。製品の進化の中でのイノベーションが起こり難くなるのです。バックログに記載されているということは、誰かがその事項をバックログに乗せるべきと考えて記載したということです。したがって、チームのプロダクトオーナーをそのバックログを吸収するために“as is”の開発をしようとする傾向が強まり、計画そのものを見直そうとしなくなります。
多くの会社がイテレーションを繰り返し、その中で実装する“ストーリー”を準備します。そして、イノベーションを起こすことは置き去りになるのです。
Todd Charron氏はバックログがメンテナンスできなくなり、洗練されたアジャイルプロダクト管理ツールを探す場合のよくあるアンチパターンを示している。氏は次の事実を強調する。
必要なのはより優れたバックログ管理ツールではない。バックログを小さくすることだ
Roman Pichler氏はプロダクトバックログの動的な側面について話し、バックログを硬直したものとは捉えずに、学習ツールとして利用することを勧めている。
初期のバックログは顧客やユーザからのフィードバックによって検証され、洗練されるべき「仮定」として扱うべきです。
また、士はプロダクトバックログを手入れする方法も紹介している。ひとつの方法はプロダクトカンバスだ。読者も同じ問題を抱えていないだろうか。どのような方法で対処しているだろうか。