新任スクラムマスターがプロダクトオーナーに聞くべき20の質問

1. プロダクトのビジョンとそのためのGTM戦略はありますか？

ビジョンや戦略に関する質問が出たときに、プロダクトオーナーは、チームで一番の頼りになる人物でなければなりません。

2. 新たなアイデアや要求については、どのように学んでいますか？

ここでは、プロダクトオーナーは、プロダクトの発見プロセス全体について説明できる必要があります。アイデアから仮説、実験、そして最終的な検証に至るまで説明できるでしょうか。

3. プロダクト発見プロセスにユーザー調査をどのように組み込んでいますか？

私は、学習する組織がユーザーテストを継続的に実施しないで運営できるとは思えません。したがって、プロダクトオーナーは、ユーザーテストのプロセス全体だけでなく、スクラムチームがどのようにプロダクトの発見に関わっているのかを説明できるべきです。

4. ユーザー調査と顧客ニーズの把握にどれくらいの時間を割いていますか？

経験則としては、50％の時間を割いていれば素晴らしいでしょう。10％未満の時間ならば、プロダクト発見プロセスに（たくさんの）改善の余地があります。プロダクトオーナーの作業負荷に関する質問でフォローアップしましょう。また、プロダクトオーナーが顧客と話しをする時間を増やすためにどのようなサポートができるかを説明しましょう。

5. スクラムチームはどの段階でプロダクト発見プロセスに関与しますか？

プロダクト発見プロセスの出来る限り早い段階で、スクラムチームが参加できることを強く推奨します。開発チームのメンバーがこのプロセスに参加するのが早ければ早いほど、技術的に実現不可能であったり、投資に対するリターンが得られない解決策であったりが押し進められる可能性が低くなります。

6. 利害関係者との連携をどのように整理していますか？

これはプロダクトオーナーにとっては簡単な質問でしょう。このコミュニケーションを時間をかけて確立し、改善するにはさまざまな方法があります。例えば、それぞれの利害関係者との定期的なミーティングを設けることや、利害関係者をアンバサダーとして任命して「連絡将校」として育成するなどです。利害関係者/アンバサダーとのワークショップを手配しましょう。ユーザー体験担当者とチームを組んで実行しましょう。例えば、ユーザージャーニーやユーザーストーリーマッピングのワークショップを開催したり、利害関係者をリファインメントのセッションに招待し、ユーザーストーリーの価値を説明してもらったりしましょう。詳しくは、「利害関係者とのコミュニケーション 〜 11の実績のある戦術」をご覧ください。

7. 長年のプロジェクト (pet project) をどう扱っていますか？

新任スクラムマスターが知りたいのは、プロダクトオーナーがプロダクトバックログを本当に守ことができるかです。過去にその人は、「いいえ」と言ったことがありますか？また、スクラムチームが長年のプロジェクト（pet project）に取り組んでいたり、取り組んでいたとしたら、なぜそうなったのでしょうか？

8. プロダクトロードマップの作り方はどのようにしていますか？

ロードマップのプランニングは、ポートフォリオのプランニングと同様に継続的に行われます。プロダクトオーナーは、組織のプロセスを詳細に説明できる必要があります。

9. プロダクトバックログはどれくらいのサイズですか？

私は、スクラムチームが 3 〜 4 スプリントで対応できない大きさのプロダクトバックログが有用だとは思えません。プロダクトバックログがこの閾値を超えている場合、このようなプロダクトバックログの潜在的に不利益な混雑化を防ぐために、プロダクトオーナーにはサポートが必要かもしれません。結局のところ、新任スクラムマスターは、プロダクトバックログから価値のあるシグナルを探しているのです。

10. プロダクトバックログの作業アイテムの典型的な消費期限はどれくらいですか？

すでに5ヶ月も経っている作業アイテムの価値は疑ってしまいます。「でも、それに取り組んできたのです」と言う言い訳が浮かんできます。

