"scrumnoob"氏は現在取り組んでいるスクラムプロジェクトに問題を抱えている。プロダクトオーナーがプロダクトバックログに優先度を付けたがらないのだ。"scrumnoob" はこう書いている。
プロダクトオーナーはプロダクト知識、ビジネス管理について卓越しており、スプリントの理想／デモ、ふりかえりに賛同しています。ところが、リリース計画のためのプロダクトバックログの調整と優先順位付けについては純粋に考え、それらに賛同していないようです。むしろ、これらマストなものすべてが期日までに必要であり、優先順位を付けても意味がないと考えているのです。
こうした状況において、"scrumnoob"氏は何をすべきだろうか？
"woynam"氏の提案は、プロダクトオーナーに顧客価値以外の要因でバックログを順位付けするよう頼むことで機能不全に対処することだ。
もしバックログにある「すべてのもの」を実現しなくてはならないなら（本当か疑わしいけれども）、バックログを優先順位付けするのにいろんな方法があります。技術的リスクに基づいて優先順位付けしてもよいでしょう。これは間違いなくビジネス価値に影響を及ぼします。実装が困難だったり、不確実性の高い機能はありますか？ 最初にこれらを実装することで、将来遅すぎる時期に予期せぬ事態が起こるリスクが減らせます。
バックログをテーマ別にまとめてもよいでしょう。単一の機能領域にあるストーリーはいっしょに実装すべきです。そうすれば、プロジェクトの初期にやめる必要があっても、機能セットにはまとまりがあります。
中間成果物はありますか？ 展示会にデモ版は必要ですか？ もしそうなら、デモできると意味があるのは何ですか？
Dave Rooney氏の提案は、ソフトウェアプロジェクトに自然と発生する品質と時間のプレッシャーを使って、プロダクトオーナーを説得することだ。
[...] あなたの組織にスクラムを導入する前、最終フェーズで大量のシステムテストを実施するようなプロセスを使っていましたか？ もしそうなら、リリースにさらに機能を詰め込むために、そのフェーズは「圧縮」されていましたか？ もしそうなら、品質はどうでしたか？ もっとよい質問があります。リリースを出荷可能にするために、どれくらいテストややり直しが必要でしたか？ こうした情報を使えば、最後に品質が失われる危機的時期よりも前に達成したい機能は何なのか、プロダクトオーナーに質問できるでしょう。
Peter Stevens氏のおすすめは、優先順位付けの問題をもっと大きなビジネス視点の範疇に入れることだ。
ご存知のように典型的なパターンがあります。ビジネス部門は優先順位を設定できないし、やりたがらないし、実際やりません。そのため開発部門のだれか（通常はセカンドラインマネージャ）がその割に合わない仕事をやることになります。価値を最適化するのは実際のところよいことではありませんが、これは優先順位付けがなされることを意味しています（そして、ビジネス部門は厄介な仕事を免れて、間違った優先順位付けをしたと開発部門を非難できるのです）。これはあなたの組織が望んでいることですか？ スクラムを使っても、この典型的なパターンを続けたいのですか？
Dave Rooney氏の考えは、開発チームがバックログを優先順位付けするが、プロダクトオーナーが自ら行動するの期待して、間違った優先順位付けをするというものだ。
どのアイテムを高い優先順位付けに*すべき*か、あなたには筋の通った考えがありますか？ もしあるのならプロダクトオーナーに言いましょう。最初に優先順位が最低のアイテムを選んで、「わかりました、これらを最初にやるつもりです」と。それから優先順位が最高のアイテムを選んで、「これらは最後の最後に残しておきます」と。こういう戦略もあります。バックログアイテムの順位付けを完全にランダムにするのです。
突如として、何が優先順位が高いのか、プロダクトオーナーにはもっとよい考えが浮かぶことでしょう。;)
しかし、David Koontz氏はこういう考え方にはあまり感心していない。
私は意図的に価値の低いアイテムに取り組むよう提案したくはありません。これは意地悪だし、人間関係やチームの成功にとって有効だとは思えません。チームには責任があります。たとえプロダクトオーナーがその役割を果たしていなくても、その代理として全員最善を尽くす責任があるのです。チームの多くの人はプロダクトオーナーと同じくらいストーリーの価値を理解しています。優先順位を付けて、できる限りのことをするべきです。
どんなソリューションが進められようとも、Charles Bradleyのおすすめは他のスクラムの障害と同様にスクラムマスターに問題に対処させることだ。
スクラムを導入したのはだれの判断ですか？ 以前使っていたのはどんなプロセスでしたか？もし次のスプリントでひとつもストーリーを実現できなければ、だれが怒るのですか？
プロダクトオーナーはだれに報告するのですか？
あなたはだれに報告するのですか？ あなたはスクラムマスターですか？
私が言いたいのは、この問題を障害として扱って、スクラムマスターが解決に取り組むべきだということです。おそらくほとんどの場合、障害はチームの外側にあります。
あなたの障害を解決する、あるいは後で突然中止になって少なくとも障害を「補う」には、それにふさわしい判断者を見つける必要があるように聞こえます。