まえがき
レアジョブテクノロジーズの三上です。 最近メンバーからスクラムに関する質問や相談をもらうことが増えて、 私自身の経験を振り返ったり、質問の背景や実績を共有してもらう中でスクラムの理想と現場の課題感を議論しながら気付きや考え直す機会にもなっていてありがたいです。
少し古い記事ですが、「スクラムマスターを雇う時に聞いてみるとよい38個の質問」
を見かけてやってみたいなーと思ったので 面接をうける気持ちで直感で書いてみます。
38個をすべて書くと時間かかりそうなので今回は以下の5つの項目の中から
「プロダクトバックログのリファインメントと見積りについて」の項目を抜粋して回答します。
プロダクトバックログのリファインメントと見積りについて
7つの質問に答えていきます。
1.プロダクトオーナーはステークホルダーの要求をプロダクトバックログアイテムに落とし込んでその見積りをチームに求めることになる。その流れでよいか？
流れ自体は良いと思う。 ただ、背景や目指したいゴールは語って欲しいです。 特にうちのメンバーはプロダクト開発したいメンバーが多いと思うので、あるとよりモチベーションも上がると思う。むしろゴールは一緒に考えていきたい。
2.チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
プロダクトオーナーをどんな人が担っているかによって強みは変わると思いますが、 定量的な分析があると開発チームも納得感ありますよね。 実体験で言うとマーケティングにおけるKPIをもとにした仮説には納得感がありました。例えばユーザーの行動分析から想定したユーザーストーリーの追加！のような
これも背景があるとより良いと思っていて、どんな観点で分析したのかなど添えるとより納得感あるしメンバーの学びにもなると思います。
3.誰がユーザーストーリーを書くとよいか？
全員ですね。前提としてプロダクトはみんな触っているよね？と言いたい（私自身への圧でもある） 自分が書いたストーリー採用されて実績出たら一番ハッピーなはず。
4.よいユーザーストーリーとはどんなものか？どんな構造か？
これはシンプルにユーザー目線で5Wで書かれているものですね。 はじめはある程度は粒度が大きくても良いと思います。 起票のタイミングでは5Wのみで、リファインメントの場でHowとHow muchについて議論しながら 粒度を細かくして完了の定義を認識合わせしていけると良いと思います。
5.「Readyの定義」には何が含まれているべきか？
ゴールの定義、何を目指しているか、どう計測するのかですかね。 特にうちだと「どう計測するか」が疎かになりがちなので重要だと思います。 これをサボると謎の仕様みたいな積み上げになってしまうので、どのタイミングで再検討するのかも議論されていると良さそうです。
6.ユーザーストーリーを時間で見積もらないのはなぜか？
時間で見積もりするには調査が必須でかなり時間を取られます。 ポイント見積もりのメリットはコスト安く見積もることですよね。 前提としてそれに時間をかけてしまうのがまず勿体ない、むしろ価値を高めるプロダクト開発に時間を使いたい。 そこで相対的に安く見積もりが出来る、ポイント見積もりをするわけです。
ポイントはあくまでユーザー価値があってより安く作れるのはどれだ？の判断材料でしかないです。 ただポイント見積もりするには不確実性が高すぎる場合や不安が大きい時は調査タスク（Spike）を起票してtimeboxを決めて調査してから 見積もるのも良いプロセスだと思います。
一方でベロシティをチームの成長指標をして置くこともあると思うので、「精度の高い」ポイント見積もりは私自身も難しいと感じていますが、 チームの成熟度と共に上げていきたいものの一つでもあります。
7.プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
当然ながら一気に取り組むのは無理なので、リファインメントとスプリントプランニングの場を活用します。 タイミングがバラバラだと読み取れるので直近でやるべきものから優先順位をつけて計画を立てます。 ただ将来的にやりたい、のようなバックログで言う下であれば下のものほど状況が変わりうるし、それに調査やコストをかけると勿体ないので 議論するのは優先順位の高いものだけでも良いと思います。
続きはまた次回！
