はじめに
ポイント
・プランニングポーカーと同じような精度で、かける時間を削減出来る
・ファシリテーションのオーバーヘッド削減による効果
・見積もるユーザーストーリーの量が多いほど効果的
・チームの見積もり能力が平準化されている必要がある
過去記事
AdVenture Lab 藁谷です。今はスクラムマスター兼開発者として働いています！
以前、大規模見積もり手法であるMagic Estimationで多数のユーザーストーリーを短時間で見積もる話を投稿しました。
読んでいただいた皆さんありがとうございます。きっと気になっていると思います「本当に有効だったのか？」ということが…！
ということで、今回は別のプロダクトで27個のユーザーストーリーをMagic Estimationで見積もったので、実際にはどれくらい乖離が生まれているのかについて振り返るとともに、その有効性を考えてみたいと思います。
目次
Magic Estimationについて
どんなんだっけ
大規模＆速度重視の見積もり手法。
チーム内で大体の認識があっているユーザーストーリーについて見積もりを省略することで、ファシリテーションによるオーバーヘッドを削減できる。
デメリットとしては「ぱっと見で要検討事項を全員で見逃してたら終わり」といったところでしょうか。その場合はPBRやプランニングで露見する（はず）ので、なんとかはなりますが、今後の見通しには当然影響が出ますね。できるだけ早くPBRで気づいて再見積もりできるといいですね。
進め方などの詳細は上記にリンク貼っている過去記事を見てください！是非！是非！
（前提）私たちのチームの情報
ユーザーストーリーポイントの基準
私たちのチームでは、以下のユーザーストーリーをユーザーストーリーポイント3としています。
・Vue+Java(SpringBoot)+MySQL
・Webページ側にホーム画面→一覧表示画面の画面および遷移を作成
・DB問い合わせを行い登録されているリストを取得、Webページに一覧表示する
平均的なポイントと分割を検討するサイズ
・平均すると2~3程度に収まるようにユーザストーリーを作成することが多い
・5ポイントを超えると分割を検討する
ちなみに分割を検討するサイズについては、1Sprint平均ベロシティが10弱なので、半分に収まらないサイズだと分割を検討する傾向があります。
・普段はプランニングポーカーを使って1時間あたり8~10くらいのユーザーストーリーポイントを見積もっている
見積もりを行ったメンバー
・数年来、同一プロジェクトを共にし、気心もしれている
・スキルレベルも平準化が進められており、見積もりやプランニングはメンバー全員が実施に問題はない
・POは、開発へに積極的に関与し、受け入れ条件やそのビジョンを明確に伝えてくれる
と、恵まれているチームではあります。
計画からどのくらい乖離した？
全体で見ると
以下の図の通りです。
合計のユーザーストーリーポイントが75に対し実績が79.5とあまり乖離がないように見えますが、不要となったユーザーストーリーが7ポイント分あるので、もし対応要となっていた場合は86.5程度だった可能性があります。
差をとると86.5-75=11.5で、我々のチームのベロシティから考えると1~1.5Sprint程度の差となります。
割と精度高い？すごいぞ！
個別に見ると
デザイン関連のNo.4/6/26(青網掛け)が+9.5で大きく乖離しました。これはデザイナー参画後に画面構成の見直しを行ったためで、想定よりも大きな稼働が必要となりました。
また、不確定要素が多く、5以上としたNo.8/23(黄網掛け)について、No.8は想定通り5以上となりましたが、No.23は多くの機能が他のUSと重複していたため予想を下回りました。
何でうまく行った？課題は？
乖離率としては15.3%ほどと割と精度良く見積もれていたのではないかと思います！
でもそれはなぜなのでしょうか。
うまく行った要因
- 個別のメンバーがある程度の見積もりを単独で行える程度の能力があった
- 受け入れ条件が事前に明確化されていた
- ユーザーストーリー自体の粒度がチームとして扱いやすいサイズのものが多かった（うちのチームだと2~3程度）
- PO、開発者のMVPリリースまでのプロダクトの完成イメージを共有できていた
課題
- UIに変更があり見積もり時から完成イメージが変わった
- 機能が重複してもとりあえずフルで見積もった
- 不要となるストーリーは見積もり時には気がつかなかった
- Magic Estimationには準備のコストがかかる
これってMagic Estimationでもプランニングポーカーでも変わんないじゃん！
こうして見てみると、課題の4.「Magic Estimationには準備のコストがかかる」以外はMagic Estimationでもプランニングポーカーでも同じことが起こり得ますね！
と、いうことはMagic Estimationで見積もりをすれば、精度を落とさず早い見積もりを行えるのではないでしょうか。
プランニングポーカーで意見があまり割れないような、機能の完成イメージや作業内容のイメージの認識共有が取れているチームについてはMagic Estimationを使う価値がありそうです。
（おまけ）課題への考察
UIの変更に関して
当たり前の話ですが、UIに変更が生じればプロダクトの完成イメージも、必要な作業内容も変わりますよね。
私たちはSprint0をインセプションデッキ作成→ユーザーストーリーマップ作成→優先順位検討→見積もりの流れで行っていましたが、私たちのチームにはデザイナーがいないので、見積もり後からスポットで参加していただく形にしていました。これをユーザーストーリーマップ作成後のタイミングでデザイン検討していれば、プロダクトの完成イメージをデザイナー、PO、開発者で擦り合わせた上で見積もりを行うこととなるので、より乖離が少なかったのではないかと考えます。
じゃぁどこまでデザインできてればいいんじゃい
いやほんとそれです。ユーザーストーリーポイントが増大した理由だけに焦点当てて考えてみると、
・元々１画面想定だったものを4画面構成に見直した
・画像情報を一覧表示する機能で「画面に表示する情報」に追加があった
などがありました。
なので最低限 「機能やデータと画面の紐付け」 が決まっていればユーザーストーリーの粒度がより明確になったかもしれないですね。そうすると ワイヤフレームまで作ってもらうレベル なのか？
まぁ、今回は乖離した理由を考えたかったので 「そもそも画面のデザイン検討の結果、実装内容を見直してより良いものを作ろうという行為なので別にいいじゃん」 という思いは隅に追いやってます。
機能の重複について
実施の順序によってどのユーザーストーリーで先にその機能を作るか変わるため、特に何も考えず重複したまま見積もりましたが、機能重複分は関連するユーザーストーリーや重複分のストーリーポイントをメモ書きしておけばより良かったかもしれませんね。
不要となるストーリーについて
こちらについてはどうですかね。。
むしろ別機能追加や本当に必要な機能なのかの検討を後続で出来ていた、ということになると思うので、問題とみなさなくて良いように思えます。柔軟性があるというのは素晴らしいことですね。
結論
条件はあるけどMagic Estimationは十分有効！
最も重要なことですがMagic Estimationが使えそうなのは、通常のプランニングポーカーで大半のユーザーストーリーについて、チーム内で完成イメージ・作業内容の認識共有が取れているような状態が必要ということになります。
また、プランニングポーカーと比べると準備が必要になるので、ユーザーストーリーの数が多いほど効率化の効果は高くなります。
今回では、もともと1時間で8~10程度のポイントを見積もっていたチームがMagic Estimationを使うことで、同じ時間で7倍以上のユーザーストーリーを見積もることができました。
これは議論に時間をかける必要のないユーザーストーリーが多い場合にファシリテーションのオーバーヘッドを削れることがMagic Estimationのキモなんじゃないかなぁと思います。
なお以下の場合効果が薄そうです
- 見積もりに関して課題の多い状態
・ 経験の浅いメンバーがいる場合はその人の事前見積もりに対しての見直し・認識擦り合わせが多くなる
・ デザインや機能に変更が見込まれるユーザーストーリーは時間をとって議論しても再見積もりになることが多い
・ ユーザーストーリーのサイズが大きいと見積もりに時間もかかりズレも大きい - 見積もる対象のユーザーストーリーが少ない場合
・ わざわざMagic Estimationのための準備をしても時間削減効果が薄い
スクラムマスター目線で思ったこと
- 普段行っているプランニングポーカーと比べても、より全員参加型の印象が強い
・最初は一人で見積もらないといけないので全員頭フル回転
・見積もり根拠を問われた時のため不明点も「まぁいいや」で放置しにくい - 1件ごとに「ユーザーストーリー説明→質問の確認→見積もり→認識合わせ」とした時の(無駄に感じる)時間がない
- 全体の機能をまたがって確認するので、今後何をしなくてはいけないかをメンバー全員で共有しながら進められていた
見積もるべきユーザーストーリーが大量にある時じゃないとなかなか使う機会も少ないかもしれませんが、普段の見積もりに飽きた時にやってみても面白いかもしれませんね！どなたかやってみて記事書いてください！（無責任）
以上！！！