ブログ

ryuzeeによるブログ記事。不定期更新
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それでは。

  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック