ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

プロダクトバックログアイテムとタスクの見積り

みなさんこんにちは。@ryuzeeです。

以前お客様先でスクラムのトレーニングを実施した際に、プロダクトバックログアイテムとタスクの見積りについて質問をいただきました。 見積りについてはもっとも質問をいただく項目の1つでもあるので、ここでスクラムにおける見積りについて書いておくことにします。

プロダクトバックログアイテムの見積り

まずはプロダクトバックログアイテムの見積りについて考えてみましょう。

なぜプロダクトバックログアイテムを見積もるのか?

なぜプロダクトバックログを見積もるかといえば以下の理由です。

  • そのプロダクトの全体を把握する。全体のサイズが分からないと現在の進捗が把握できません。もちろん全てのプロダクトバックログアイテムを絶対に作るかといえばそうではなく、途中でプロダクトバックログアイテムが追加されたり削除されたりしますが、それでも全体の概要を把握しようとすることには意味があります
  • 同じ理由で、スプリント単位でどれくらい完成できるかを把握するためにも見積りが必要です
  • 全体の見積りとスプリント単位での完成の実績がわかれば、指定した期日までにどれくらいが完了するのか、もしくは全てを完了するのにどれくらいの時間がかかるか推定できます。この推定はスプリントを繰り返せば繰り返すほど正確になっていきます
  • これらはすなわち事実に基づいて計画を更新できるようになることを意味します
  • また見積りがあれば、ビジネス価値と比較して規模が大きすぎるものは作らない判断をする、もしくはビジネス価値と比較して規模が小さいものは優先順位を上げるといった対応も可能になります。すなわち限られたリソースや期間の中で最大限の成果を出すための計画の精度があがります
  • なお、計画はたてることに意味があって、そのとおりにすすめることに意味があるとは限りません。したがって見積りにおいて過度な精度は不要で、おおよそのサイズがわかるだけでさまざまな判断の材料になります

プロダクトバックログアイテムの見積りのタイミング

これを踏まえるとおのずと見積もるタイミングは明らかです。見積りは以下のタイミングで実施するのがおすすめです。

  • 開発の初期で最初のプロダクトバックログの洗い出しがおおよそ終わったとき。ここでの見積りは全体の把握に使います
  • 最初のスプリントを始める前。最初のスプリントの開始前に少なくともそのスプリントで着手すべきプロダクトバックログアイテムが準備完了になっている必要があります(でないと大きな手戻りが発生するリスクが高くなります)。準備完了になった上位のプロダクトバックログアイテムは見積りをし直します。準備完了の状態であれば見積りの精度が向上するためです
  • 最初の数回のスプリントが終わった時。最初のスプリントは成果がでないことも多いので、何回かスプリントをこなしたあとで、残っているプロダクトバックログアイテムを見積り直します。その時点で開発チームは実際の開発を行った経験があるため、プロジェクト初期にくらべると見積りの精度は向上します
  • その後の定期的な見直し。もちろんプロダクトバックログアイテムは随時追加されるので、追加されたプロダクトバックログアイテムの順番が上位の場合は適宜見積りを行います。またプロダクトバックログアイテムを分割したりもするので、分割したプロダクトバックログアイテムの見積りや、全体の見直しを行います

言い換えると開発の期間中、未着手のプロダクトバックログアイテムについては、継続的に見積り直しが必要ということになります。 プロダクトバックログが更新されるづける成果物であるということは見積りも更新され続けるということなのです。 なお、完成したプロダクトバックログアイテムを見積りし直すことに意味はありません。

プロダクトバックログアイテムの見積りには何を使うか

スクラム自体ではどんな方法を使って見積もるかは定義していません。すなわち見積りの方法の選択肢としては以下のいずれも考えられます。

  • 物理単位付きの絶対見積り。例えば人日や人月、万円など
  • ポイントを使った相対見積り。よく使う方法にプランニングポーカーがある。プランニングポーカーでは、1・2・3・5・8・13などのフィボナッチ数列のカードを使って見積もる
  • Tシャツサイズ。プランニングポーカーを簡易にして、S(小さい)、M(中くらい)、L(大きい)、XL(かなり大きい)などのサイズに分類する
  • 見積もらない。全てのプロダクトバックログアイテムをだいたい同じ大きさに分割し、そもそもプロダクトバックログアイテムの個数をさまざまな計算に使う

このうち絶対見積りについては、外したときのインパクトが大きいこと、それを理由にして見積りが紛糾しやすいこと、数字がついているとその数字が外部に約束として扱われてしまうリスクが高くなることから避けておくのが無難です。また見積もらずに全てのプロダクトバックログアイテムを同じサイズに分割するのも経験が要求されるので難易度は高いでしょう。 ということで、プランニングポーカーによる相対見積りかTシャツサイズ見積りが初期のチームにはおすすめです。

スプリントバックログのタスクの見積り

次にスプリントバックログのタスクの見積りについて見てみましょう。

なぜスプリントバックログのタスクを見積もるのか

スプリントバックログのタスクを見積もる理由は以下の通りです。

  • スプリントプランニングではそのスプリントで着手するプロダクトバックログアイテムを選択して、それらを実行計画(つまりタスク)に分割するのが一般的です。それぞれのタスクを見積もることで、本当にそのスプリントで選択したプロダクトバックログアイテムが完成しそうなのかを予測できるようになります
  • すなわちタスクの合計時間が、開発チームがスプリントで使える時間を超過していた場合、たとえプロダクトバックログアイテムの見積りについては過去の結果から達成できそうであっても、現実的には難しい可能性があるということが分かります。このときはプロダクトオーナーと開発チームが相談して、なんらかのプロダクトバックログアイテムを諦める判断をすることになります
  • 毎日残り作業に必要な時間を追跡していくことで、スプリント終了までに予定したプロダクトバックログアイテムが完成しそうかどうかが分かります。すなわちバーンダウンチャートがかけるようになります
  • つまり、もしスプリントの途中でこのままいくと終わらないであろうことが判明した場合にすぐにプロダクトオーナーと調整が可能になります
  • また見積りをしておくことで、タスクに想定外の時間がかかっている場合に、開発チームとして速やかな対処(スウォーミングなど)も可能になります

スプリントバックログのタスクの見積りのタイミング

タスクは、選択したプロダクトバックログアイテムを完了させるための作業なので、スプリントプランニングで見積りを行います。 全てのプロダクトバックログアイテムを事前にタスクに分解する必要など決してありません。 必要になったタイミングで必要な分の計画を行えば十分です。 なぜなら、タスクの見積りは、そのスプリントの計画と追跡のためだけに使うからです。 またスプリント中には新たにタスクに気づいたり、タスクの実施によって他のタスクの難易度が変わることもあります。したがって必要に応じて日々見積りを更新します。

スプリントバックログのタスクの見積りには何を使うか

スクラムガイドで定義されているのは、残作業が追跡可能であるようにすべきという点だけです。 一般的には、ここでの見積りには時間を使うことが多いでしょう。 それはスプリントプランニングでキャパシティとの比較が容易になる点や、バーンダウンチャートによる追跡が容易になる点によるものです。 時間を使う場合、1タスクあたりの最大サイズは1日くらいの規模が望ましいでしょう。 そうすればデイリースクラムにおいて、昨日も今日も同じタスクに取り組んでいる場合異常が起こっている、と容易に理解できるためです。 もちろん成熟したチームであれば、タスクをなるべく同じサイズに揃えて、個数で管理するといったことも可能です。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 【新刊発売のお知らせ】ジョイ・インク 役職も部署もない全員主役のマネジメント
次の記事 【資料公開】スクラムの落とし穴

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World