CSP-SM受けてみることにしたそのxに向かって「プロダクトビジョンをバックログ化した話」

2022年3月21日 23:19

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

4.1 プロダクトビジョンをバックログに落とし込む2つのテクニックを考える

選んだ二つ

もう・・・ただただ頑張るというのがテクニックなのか・・・。

プロダクトビジョンをバックログに落とし込むた目のテクニックは、方向性をそろえながら、ブレイクダウンをしていくことです。

プロダクトにはなりたい姿があるはず(プロダクトビジョン)です。
そのビジョンを達成するために指標となるゴールを作成します(プロダクトゴール)。
これ以降は、スプリントでどのように進んでいくかという問題になります。

プロダクトのゴールが決まった後は、スプリントで達成すべきスプリントゴールを決めます。プロダクトゴールに向かうための一歩を細分化したものスプリントゴールに設定されます。

さらにスプリントゴールから具体的に達成すべきインクリメントを創発するプロダクトバックログを作ります。
これにより、プロダクトビジョンから落とし込まれたプロダクトバックログが作成されます。

スクラムイベントのイメージで言うと、

の方がより適切かもしれません。

しかし、今回はどのようにバックログに落とし込むかを考えるために違う順番とします。

プロダクトのビジョンはIssue(イシュー)から作られていると仮定します。
顧客が抱えている、課題やニーズを解決した状態が示されているのがプロダクトビジョンということです。

そのプロダクトビジョンを達成すべく、イシューを細分化したものをバックログとする方法です。

顧客課題から直接バックログに変換されるので、中間生成物が作成されづらいです。

※ここでいう中間生成物とは、本来の顧客課題を満たすために派生した一次ニーズとしてのインクリメントではありません。一次ニーズを満たす条件として発生してしまった二次ニーズのためのインクリメントのことを中間生成物と捉えています。

前提として、二次ニーズから誕生したプロダクトの話になってしまいます。それは本人認証のためのプロダクトでした。

「〇〇を利用した本人認証ができない」という比較的、機能に近い課題から派生したプロダクトだったので、バックログに落とし込みやすかったのです。

まず最初に作ったバックログは「〇〇を利用した本人認証ができない」。
方法問わず、指定した方法で本人認証ができれば良いわけです。
バックログの内容の記載の流儀も特に意識してはいません。チームとコミュニケーションを取れれば良いので、まずはこの内容でチームの創造性に任せました。

外部のAPIを使うことや、他のプロダクトの管理画面を流用することは決まっていました。

結果として、一連の流れを見るまで1週間スプリント2回で到達したことが、この時のチームの成果です。

課題を解決するために、やらないことを決め最低限の機能作成をしました。
これによって２スプリントで検証可能な何かができたことは、スクラムチームにとって大きな経験となりました。