ガイド · 約1分で読めます

ストーリーポイントとは?実践ガイド

ストーリーポイントの意味、アジャイルチームが時間ではなくポイントで見積もる理由、研究で分かっていること、過剰な約束を避ける使い方を紹介します。

ストーリーポイントは、作業にかかる時間ではなく、複雑さ、不確実性、作業量を合わせて表す相対的な単位です。チームは「何時間かかるか」を予測する代わりに、項目同士を比較して「こちらはあちらの約2倍の作業量」と判断します。プランニングポーカーではフィボナッチのような尺度を使うことが一般的です。ここではポイントが表すもの、研究結果、過剰な約束を避けた使い方を説明します。

ストーリーポイントとは

ストーリーポイントが答えるのは絶対的な時間ではなく、比較の問いです。「何時間かかるか」ではなく、「よく知っている作業と比べてどのくらい大きいか」を考えます。小さいと合意したストーリーを2、少し大きいものを5、大きく曖昧なものを13とすることがあります。数値に固定の時間は割り当てられず、チームで共有する相対的な規模を示します。

抽象的な単位を使うと、特定の人の作業速度や締め切りの約束から見積もりを切り離せます。若手とベテランの開発者で所要時間が違っても、一方の作業がもう一方の約2倍だという点では合意できることがあります。

ストーリーポイントを構成する要素

1つの数値に3つの要素が含まれます。

  • 複雑さ:作業の難しさ、構成要素の数、影響するシステム。
  • 不確実性:チームがまだ知らないこと。未知の要素やリスクが多いほど数値は大きくなります。
  • 作業量:個々の作業は単純でも、繰り返しの量が多い場合のボリューム。

そのため、所要時間が同程度でも異なるポイントになることがあります。40個のファイルに及ぶ単純な変更と、1つのファイルにある難しいアルゴリズムは、異なる理由で「大きい」作業です。

時間ではなくポイントで見積もる理由

相対見積もりが使われる理由は、計算よりも人間に関するものです。

  • 担当者から見積もりを切り離す。 時間は誰が作業するかによって変わります。相対的な大きさは人による差が小さいことを目指します。
  • 比較は予測より速い。 具体的な時間を予測するより、項目同士の大小を判断する方が簡単です。
  • 偽の精度を避ける。 「13ポイント」は不確実性を正直に示します。「16.5時間」は根拠のない精度を装うことがあります。
  • 対話を促す。 一緒に見積もる本当の価値は数字ではなく、隠れた作業を見つける議論です。プランニングポーカーのセッションもご覧ください。

こうした利点はありますが、見落とされがちな点も正直に見ておく必要があります。

研究が示すこと

ストーリーポイントは時間見積もりより正確だという一般的な主張は、比較実験で十分に裏付けられていません。

ある統制実験では、専門の開発者が同じタスクをストーリーポイントと作業時間の2通りで見積もりました。ストーリーポイントの見積もりは時間見積もりより正確性が低く、作成にも時間がかかりました。経験豊富な開発者でも結果は同じでした。また、誰が見積もるかによってポイントの大きさが大きく変わり、担当者に左右されないという期待とは異なる結果も報告されています。

大規模な分析でも似た傾向があります。2022年の研究は37のオープンソースプロジェクトに含まれる実際のユーザーストーリー37,440件を分析し、チームのポイントと実際の作業時間を比較しました。ポイントと実作業の対応が良好だったのはプロジェクトの約7%だけでした。ほかでは関係が中程度または弱く、元の人による見積もりは約4件に3件で高すぎるか低すぎるものでした。より広範なレビューでも、ストーリーポイントは一般的な手法ではあるものの、工数を正確に予測するという確かな証拠はないとされています。

率直な結論として、ストーリーポイントは個々のタスクの所要時間を確実に予測する方法ではありません。項目ごとの精密な予測を期待すると、研究が示すとおり期待外れになるでしょう。

ストーリーポイントの適切な用途

正しい目的で使えば、さまざまな利点があります。

  • 共通理解を作る。 投票が分かれたとき、議論によって前提、未確認の作業、リスクが明らかになります。この認識合わせが主な成果です。
  • 複数項目の大まかな予測。 個別の見積もりには誤差がありますが、バックログ全体では誤差が相殺される場合があります。スプリントで完了したポイント数(ベロシティ)を追うと、時間を単純に合算するより実用的な概算になります。
  • リスクの高い項目を見つける。 13や21は、大きすぎるか不明点が多いことを示します。問題になる前に分割しましょう。
  • 見積もりを人間的に保つ。 相対評価は、時間見積もりで生じやすい締め切りの圧力や個人への責任追及を避けます。

