DZoneだから、そのうち日本語翻訳されると思うけど。
dzone.com
「（忘れないように）とりあえずバックログに積んどこう」ってついやってるかも。
が、それを Expensive Folly と言っている、です。
プロダクトオーナーの中には、プロダクトの目標を達成し、同時に完全な透明性を確保するには、包括的なプロダクトバックログが最善の方法であると信じている人もいます。貴重なアイデアを決して逃してはなりません。ただし、包括的なバックログは、すぐに予期しない副作用を伴う過大なプロダクトバックログになる可能性があります。
サイズが大きすぎるプロダクトバックログがイノベーションに与える悪影響、スクラム チームの価値創造能力、ステークホルダーとの関係について詳しく学びましょう。
という記事になります。
若干省略してまとめます。以下、ググる翻訳ベースで抜粋しながら引用。
■大量のプロダクトバックログによるコストのかかる副作用
- 無駄を助長する: 過大なプロダクトバックログは、より価値のあるタスクが継続的に発見されるため、決して開発されない可能性のある項目に時間を投資することで無駄を助長します。
- サンクコストの誤謬リスク: 大量のプロダクトバックログはサンクコストの誤謬につながる可能性があります。チームは、重要な価値を追加するためではなく、すでに時間を費やしているため、アイテムの改良と優先順位付けを続ける可能性があります。
- 分析麻痺につながる: チームは項目の評価、優先順位付け、再優先順位付けに過度の時間を費やす可能性があり、実際の製品開発に集中する能力が損なわれます。最終的に、これによりプロジェクト全体の速度が低下し、顧客のための価値の創造からバックログ自体の管理にエネルギーがそらされます。
- 利害関係者の関与に損害を与える: 項目が膨大なため、関係者は計画、進捗状況、優先順位を把握することが難しくなり、期待のずれが生じる可能性があります。利害関係者は、膨大なリストの中から自分の特定の利益を見つけるのに苦労する可能性があり、利害関係者を混乱させ、孤立感を引き起こす可能性があります。
- クラウディングアウト効果: 包括的で過大なプロダクトバックログにより、利害関係者やチームメンバーがアイデアや洞察を提供するのを意図せず妨げてしまう可能性があります。
- イノベーションの阻害: チームは新しいアイデアを取り入れる余地がないと感じ、束縛されていると感じ、創造的な問題解決スキルが制限され、革新的な解決策を見つけることができなくなる可能性があります。
- 誤った安心感: 徹底的なプロダクトバックログは、誤った安心感、つまりコントロールされているという錯覚をもたらす可能性があります。スクラム チームが必要な作業をすべて特定し、発見と学習の必要性が認識されなくなったように見えるかもしれません。
- 早期の最適化を促進する: プロダクトバックログが膨らむと、チームが将来のバックログ項目の完了を予測したシステムやワークフローを設計する必要があると感じて、時期尚早な最適化につながる可能性があり、その結果、不必要な複雑さが生じ、これらのタスクが後で変更されたり優先順位が低くなったりした場合に無駄が発生する可能性があります。 このアプローチは、最も価値のある現在のニーズではなく、不確実な将来のニーズに向けた努力を奨励するため、アジャイルのシンプルさの原則 (未完了の作業量を最大化する技術) やスクラムの焦点の価値と矛盾します。
こちらは、アジャイルとはなんぞや的な内容なので、タイトルだけでさらっと流しときます。本文ご参照のこと。
■大量のプロダクトバックログの影響に最も効果的に対抗する方法
- シンプルさを受け入れる
- WIP (進行中の作業) を制限する
- バックログを定期的に改善する
- ジャストインタイムの改良
- 優先順位付けと優先順位を下げる
- チームに力を与える
- オープンな対話を促進する
- 継続的な学習と適応
バックログが「残作業」になってしまうこともあり、「捨てる」という判断がしづらいこともあると思います。そのへんを周囲とうまく調整するのがプロダクトオーナーの仕事のむずかしさのひとつなのだと思います。
