Henrik Kniberg氏がブログ記事agile product ownership in a nutshellでプロダクトオーナから見たアジャイルソフトウエア開発を概括している。氏は“プロダクトオーナ―シップを学ぶ1日のトレーニングコースを15分のアニメーションに圧縮”した動画を紹介し、視聴を勧めている。動画の雰囲気を紹介するため、下記にこの動画が扱っていることを引用したい。
スクラムでは、ユーザストーリーとして表現される利害関係者のニーズは一覧にされる。これは、プロダクトバックログと呼ばれ、プロダクトオーナが責任を持つ。
プロダクトオーナはバックログに何を入れ、バックログから何を外すかを決めます。さらにバックログの順番を決めます。今ビルドするのか何か、何を後回しにするのか。これは大変な仕事で、チームや利害関係者と一緒に決める必要があります。
プロダクトオーナとチームは一緒にプロダクトバックログを管理する。
ストーリーの価値と大きさを見積もり、優先順位を付け、ときに分割をする。このような仕事は通常“バックロググルーミング”と呼ばれます。Patは毎週水曜の11:00 – 12:00にバックロググルーミングのワークショップを開催しています。チームは皆出席し、ときどき数人の利害関係者も参加します。アジェンダは多岐にわたります。見積もりに注力するときもあれば、ストーリーの分割を行うこともあります。ストーリーの受け入れ条件を記述する場合もあります。
スクラムの各役割はソフトウエア開発においてそれぞれ独自の焦点を持っている。
スクラムの役割の間には健全な緊張関係があります。プロダクトオーナは正しいソフトウエアを構築することに注力します。チームはソフトウエアを正しく構築することに注力します。スクラムマスタやアジャイルコーチはフィードバックのループを短くすることに注力します。
プロダクトオーナとチームは協力して品質と進捗のバランスを取る。
チームが技術的負債をため込んでいるのなら、つまりテストを書いていない、アーキテクチャを継続的に改善していない、という状態なら、進捗は遅くなりストーリーの消化を表すグラフも平坦になります。これでは、先の見通しを立てられません。したがって、チームは持続可能なペースを維持することに責任を持ちます。そして[プロダクトオーナは]チームに近道をしようとする圧力がかかるのを避けます。
複数のチームが一緒に働く大規模なプロジェクトの場合、1人以上のプロダクトオーナがいる場合がある。この場合は、プロダクトオーナ同士の協力が不可欠だ。
複数のチームがある場合、プロダクトオーナにはもうひとつ重要な責任が生まれます。お互いに話し合うことです。チームやバックログは依存関係が最小限になるように組織するべきですが、どうしてもある種の依存関係は残っていしまいます。したがって、プロダクトオーナの間である主の同期を行い、理にかなった順番で開発を行い、部分最適が生まれないようにします。
Mountain Goat Softwareはlearning scrum – the product ownerというページでプロダクトオーナの役割について書いている。プロダクトオーナは開発したいもののビジョンを持ち、それをスクラムチームに伝える。チームとプロダクトオーナはひとつのスプリントでどのくらい開発を行うのかを決める。
プロダクトオーナは"あと4つのスプリントが残っているから、今回のスプリントではプロダクトバックログの4分の1を消化しなければならない"というようなことを言ってはなりません。プロダクトオーナの仕事はチームを明確でより高みにあるゴールへ進むように動機付けることです。チームのメンバーは自分たちの能力について一番よく知っています。したがって、プロダクトバックログの上位にあるユーザストーリーのうち、どれがスプリント内で実装できるかを選択します。
また、プロダクトオーナとチームは要求変更の管理方法について合意をする。
スクラムのチームは選択したユーザストーリーを完成させることをコミットメントします。それに対してプロダクトオーナは、スプリント内に新しい要求を投入しないことを約束します。要求は変更してもいいが(奨励されてもいるが)、スプリントの外で行わなければなりません。
Faisal Mahmood氏はshould the product owner attend daily scrum, product owner and team engagementというブログ記事でミーティングでプロダクトオーナとアジャイルチームがどのように協力するかを説明している。氏はなぜプロダクトオーナがスプリントの計画策定やスプリントのレビュー、振り返りのミーティングに参加するべきか、説明する。
[プロダクトオーナは]プロダクトバックログの項目(ユーザストーリーや他のフォーマットでの要求)をチームに説明します。そして、チームと一緒にプロダクトバックログの項目(ユーザストーリーなど)の範囲についての理解を共有します。(…) プロダクトオーナがスプリントの計画会議に参加することは必須です。そうしないとチームは価値の低い項目やまったく価値のない項目を選択してしまいます。無駄や混乱、機会損失が生まれてしまいます。
スプリントのレビューはプロダクトオーナが作業を承認する、あるいは認めないための最後の機会です。スクラムチーム(プロダクトオーナ、チーム、スクラムマスタ)と利害関係者はスプリントのレビューで製品の方向性や市場、競争環境について話し合います。この議論の結果、プロダクトバックログを更新することになります。そのようにプロダクトオーナがレビューに参加するのはとても重要なのです。
プロダクトオーナが振り返りのミーティングに出席しないと、チームだけではスプリントの計画方法の改善や、バックログの管理や更新、バックログの整理方法の改善、プロダクトオーナと利害関係者を製品に関わらせる方法の改善、スプリントのレビュー方法の改善ができません。不可能ではないにしろ、とても難しくなります。
Dean Leffingwell氏が作成したscaled agile frameworkはリーンとアジャイルの実践を企業に適用するのに役立つ。これにはプロダクトオーナの役割について書いてある。
プロダクトオーナはチームのメンバであり、チームのバックログ(一般的なスクラムで言うプロダクトバックログ)の定義と優先順位付けに責任を持ちます。さらに、プロダクトオーナは品質に対して重要な役割を果たします。そして、チームの中でただ1人システムのベースラインに新しいストーリーを“取り込む”権限を持ちます。アジャイルを導入するほとんどの企業にとって、これは新しい、そしてとても重要な役割です。フルタイムの仕事(1つか2つのアジャイルチームに1人のプロダクトオーナ)になります。
氏によれば、アジャイルを使ってソフトウエアを開発している企業は複数のプロダクトマネージャとプロダクトオーナとチームのバランスを取らなければない。
開発を成功させることは、ある意味では人数のゲームです。適切な役割に適切な人数を配置することができなければ、ボトルネックが発生し、開発の速度は制限されます。それゆえ、プロダクトマネージャの人数、プロダクトオーナの人数、アジャイルチームの数はおおよそのバランスを取らなければなりません。そうしないと、全体が仕事の定義や明確化、受け入れなどのための待ち時間で時間を無駄にしてしまいます。
Marc Löffler氏は5 reasons why a product owner team might be a good ideaというブログ記事でプロダクトオーナのチームの利点について説明している。プロダクトオーナのチームの利点は、ひとつの開発チームにひとつのプロダクトオーナを割り当てることができる、というのが氏の主張だ。
スクラムマスタがプロダクトオーナを兼任している場合もありますが、稼働できなくなってしまったらどうするのでしょう。これは良くないやりことです。でも、稼働できなくなってしまうことは起こりえます。しかも、一度だけではないでしょう。これもプロダクトオーナのチームのひとつの利点です。チームの1人や2人が稼働できない(病気や休暇で)状態でも、チームは問題なく働くことができます。
もうひとつの理由はプロダクトオーナがチームとして働くことでバックログの品質が改善される。
プロダクトオーナがバックログに新しい項目を追加できる唯一の人であるべきだという規則は、私は知りません。しかし、多くのチームはこのことを理解していません。プロジェクトオーナがチームになることで一緒に働くようになります。もちろん、プロダクトオーナは開発チームと一緒に働き、バックログを整理したり、バックログのメンテナンスに開発者の力を借りたりしなければなりません。プロダクトオーナのチームはチーム内の協力を促進させるのに役立つのです。