はじめに
AgVenture Labの藁谷です。
私たちの開発するレシピアプリ「エプロンシェア」にて、Sprint0のピボットを行いました。
その結果新しいユーザーストーリーが24個発生、こりゃぁ見積もりに精が出るなぁと開発チーム一同戦々恐々としておりますと、我らがアジャイルコーチより「マジックエスティメイトやってみれば?」とのご提案。
調べてみると普段使っているエスティメイションポーカーより精度は低いが、素早く見積もることができるということなので、実際やってみたらかなり有効でしたというお話しです。
黙って実施する特徴から「(黙っている間に)勝手に見積もりが終わって魔法みたい」「お葬式みたい」ということでこんな名前らしいです。
ちなみにストーリーポイントだけでなく、ビジネスバリューの見積もりにも使えるようです。(ここでは触れないので参考動画1を参照してください)
目次
前提
やり方自体は色々あるようですが、私は参考文献にあげた4つほどのサイト・動画を参考に、チームに合うよう手を加えています。
そのため「ここちょっと違くない?」「なんでこんなルールにしてるの?」と言ったご意見あるかと思いますが、ご容赦願います。
チームの概要
- 現メンバー体制での見積もりは、週1回~隔週1回の頻度で半年間ほど実施。
- ストーリーポイントのボリュームゾーンは2~3で5を超えるとストーリー分割が視野に入る。
- 基準ストーリーポイントは3、vue+java+MySQLでユーザ検索処理を一通り作成するもの。
- 議論はmiroを利用している。
対象ユーザーストーリーについて
- ユーザーストーリーマップはスクラムチーム全体で議論済み。
- 優先度高中低分類後、高のものについてPOにてストーリー起票・優先順位並び替え済み。
- 各ストーリーの受け入れ基準は未整備、または概要程度の記載のものがほとんど。
うちのチームで実施した手順
事前準備
- ストーリーを付箋に書き出す。
- ホワイトボードに以下のような領域を作る。(縦軸優先順位、横軸ストーリーポイント)
- その際、不明点があり概算見積もり不可なものをおく「?」領域を作成。
- 書き出した付箋を各メンバーに配る。
ラウンド1(5~7分)
- 各メンバーは手持ちの付箋を見積もり、いずれかの領域に貼り付け。
- ラウンド中は会話はNG。
- 時間が余ったら他の人の貼った付箋を確認して次のラウンドに備えます。
時間に関しては付箋1枚につき1分程度でも時間余りました。
PO確認時間(10~15分)
- 「?」領域に配置した見積もり不可の内容をPOに確認。
- 概算見積もりに不要な細かい議論はここではしないように。
議論は先送りせず一通りの「?」項目には目を通した方が良さそうです。
会議のバッファ使用先としては優先度高いかと思いますが、
複数ラウンド回すのとどちらが効果あるのかは検証していません。
ラウンド2以降(5~7分)
- ストーリーポイントが自分の想定と異なるものについて付箋を移動させる。
- 各付箋のラウンド内での移動は1度のみ。
(動かされた付箋を動かしたいときは議論を聞いてから次のラウンドで動かす。) - 移動した際にはストーリーポイントの移動履歴(いつどこから)を付箋にメモする。
- ここでもラウンド中は会話はNG。
議論・PO確認時間(5~7分)
- 「?」領域に配置した見積もり不可の内容をPOに確認。
- 移動させた付箋についてその理由を端的に述べる。
- 議論の結果移動の取り消しOK、その場合付箋を戻し移動履歴のメモを削除。
以降ラウンド、議論を繰り返す
- 議論が繰り返されるストーリーは「?」に入れて後日の検討に回す。
- 付箋の移動がなくなったらラウンド中でも切り上げて良い。
- 決めた回数のラウンド完了で終了。
チームとしてある程度収束の合意が取れたら終わりでもいいと思います。
終了後
- 「5より大きい」領域に配置されたものは議論が必要なストーリーとして可視化。
- 移動がなかったものはセットされた値でストーリーポイント確定。
- 隣り合う2つの領域間のみ移動したものは平均値でストーリーポイント確定。
- それ以外のものは議論が必要なストーリーとして可視化。
可視化方法は99や-1など仮の値をセットするとわかりやすいかもしれません。
注意点・感じたこと
-
新しく結成されたチームでいきなりは難しそう。
- POも開発者も同じストーリーポイントの基準を持っていないとかなりブレそう。
- ストーリーが十分に小さいサイズでないと結局全て要議論対象になる。
-
ラウンド1のストーリーポイントは追跡しなくて良さそう。
- ラウンド1からラウンド2はブレが大きいものの、それ以降はかなり収束傾向。
- チームとして認識の共有が取れているものの、ルール上要議論になってしまう。
-
リリース計画に用いる場合、かなり概算の見積もり結果であることを認識しないと危ない。
- エスティメイションポーカーでの見積もり以上にリリース期間のバッファは必要。
- これでキツキツのリリース計画立てられたら…
- 説明の上認識、計画を改めてもらう。
- 求められる見積もりの精度が足りない→時間取って見積もった方がいい。
-
24件中 削除1件 確定20件 要議論3件 となった
- ストーリー説明30分、マジックエスティメイト説明5分、見積もり振り返り7分を除くと
所要時間は以下表の通りになりました。 - 初回のPO確認は4件ありました。
- ラウンド2、ラウンド3は時間余りまくりでした。
- ストーリー説明30分、マジックエスティメイト説明5分、見積もり振り返り7分を除くと
内容 | 所要時間(分) |
---|---|
ラウンド1 | 6 |
PO確認 | 15 |
ラウンド2 | 6 |
議論・PO確認 | 7 |
ラウンド3 | 5 |
結果の確認 | 7 |
合計 | 46 |
まとめ
ストーリーの粒度がある程度小さい(というかチームに馴染みのあるサイズ)必要があるが、1件につき2分程度で見積もりができた。
「内容説明」「意見聴取」「ポーカー実施」 などが必要ないストーリーの分が時短になる。
あくまでも簡易見積もりです。
直近作業分ストーリーはPBRなどで詳細確認・必要に応じた再見積もりが必要です。
参考文献
- Magic Estimation
- Magic Estimation - Process to estimate Agile Scrum projects fast
- 魔法見積もり(Magic Estimation)
- Magic Estimation
-
https://www.workshopwednesday.co/videos/magic-estimation 4:50あたりからビジネスバリュー、9:00あたりからユーザーストーリーポイントの見積もり ↩