はじめに
スクラムでの見積もりは意外とさらっと書かれている事が多く、作業見積もりと規模見積もりがごちゃごちゃの状態でスクラムを進めていた結果、チームの中で見積もりに対する不信感が強くなり「このままではいけない」と感じたため、まとめました。
また、似たような記事があまりネット上で見かけなかったため、ここにざっくりと分かるように集約しました。ぜひ、自分のようにごちゃごちゃになってしまっている方に届けば嬉しいです。
まず何のために見積もるか
アジャイルのチームにとって、作業を見積もることは、良い予測を追求しようとするだけではありません。チームが要求を深く理解し、開始する前に何を構築しようとしているのかをより深く考え、一定時間内にチームで協調して取り組むことで、構築しているものに対して大きな価値を生み出すことを促します。 (アジャイルメトリクス p40より)
見積もりによってプロジェクトの状態が見えてくる。
たとえばベロシティは
- 仕事の見積もりの適正度
- 安定した仕事の完了度
- 安定したコミットメントの作成と達成度
が分かる。他にも様々なメトリクスを組み合わせることで分析ができる。
また、ベロシティをベースにリリース計画を立てることで、勘ではない実績に基づいた計画を立てることができる。
見積もりと計画づくりは、期日やスケジュールを決定するためだけのものではない。計画づくりとは価値の探求なのだ。(アジャイルな見積りと計画づくり p28より)
見積もりと計画づくりによって
- リスクを軽減する
- 不確実性を減らす
- 意思決定を支援する
- 信頼を確率する
- 情報を伝達する
メリットを享受できる。そしてこれらはプロダクトの価値の探求に繋がる。
これらはチームが自己管理できるようになるためには必須のものであり、チームが自己管理するために見積もりを行う。
見積もりの費用対効果
必要十分な労力をかけたうえで、大まかに正しい見積もりを目指す。
やりすぎても見返りが少なく可能性もある。
出典：『エッセンシャルスクラム』
スクラムで見積もるタイミング
スクラムでは見積もるタイミングが２回ある。
バックログリファインメント
概要
【いつやるか】 スプリント中にいつでも
【何をやるか】 プロダクトバックログアイテムの作成と改良（詳細の追加）、見積もり、優先順位付け
【誰がやるか】 プロダクトオーナーが主導で行うが、ステークホルダーやスクラムマスター、そして開発チームが参加する
【どのくらいやるか】 スプリントの作業時間の最大1割まで確保OK
ユーザーストーリーやバグ修正などのプロダクトバックログアイテムをストーリーポイントで規模感を相対見積りで行う。
ここでの相対見積もりの手法としては『ストーリーポイント』と『理想日』の2種類がある。どちらもメリットがある。
ストーリーポイントの見積もりが大きくなったら機能面での分割を行う。
POがPBIに対して見積もりがほしいときは人を招集し、見積もりを行う。
ストーリーポイントのメリット
- 職能横断的な作業の進め方を促進する
- 長持ちする
- 純粋に大きさだけを表す
- 見積もりが早い（合意しやすい）
理想日のメリット
- プロジェクト関係者に説明しやすい
- 導入しやすい
ストーリー分割の例(ストーリーポイントで見積もり)
スクラム現場ガイドからそのまま引用
ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小機能がスクラム現場ガイドでは考え方の目安として語られている。
- 〜として、アカウントを管理できる
- 〜として、自分の注文を管理できる
- 〜として、設定を管理できる（これも分割できる）
- 名前、パスワード、メールアドレスを変更できる
- パスワードをリセットできる
- アドレス帳を管理できる
- アドレス帳にすでに存在する住所を編集できる
- コンフィグレーションファイルを更新できる
- 拡張DLLを更新できる
- アドレス帳から住所を削除できる
- 新しい住所をアドレス帳に追加できる
- メールの設定を変更できる
- 〜として、支払い方法を管理できる
- 登録済みの支払い方法を管理できる
- 登録済みのクレジットカードを変更、削除できる（これも変更・削除でまだ分割できる）
- クレジットカードを追加できる
- ギフトカードを管理できる
スプリントプランニング
【いつやるか】 スプリント開始する前に
【何をやるか】 スプリントを通して顧客に届ける価値を決め、それに沿うプロダクトバックログアイテムを選択し、作業計画を立てる
【誰がやるか】 スクラムチーム全員が強力して行う
【どのくらいやるか】 1週間スプリントでは1時間程度
ユーザーストーリーやバグ修正などのプロダクトバックログアイテムを作業アイテムにした上で具体的な時間で計画する。
作業時間の見積もりが大きくなったら作業タスクの分割を行う。
作業タスクの分割例(時間で見積もる)
スクラム現場ガイドからそのまま引用
- 拡張DLLを更新できる
上で小さく分割されたストーリーがある。これらを作業タスクに分割すると
- 拡張DLLを更新できる
- 顧客の受け入れテストを設計する (見積もり12h)
- エンドツーエンドの自動受け入れテストを書く (見積もり12h)
- ダイヤルアップ用のプロファイル検査をテストする (見積もり12h)
- 自動受け入れテストを実行する (見積もり6h)
実際に着手してみたら他にもやらなきゃいけないタスクが見つかる場合がある。そうしたら作業の手を止め、再度分割をする。- 顧客の受け入れテストを設計する(見積もり 12h)
- ブレインストーミングをして受け入れテストをドキュメント化する(2h)
- ステークホルダーと一緒に受け入れテストをレビューする(3h)
- 足らないテストをステークホルダーとブレインストーミングする(2h)
- チームで受け入れテストをレビューする(1h)
- 受け入れテストをテスト自動化フレームワークに組み込む(3h)
- 受け入れテスト用のデータを追加する(2h)
- プロファイラを設定して新しいテストに対応する(2h)
- 新しいテストをビルド用サーバに追加する(1h)
FAQ
ベロシティは何を集計するの？
集計するのはプロダクトバックログアイテムに対して付けたプロダクトバックログアイテムのサイズを集計する。（つまりストーリーポイントなどの規模見積もり値）
スプリントプランニングでのタスク分割は全員で行う？
推奨は「全員でやれ」になります。
最後に、スプリントのタスクにおけるアンチパターンを紹介します。
・スプリントプランニングのときにはすでに誰かが詳細化・分割したタスクが存在している（ときには何故か作業時間の見積りが入っていることすらある）
・プロダクトバックログアイテムがすでにタスクになっている
・テックリードや技術的に優秀な人が、スプリントプランニングのときに「みんなのため」（と称して）タスクを分解してあげる
・スプリントプランニングのときにプロダクトバックログが個人にアサインされ、担当する個々人がタスクに分解する
ポイント
- 基本的に平均的なスキルの開発者を基準にします。
- 1タスクの最大時間は1日くらいまでに抑えます。
- タスクにバッファを持たせない
所感
ここでどのくらいの粒度にするかどうかはチームで決めると良いと思っています。チームにジュニアが多い場合は、作業タスクはほとんど実装レベルまでの話まで落とし込むと、チームが成長し、チームの力を平均しやすくなります。
逆にある程度経験のあるエンジニアが揃っているチームの場合はそこまで詳細に作業タスク分割をする必要はないと感じています。共通認識を揃えるくらいが、一番落とし所としてはちょうどいいのかと思っています。
スプリントプランニングにとても時間がかかるのですが、どうしたら良いですか？
スプリント開始前にプロダクトバックログリファインメントが不十分である可能性があります。 スプリントで選択しそうなプロダクトバックログアイテムには、あまり大きな疑問点がない状態にしておくことをお勧めします。
ポイント
- プロダクトバックログアイテムを生煮えの状態でスプリントバックログに入れない
所感
生煮えの状態でスプリントバックログに入れてしまうと、大きな手戻りが発生します。それこそ、「このストーリーを今本当に対応する必要ある？」という状態に戻るときもあります。事前にプロダクトバックログリファインメントをチームで怠らず実施することで、より作業に集中することができるので、インクリメントを出しやすくなります。
作業タスクの実績値は取る？
いまいち文献を探していく中で実績について触れられているものは少なく、アジャイルメトリクスで多少触れられているだけでした。（実績の取り方くらい）
そこで先日発売の「これまでの仕事 これからの仕事」という書籍でこのような節がありました。
「予実のズレをなくすことが成果につながる」という世界観がマイクロマネジメントを生む
この節を見て、「ハッ」としました。作業タスクの見積もり時間も、「ただの計画」にすぎません。「計画通りすべてうまくいく」ならスクラムはやっていません。つまり、精密な予実管理はいらないのではないかと思いました。
かといって、データを無視してチームの改善に役立てないのとは話が違います。実績としてベロシティを見たり、コントロールチャートを見てリードタイム・サイクルタイムを見てチームで話しあうことによってカイゼンに繋げていくことが大切だと実感しました。
合わせて読んでね
最後に
はげみになりますので、ぜひいいね❤️をいただけると嬉しいです！
参考資料