見出し画像

プロダクトバックログの優先順位を”フェア”に決める

今回は、プロダクトバックログの優先順位付けに関する記事になります。

皆さんのプロダクトオーナーは、プロダクトバックログを”フェア”に管理していますか。発言力のあるステークホルダーから言われるがままにリリースしていたり、不要な項目でバックログが溢れかえっていませんか。

プロダクトバックログは、発言力などに影響されず、”フェア”に価値を見極めて決める必要があります。

今回は、スクラムを前提に優先順位の決め方や重要性について解説していきたいと思います。

プロダクトバックログとは

バックログというのは、優先順位付けされた作業リストです。つまり、プロダクトバックログとは、プロダクトに関する作業に優先順位付けされたリストになります。

この”作業”とは、改善に必要な新機能、バグ、技術的負債などを意味します。Todoタスクのような細かい作業を意味するものではありません。

各スプリントで取り組む作業は、プロダクトバックログが淵源になります。優先順位は、プロダクトオーナーが最終責任を持ちます。

以下は、スクラムガイドとPMBOKにおける記載です。参考までに引用します。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。

スクラムガイド -P.14

バックログとは、完了すべき作業の優先順位付けされたリストである。プロジェクトには、プロダクト・バックログ、要求事項バックログ、障害事項バックログなどがある。バックログ内の項目には優先順位が付けられる。優先順位付けされた作業は、その後、次回のイテレーションのスケジュールに組み込まれる。

PMBOKGuide7thEdition -P.185

プロダクトバックログと優先順位の重要性

スプリント毎にリリースされる価値を含む生成物の根源は、プロダクトバックログになります。つまり、バックログ上に表現される優先順位は、プロダクトの戦略・ビジョンを示唆するものです。順にリリースされることで体現されます。

優先順位の最終責任は、プロダクトオーナーにありますが、往々にして現場では発言力のあるステークホルダーが干渉します。誰が見ても価値が高く、希求するものであれば話は別ですが、そうとは限りません。

言われるがまま無尽蔵に登録すると、不要な項目でバックログが溢れかえってしまいます。挙げ句の果には、不本意な優先順位が決められてしまい、戦略・ビジョンと乖離してしまいます。

発言力などに影響されず、価値を見極め、フェアに決める必要があります。すべて「Yes」ではなく、時には「No」が必要です。そのためには、根拠となる戦略やビジョン、優先順位付けが必要です(戦略やビジョンに関しては別記事で書ければと思います)。

プロダクトバックログの優先順位を決める方法

大きく以下のステップを踏んで決めます。
1.価値と労力から優先度(重要度)を決める
2.緊急度を考慮して優先順位を決める

1.価値と労力から優先度(重要度)を決める

プロダクトバックログアイテムの「価値」と、それを実現するために必要な「労力」を決めます。そして「価値」を「労力」で除算し、「優先度(重要度)」を求めます。

優先度(重要度)=価値/労力

「価値」は、プロダクトオーナーが決めます。なぜなら、プロダクトの必要性やビジョン、市場動向、ペルソナを一番熟知しているはずだからです。必要に応じてステークホルダーから意見を募ります。

価値を評価するには様々な観点が必要です。具体的には、以下です。
・戦略、ビジョンとの整合性(ペルソナ含む)
・お金(販売数を増やせるか、販売価格を上げられるか、コストを削減できるか)
・リスク(ステークホルダーへの影響、市場への影響、他機能への影響)
・組織開発(チームスキルの向上に寄与するか)
・その他(汎用性/独自性、充足/不充足、満足/不満足)

※価値は、同じアイテムでもペルソナごとに異なる場合があります。そのため、ペルソナごとに評価した価値を戦略・ビジョンに照らし合わせることが必要になります。

「労力」は、開発チームが決めます。なぜなら、当の本人たちが実際に取り組むからです。また、技術を一番熟知しているはずです。プロダクトオーナーが干渉してはいけません。

各々の大きさはフィボナッチ数列を用いて決めます。そして「価値」を「労力」で除算し、「優先度(重要度)」を導きます。結果として「優先度(重要度)」は、価値が大きく労力が低いものが高くなります。そして価値が小さく労力が高いものは低くなります。

以下のような4象限で表現することができます。

プロダクトバックログアイテムの価値と労力のマトリクス
価値と労力のマトリクス

2.緊急度を考慮して優先順位を決める

ステップ1で導いた「優先度(重要度)」に対して「緊急度」を考慮し、「優先順位」とします。

「緊急度」の評価は、”緊急である”と”緊急ではない”の2択で問題ありません。以下の4象限に合わせてアイテムを分類できれば良いためです。(緊急度に重みを付け、スプリント内の着手順などを決めることも可能です)

The Eisenhower Decision Matrix をもとにした対応方法
The Eisenhower Decision Matrix をもとにした対応方法

「排除」に分類されたアイテムを除いて、基本的に「優先度(重要度)」の高いものから実施します。「排除」のアイテムは、削除するだけです。バックログが不要な項目で溢れかえることを回避します。

プロダクトバックログは定期的に見直す必要があります(理想は常に最新ですが)。見直す際は、上記のステップを再度実施します。

ステップ1で緊急度を同時に考慮しないことが、肝要です。同時に考慮すると、正しく価値を見定めることが難しくなります。

バグが良い例です。緊急ということだけで価値が高くなる傾向が見られます。そのバグが修正されることで生まれる価値は、本来もっと小さいかもしれません。特定のステークホルダーだけが困っており、早く直してほしいと言っている場合などです。

プロダクトバックログの優先順位を決める方法まとめ

プロダクトバックログの優先順位を決める方法まとめ

優先順位を決める方法をご紹介しました。以下のステップを踏みます。
1.価値と労力から優先度(重要度)を決める
2.緊急度を考慮して優先順位を決める

これらのステップを踏むことで根拠のある優先順位をフェアに決めることができます。不要なバックログアイテムは、根拠をもって「No」と言え、発言力のあるステークホルダーが干渉してきても説明することができます。

プロダクトオーナーは、プロダクトの価値を最大化する役目を担います。これはプロダクトの舵取りといえるでしょう。

不甲斐ない舵取りは、クルーの士気を下げ、暗礁にいつ乗り上げるか分からない剣呑さがあります。適切な方向に舵を切り、目的地を目指すためには、コンパスと時宜を得た対応が必要になります。

ビジョンや戦略をコンパスだとするならば、時宜を得た対応は適切な優先順位でリリースされるバックログアイテムだと思います。そのためにも忖度ないフェアな優先順位を心がけていきたいですね。

【合わせて読みたい】

ーーーーーーーーーーーーーーーーーー

いかがでしたでしょうか。
ぜひスキとフォローもお願いします!
では、また!
※本記事の内容は個人の見解であり、私が所属する組織とは一切関係ありません。

この記事が参加している募集

最近の学び

この記事が気に入ったらサポートをしてみませんか?