これらの用途に、ポイントが実際の工数を正確に表す必要はありません。チームが話し合い、同じ基準で比較することが必要です。

ストーリーポイントで見積もる方法

  1. 尺度を選ぶ。 多くのチームはフィボナッチデッキ(0、1、2、3、5、8、13、21)を使います。数値間隔が広がり、大きな項目の不確実性を反映できます。
  2. 基準となるストーリーを決める。 内容がよく分かっている項目を基準(「これは3」)にし、ほかの項目を比較して見積もります。
  3. 一緒に見積もり、同時に公開する。 最初に出た数値に引きずられないよう、プランニングポーカーを使います。詳しくは手順ガイドをご覧ください。
  4. 理解が進んだら再見積もりする。 ポイントは現時点の理解を表すもので、契約ではありません。状況が変わったら更新します。

ポイントと時間の比較

項目ストーリーポイント(相対)時間(絶対)
測るもの複雑さ、不確実性、量を含む相対的な規模特定の所要時間
担当者による違い影響を受けないことを目指す影響を受ける
個別項目の予測根拠が弱い小さく既知のタスクなら一定の目安になる
チーム全体の予測複数項目のベロシティで可能合計を正確に予測しにくい
見積もりの速さ比較は速い予測には時間がかかる
主な価値共通理解と議論本当に必要な場合の具体的な数値

どちらも万能ではありません。関係者が実際の日付を必要とする場合、ポイントだけでは答えられません。ベロシティの傾向と話し合いを組み合わせれば、推測した時間を積み上げるより妥当な予測ができます。

よくある誤用

  • ポイントを時間に換算する。 「1ポイント=4時間」の表はポイントを使う理由を失わせ、偽の精度を持ち込みます。
  • チーム間でベロシティを比較する。 ポイントはチームごとに基準が違うため、Aチームの8とBチームの8は同じとは限りません。生産性ランキングに使うのはアンチパターンです。
  • ポイントを業績指標にする。 目標にした途端、ポイントが水増しされ意味を失います(グッドハートの法則)。
  • 個別項目の正確さを期待する。 研究が示すとおり、単一タスクのポイントは実際の時間を予測する力が弱いものです。1件ではなく複数項目で予測しましょう。
  • 再見積もりしない。 作業を理解する前の数値に固執せず、必要に応じて更新します。

よくある質問

ストーリーポイントは時間と同じですか?

いいえ。時間は特定の人に結びついた絶対的な長さです。ストーリーポイントは複雑さ、不確実性、作業量を組み合わせた相対的な大きさで、担当者によらないことを目指します。

1ポイントは何時間ですか?

決まった換算値はありません。換算表を作るとポイントを使う目的に反します。チームが後から時間との傾向に気づくことはありますが、見積もりのルールではありません。

どの尺度を使えばよいですか?

一般的なのはフィボナッチ(0、1、2、3、5、8、13、21)です。大きな項目ほど不確実性が増えることを表せます。大まかな見積もりにはTシャツサイズも使えます。

ストーリーポイントは正確ですか?

単一項目の工数予測については、証拠が弱い状態です。時間見積もりに対する明確な精度の優位性は統制実験で確認されず、大規模分析でも実工数との相関は一貫していません。価値は共通理解と複数項目の概算にあります。

チーム間でベロシティを比較できますか?

できません。ポイントはチーム内で調整されるため、チームごとのベロシティは比較できません。ランキングに使うとポイントの水増しを招きます。

誰がポイントを決めますか?

通常はプランニングポーカーで、作業するメンバーが一緒に決めます。プロダクトオーナーは範囲を説明しますが数値は決めず、スクラムマスターが進行します。

ポイントは工数と複雑さのどちらを測りますか?

両方に加え、不確実性と作業量も含みます。複数の要素を1つの相対数値にまとめるため、時間が同程度の作業でも異なるポイントになることがあります。

出典

  1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
  2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates?
  3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022.
  4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.

関連記事