プロダクトバックログが「墓場」化する理由：階層構造の欠如がもたらす優先順位の崩壊
Product Backlog Problems: Why Your Hierarchy Is Broken
プロダクトバックログがフラットなリストになると、戦略的な意思決定と些細なタスクが同列に扱われ、優先順位付けが機能不全に陥ります。本記事では、Klaus Leopoldの「フライトレベル」モデルを参考に、戦略・調整・運用の3つの高度を分離し、イニシアチブ層を導入することで、バックログを戦略ツールとして機能させる方法を解説します。また、Jiraなどのデリバリーツールが問題を悪化させる理由と、プロダクトバックログとデリバリーバックログの分離という解決策も提示します。
バックログは「検索バー付きの墓場」と化していた。
HNでの議論
22- squidlib
これは広告なので、中身は薄いだろうが、例示されたユースケースが、あまり現実的・実用的でないと強く感じた。
まず最初に、この手法はチームがすでに散らかって完全にメンテナンスされていないバックログを持っていることを前提としている。たとえメンテナンスされていないバックログでも、Jiraや他のツールには、バックログを視覚的にクリアに保つのに役立つ優れた組み込みツールがすでにある（優先度インジケーター、エピックタグ、特定のレベルの作業用にプレースホルダースプリントを作成する機能など）。
スプリントプランニングの議論は、チーム（エンジニアリング、QA、ステークホルダーなど）全員が毎回のスプリントプランニングセッションで作業の優先順位決定に発言権を持つことを示唆している。これらの会議でPMはどこにいるのか？PM/POはスプリントプランニングに「何を」を持ち込む。このサイクルが繰り返し起こっているなら、プロダクトチームのメンバーは弱く、あまりにも大目に見られている。チームはおそらく方向性の欠如に不満を感じているだろう。
フライトレベルアプローチの核となる前提に入ると、3つのフライトレベルは、依然として大きくなり得るバックログに分解されるだけで、このツールが解決しようとしたのと同じ問題が生じる。また、3つのフライトレベルは、チームが近い将来対後で実際に何を提供するのかをステークホルダーに明確に示すものではない。なぜなら、このモデルでは、デリバリーチームが行うすべてのことがバックログにまとめられているだけだからだ。しかし、すべてが悪いわけではない。アイテムの優先順位と価値はより明確になるだろう。スプリントプランニングセッションはよりスムーズに進むはずだ。最後に、3つのフライトレベルを見ると、[…]を思い浮かべるだけだ。
- bluGill
私は、バックログに入れるものを慎重に選ぶようにしている。現実的にやらないのであれば、バックログに入れるべきではない。やりたいことはたくさんあるが、現実的に価値がないと分かっているので、バックログには入れていない。毎月のトークン使用量を使い切っていないAIを使っても、やる価値のないことはまだたくさんある。
ちょうど今週、ビルドを改善するアイデアについて考えていた。そのリファクタリングをやろう、と。しかし、それを完了させるために必要な作業量を調べ始めると、確かにビルドの改善にはなるが、作業を完了させるコストが改善の価値よりも大きいことに気づき、実行しないことにした。直す価値がないために我慢しなければならない不便がいくつもあるのは残念だ。しかし、それが現実だ。最終的に顧客を満足させ、彼らが戻ってきてより多くのお金を払ってくれるようなことをする必要がある。
- natbennett
やらないことを削除するだけだ。