研究開発でのプロダクトバックログの作り方

プロダクトバックログの作り方

スクラムを実践する中で、いつまで経っても「難しいなー」と感じるのはプロダクトバックログの作り方だ。
ただ、ここに対しては@ryuzee さんがかなりわかりやすくまとめてくれている。

初期のプロダクトバックログの作り方

なのでこれを読みましょう。という話なのだが、研究開発だと少し勝手が違ってくる。

「＜人＞として＜機能＞ができる。それによって＜価値＞が得られる」

このような受益者目線のユーザーストーリーは研究開発においても必要だが、研究開発ではそのユーザーストーリー実現の目処が立っていないことが多い。また、そもそも実現方法が複数存在することもある。なのでまず手段の妥当性を探る必要があるのだ。

実現方法をPBIとして作成する

となると、ユーザーストーリーの実現の前にそのユーザーストーリーを実現方法を探る必要がある。自分の場合、「fugafugaのアルゴリズムの妥当性が確認されている」のように表現することが多い。
そして、妥当性を確認するにはその指標が明らかになっている必要がある。研究開発の場合、そもそもここさえも明らかではない場合が多い。
そして経験上、ここが曖昧だと研究開発は良し悪しを判断できず泥沼化することが多い。
なので以下のようなPBIを以下のような順番でこなしていくことになる。

・hogehogeの妥当性を評価する指標が確定している
・fugafugaのアルゴリズムでプロトタイピングされている
・fugafugaのアルゴリズムの妥当性が確認されている

そして、妥当性を確認すると、ユーザーストーリーと照らし合わせて物足りないところができる。そこに対してまた上記手順を繰り返していくのだ。

通常のPBIと同じく、ToDoではなくToBeで記述する、というのは気をつけたい。それを実現するとなにがもたらされるか、が明らかになっているべきだからだ。

今回は、自分が研究開発チームで行っているプロダクトバックログの作り方について簡単に紹介した。うちはこうやってるよ、とかこうやったほうがいいよ、というフィードバックがあれば、ぜひお願いします。