PRO TIPS: 「Product Backlog forensics」は、組織がどのように機能しているかについての多くのインサイトを与えてくれます。プロダクトバックログのアイテム数、アイテムの消費期限、アイテムを作成したのは誰なのか、アイテムについてコメントした人、アイテムを変更した人など、データには多くの有益な情報が埋もれています。

11. 検証すべきアイデアの選び対応する作業アイテムをプロダクトバックログに追加するまでの平均リードタイムはどれくらいですか？

これは、実際にはいくつかあるメトリクスの1つです。この指標は、実際にどのように「アジャイル」なプロダクト発見が行われているかのインサイトを得ることができます。

12. プロダクトバックログに現在のチームの誰も知らない作業アイテムがありますか

もしあるならば、現在のチームメンバーと共にそれらのアイテムを再度見返してください。

1. 作業アイテムは、今でも価値を提供するか
2. アイテムの性質について、チームメンバー全員の間で共通認識できているか

13. どれくらいの頻度でプロダクトバックログのリファインメントをしていますか？

プロダクトバックログのリファインメントは継続的な活動とすべきです。私の経験では、スクラムチーム全体が参加する定期的なリファインメントのイベントを少なくとも1回*は開催することが有益であることがわかっています（訳注: スプリントに1回）。

14. プロダクトバックログのリファインメント中に並行して取り組んでいるアイテムはどれくらいあるりますか？

私の経験では、プロダクトオーナーは、次の 1 〜 2 スプリントで扱える以上のプロダクトバックログアイテムを作るべきではありません。そうしなければ、決してスプリントバックログに入らないような作業アイテムにリソースを割り当てるリスクが非常に高くなります。

15. 典型的な作業アイテムのリファインメントにどれくらい時間がかかっていますか？

リファインメントは、1 〜 2 スプリントに跨がるべきではありません。コンテキストの切り替えの危険性や仕掛かり制限は、リファインメントのセッションにも適用されます。

16. 作業アイテムをどのように作っていますか？

作業アイテムを、チームの協働作業として作っているのでしょうか。あるいは、プロダクトオーナーがユーザーストーリーを書いて、チームがそれらを見積もっているのでしょうか。プロダクトオーナーは、開発チームが見積もるための作業アイテムに対して一種の「テクニカルライター」になってしまう傾向があります。しかしながら、作業アイテムの作成は、チーム全体の協働作業とし、共通認識を持つことを強く提案します。詳しくは、「 Essential XP: Card, Conversation, Confirmation」をご覧ください。

17. プロダクトバックログのアイテムの議論をどこでしていますか？

リファインメントセッション中だけですか？または、Slack やアイテムのチケットのコメントで議論していますか？例えば？

18. スプリントバックログのアイテムを変更していますか？もしそうなら、どのような状況で変更しているか？

プロダクトバックログのアイテムがスプリントバックログとして選択された後に、変更されることはありますか？

開発チームが問題に直面した場合に、作業アイテムを小さくすることは決して素晴らしいことではありませんが、受け入れることはできます。作業アイテムがまだ価値を提供しているならばです。しかしながら、スプリントプランニングのあとに、スプリントバックログを大きくすることは受け入れられません。スプリントバックログの構成をコントロールできるのは開発チームだけです。

19. 作業アイテムをいつ受け入れますか？

『スクラムガイド』（2017）では、プロダクトオーナーによる「受け入れ」は、スプリントの中止についての段落において一度だけ言及されています。

部分的にリリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。

『スクラムガイド』

しかしながら、プロダクトオーナーとチーム（のエンジニア）が作業アイテムを「完成（done）」と考えている時に会話することは有用であることがわかっています。

20. 作業アイテムを却下したことはありますか？

作業アイテムを却下したことがあるならば、なぜそのようなことが起きたのか、また、再びおこらないようにするためにどのような対策が取れたのかを学びたいと思うでしょう。