Closed8

Scrum@Scaleのチーププロダクトオーナーは何をすればいいのか

HIMURA TomohikoHIMURA Tomohiko

チーフプロダクトオーナーのすること

  • 戦略的ビジョンを設定する(ゴールの設定)
  • 全チームに配布される、優先順位付けされた単一のバックログを作成する(検証する仮説の決定)
  • プロダクトオーナーチームが測定するメトリクスを決定する(仮説の検証)
  • 顧客からのプロダクトのフィードバックを評価してバックログを調整(適応)
  • プロダクトオーナーチームの運営

プロダクトオーナーチームがやること

  • ビジョンを組織全体に伝達する
  • 顧客と対話し、バックログを調整する (チーフPOがやってるうな…)
  • チーム間での作業の重複が起きないようにする
  • 全チームに適用される完成の定義の設定
  • チームが提起した依存関係の問題を排除する
  • 調整されたロードマップとリリースプランを生成する
  • プロダクトと市場に関する洞察力をもたらすメトリクスを測定する(チーフPOがやったのは決定)

参考にする文献

HIMURA TomohikoHIMURA Tomohiko

チーフプロダクトオーナーとは

チーフプロダクトオーナーは、プロダクトオーナーチームと一緒に優先順位を調整する。共同でバックログの優先順位をステークホルダーと顧客のニーズに合わせる。(中略)主な責務は通常のプロダクトオーナーと同じであるが、スケールされて以下のようになる。

  • プロダクト全体の戦略的ビジョンを設定する
  • 全チームに配布される、優先順位付けされた単一のバックログを作成する
  • プロダクトオーナーチームが測定するメトリクスを決定する
  • 顧客からのプロダクトのフィードバックを評価し、それに応じて共通バックログを調整する
  • メタスクラムイベント(以下参照)をファシリテートする

チーフプロダクトオーナーは、関連するスクラムオブスクラムマスターとともに、リリースプランに従ったプロダクトインクリメントの効率的なデリバリーに責任を負う。
https://scruminc.jp/scrum-at-scale/guide/#CPO

プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、

  • プロダクトゴールを策定し、明⽰的に伝える。
  • プロダクトバックログアイテムを作成し、明確に伝える。
  • プロダクトバックログアイテムを並び替える。
  • プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。

上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。

プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって⾒える化される。

プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
https://scrummaster.jp/scrum-guide#プロダクトオーナー

HIMURA TomohikoHIMURA Tomohiko

チーフプロダクトオーナーは通常のプロダクトオーナーとは大きく変わらなくて、

  • ゴールを設定する
  • やることの優先度を決める
  • 透明化し、事実を把握できるようにする
  • ステークホルダーと話をする

あたりは同一。追加としてチーム外で波及することイベントへのファシリテートが追加されているように読み取れる。

以下の責任を持つように読み取れる

  • プロダクトのデリバリー責任
    • デリバリーしてプロダクトがはじめてユーザへ価値を提供するため
  • プロダクトの価値の説明責任
    • 何をつくるか決めるため
HIMURA TomohikoHIMURA Tomohiko

プロダクトオーナーチームのスケーリング

プロダクトオーナーチームを設けることで、関連するスクラムオブスクラムとともにスケールするプロダクトオーナーのネットワークデザインが可能になる。これらの拡張ユニットには特定の用語はなく、チーフプロダクトオーナーの特定の拡張された肩書もない。プロダクトオーナーチームやチーフプロダクトオーナー向けの用語や肩書は、各組織で独自に設定することを奨励する。
https://scruminc.jp/scrum-at-scale/guide/#lwptoc11

一人だったプロダクトオーナーがチームとして扱えるように再定義した、と読み取れる。
プロダクトオーナーチームのネットワークをどのようにするかは、ガイドでは定義しないということのようだ。

HIMURA TomohikoHIMURA Tomohiko

POサイクルのハブ: エグゼクティブメタスクラム(EMS)

アジャイル組織全体に対してプロダクトオーナーの役割を果たすために、チーフプロダクトオーナーは、エグゼクティブメタスクラムイベントでエグゼクティブや主要なステークホルダーと会合する。
Phttps://scruminc.jp/scrum-at-scale/guide/#O_EMS

いままでプロダクトオーナーが一人でやっていたことをスクラムチームでやりたいと思われる。
ステークホルダーとプロダクトオーナーは話をする必要があるため、すべてのプロダクトオーナーがあつまる。

理想は、このリーダーのグループがスクラムチームとして活動することである。

とあるため、チーフPOをプロダクトオーナーとし、各チームのプロダクトオーナーが開発者となるスクラムを形成する。

HIMURA TomohikoHIMURA Tomohiko

プロダクトオーナーサイクル

“What”を調整する – プロダクトオーナーサイクル
プロダクトオーナー組織(プロダクトオーナー、チーフプロダクトオーナー、エグゼクティブメタスクラム)は、プロダクトオーナーサイクルの以下の固有コンポーネントの要求を満たすために全体として機能する。

  • 戦略的ビジョン
  • バックログの優先順位付け
  • バックログの分割とリファインメント
  • リリースプランニング

スクラムの作成物と対応するもの。
スクラムの作成物は、

  • プロダクトバックログのためのプロダクトゴール
  • スプリントバックログのためのスプリントゴール
  • インクリメントのための完成の定義

であり、若干表記としてはズレがあるが同じことを指しているように見える。

HIMURA TomohikoHIMURA Tomohiko

プロダクトオーナーサイクルとスクラムマスターサイクルをつなぐ

プロダクトオーナーサイクルにたいして、HOWを調整するスクラムマスターサイクルが存在し、これらを協調させないといけない。

“What”と“How”の責任は、完成したプロダクトがデリバリーされるまで分離される。これらのサイクルは、プロダクトに対する顧客の反応が解釈されるフィードバックコンポーネントで再度交差する。次のデリバリーサイクルへの適応に関する経験に基づく決定を行うには、ここでメトリクスが必要になる。プロダクトオーナー組織とスクラムマスター組織は、協力して、これらのコンポーネントの要求を満たす。

つまり、デリバリーしなければ、責任が分離された状態になる。
次のデリバリーをするために、デリバリーしたものにユーザに価値があるかどうか図る必要がある。これを図るためのメトリクスが必要、と解釈できそう。

HIMURA TomohikoHIMURA Tomohiko

メモ

  • メタスクラムに対する言及が一切ないことに気づいた
    • エグゼクティブメタスクラムはメタスクラムの特殊例であり、メタスクラムそのものではない
    • 参考書籍はこれになっている Sutherland, Jeff、Coplien, James O.、The Scrum Patterns Group、A Scrum Book: The Spirit of the Game(スクラムブック: ゲームのスピリット)、Pragmatic Bookshelf、2019年。
    • ガイドに登場する図からして、SoSに対応するスクラムであるように見える。

複数のスクラムオブスクラムが存在する大規模な実装の場合、エグゼクティブメタスクラムで戦略的バックログの作成と優先順位付けがされた、複数のメタスクラムが存在する可能性がある。

この言及が、1段のスクラムの場合メタスクラム自体が、エクゼクティブメタスクラムであることを示唆しているようにもみえるし、直感的にも自然である。

このスクラップは2021/09/21にクローズされました