CSP-SM受けてみることにしたそのxに向かって「プロダクトオーナーロールのスケーリング」

2022年3月17日 00:16

ここまでのあらすじはここから

5.4 少なくとも2つのパターンのプロダクトオーナーロールのスケーリング方法を比較せよ

今回の2つのパターンは以下です

プロダクトの規模を大きくする必要があるタイミングでプロダクトオーナを増やすパターンです。

増やし方はプロダクトのエピック(バックログの大きいものなイメージ)くらいの大きさのフィーチャーにつき１スクラムチームにします。

１スクラムチームの構成は下記です。

フィーチャー単位を明示的に説明すると、１スクラムチームが取り掛かるバックログのオリジナルは有機的でなければいけません。

画面区切りのような、スクラムチームがインクリメントを作ったとしてもユーザー価値を生まない単位でチームを分けてはいけません。

ユーザー価値を生まない単位でチームを分けると以下のような弊害が起こる可能性があります。

プロダクトオーナーのやることが多様化・複雑化していく事があります。その状態で、１プロダクトオーナーの限界が来る場合にプロダクトオーナーチームを作ります。

最初のプロダクトオーナーが全体のオーナーシップを持ちます。サポートのプロダクトオーナーが、フィーチャーやコンポーネントやマーケティングなどを担当するパターンです。

バックログボードは1つです。
最終権限もオリジナルのプロダクトオーナーが持ちます。

プロダクト自体の規模が大きくなる場合には１の状態で対応可能です。
プロダクトの規模は1つの開発チームで足りても、プロダクトオーナーとしてのプロダクトマネジメント業務が忙しい場合には２の状態で対応可能です。

1のパターンはフィーチャーチームにつき1つのバックログボードがある状態なので、プロダクトとしてはスクラムチームの数だけバックログボードがある状態です。

2のパターンはプロダクト1つに対してバックログボードを1つにしています。

あるプロダクトAのリリースにSaaS基盤としてのプロダクトBを使用することになりました。

２つのプロダクトは共に機能拡張が必要で、プロダクトの方向性統一のために2つのプロダクトに対して1人のプロダクトオーナーがオーナーシップを持つことにしました。

成功したこと

プロダクトAに対しては方向性の一致が取れました。同じく、スケジュール感の調整もうまく行きました。

しかし、プロダクトBに対してはプロダクトA中心のバックログが優先になってしまいました。そのため、プロダクトB自体の価値向上やプロダクトBのメンバーの成長へのバックログ価値は少ないものになってしまいました。

プロダクトオーナーとチームとバックログボードの関係を適切にする必要があります。

プロダクトオーナーは、関係するチームメンバーの成長や満足にも貢献できるプロダクトマネジメントを行う必要を感じました。

バックログに関しては、単純にチームの数ボードがある状態にすることは時には問題を引き起こします。

依存関係がない状態で、さらにプロダクトの価値に貢献できる順序で明確に並べられている必要があります。