はじめに
プロダクトバックログの優先順位は、POの大きな役割の一つですが、間違った優先順位をつけてしまうと、大きな損失を生み出す可能性があります。今回、優先順位を決めるプロセスをご紹介します。全てのケースにおいて、このプロセスが適用できるとは言えませんが、ベースがあることで、柔軟な個別対応も行うことができると思っています。
なお、オフショアを使っている使っていないは関係ない話題となります。。
Step1. ヒアリング
まず、ヒアリングからですが、下記の3つを確実に聞き出すこと。
要望 (たとえば、カレンダー機能がほしい) ・要望だけでは、本当にその方法で根本的な問題を解決できるかどうか判断できない。
理由 (たとえば、お客様の作業依頼チケットを視覚的に理解したい)
背景 (たとえば、お客様の作業依頼の件数が先月から倍に増えた) ・理由や背景を把握することで別のよい方法で解決できる可能性もある。 ・バックログにも記載し、開発チームに伝える必要もある。
ここで注意しなければならないのは、
事実 (たとえば、お客様アンケートの結果)
予測 (たとえば、マネージャーからの要望)
アジャイル開発では、MVPから開発していくことが鉄則であり、予測は価値がないものをリリースしてしまうリスクが高まります。そのため、この後のステップは、事実ベースで進めていきます。ついつい主観だけで必要と思っていても、ぐぅっと堪えるなければなりません😆
Step2. 品質要素の分解
次に、品質を区分化し、価値があるものを選別します(狩野分析モデルを利用)。
品質 | 内容 | 価値 | スマフォ例 |
当たり前 | あるのが当然で、なければ不満になる。 | ◯ | パスワードロック |
性能 | なくても良いが、あればあるほどよい | ◯ | 指紋・顔・音声認証 |
魅力 | 想像もしていなかったもの。 | ◯ | 虹彩認証(マスクしながら使える) |
不問 | あってもなくても良い。 | ✕ | 認証の履歴 |
逆行 | あっては困るもの。 | ✕ | パスワードの共有 |
不明 | 回答がよく分からない。 | ✕ | 次世代の認証方式 |
Step3. ビジネス価値のマトリックス作成
そして、WSJF(Weighted Shortest Job First)の手法をもとに、優先順位を決めます。この手法により、多角的な視点で価値を判断することができます。
開発チームの見積もりで使うプラニングポーカーを利用して、PO、SM、ステークホルダーが集まって実施するとよいでしょう。
緊急度
早くやることによりもたらされる価値(もしくは、早くやらないと棄損してしまう価値)を見積もります。
ビジネス機会
将来的にこの機能がもたらす価値を見積もります。
開発難易度
想定する仕様を整理した後に、開発の労力を見積もります。開発チームに依頼してもよい。
Step4. エピック化してMVPの絞り込み
ここまでで、優先順位の高い機能を整理することができました。まだ終わりではありません。。
次は、機能をエピック単位に分解し、MVPとそうではないものを分類します。MVPから外れたものは、その機能内で優先度を下げます。場合によっては、他の機能の優先度と比較して、開発を後に回すこともあります。
さいごに
優先度を決めるプロセスを明確、かつ透明化すると、ステークホルダーに説明しやすくなります。忖度や個人的な都合で優先度を決めづらくなります😉。
スプリント中に新たな要求があった場合でも同様に優先度を決めていきます。スプリント中にバックログの優先度を動かすことはよくあることですが、柔軟に組み替えることができるのは、アジャイル開発だからこそ!
もし顧客向けバックログの期限に余裕があれば、ときには開発向けバックログ(バージョンアップ、技術負債など)を優先し、バランスを取ることも忘れないようにしましょうー
Comments