スクラムのストーリーポイント：意味と見積り方法

ストーリーポイントとは何ですか？

ストーリーポイント は、アジャイルやスクラムのチームが、プロダクトバックログアイテムが他のアイテムと比べてどれくらいの大きさかを表すために使う相対見積りの単位です。ストーリーポイントの見積りは作業量、複雑さ、リスクや不確実性をまとめたもので、5ポイントのアイテムは2ポイントのアイテムのおよそ2.5倍の大きさです。

キーワードは 相対です。人は何かに何時間かかるかを言い当てるのは苦手ですが、「これはあれの約2倍の大きさだ」と言うのはかなり得意です。ストーリーポイントはこの強みを活かします。数値それ自体には意味がなく、同じチームが見積もった他のアイテムと比較して初めて意味を持ちます。

ストーリーポイントの見積りは通常、3つのことを反映しています：

• 作業量。 やるべきことの量：画面、レコード、テスト、文書、ページなど。
• 複雑さ。 作業を考え抜くことの難しさ：込み入ったロジック、多数の連携、なじみのない技術など。
• 不確実性とリスク。 チームがまだ知らないことの多さ：不明確な要件、他者への依存、検証されていない前提など。

ストーリーポイントはビジネス価値を測るもの 含みません ではなく（それはプロダクトオーナーがバックログを順序付けるときの仕事です）、時間を偽装した単位でもありません。引っ越しトラックに積む家具の大きさを測るようなものだと考えてください。正確な寸法を知らなくても、洋服だんすが椅子のおよそ3倍の大きさだとわかります。

この名前は次に由来します： ユーザーストーリー（多くのチームがバックログアイテムに使う「…として、…したい。それは…のためだ」という短い形式）。ただし、ストーリー形式で書かれているかどうかに関係なく、どのプロダクトバックログアイテムにもポイントを付けられます。

ストーリーポイントはスクラムの一部ですか？

いいえ。スクラムガイド（2020年版。現在も公式の最新版）は、作業を行う開発者がプロダクトバックログアイテムの規模の見積りに責任を持ち、プロダクトオーナーがトレードオフの理解を助けてもよいとしています。規模の見積り方は述べていません。ストーリーポイントは、ユーザーストーリーと同様に、多くのスクラムチームが追加することを選んでいる補完的なプラクティスです。

ストーリーポイントは、1990年代後半から2000年代初頭のエクストリームプログラミング（XP）から生まれました。XPの創始者の1人であるロン・ジェフリーズによると、チームは当初「理想日」（ペアが中断なしで作業した場合にかかる日数）で見積もり、それに負荷係数を掛けて暦日を求めていました。ステークホルダーが理想日をわかりにくいと感じたため、チームはそれを「ポイント」と呼ぶようになりました。2019年の記事でジェフリーズは、自分がその名前を提案したかもしれず、ポイントがよく誤用されていることを「今は申し訳なく思っている」と書く一方で、ポイントに価値を見いだしているチームは使い続ければよいとも述べています。

この経緯は、以下で扱うストーリーポイントの強みと批判の両方を説明しています。スクラム全体がどう組み合わさるかについては、こちらをご覧ください： スクラムとは.

スクラムチームがストーリーポイントを使う理由

うまく使えば、ストーリーポイントはいくつかの点でチームの役に立ちます：

• 見積りが速い。 数か月先の作業について1時間単位のタスクリストを積み上げるより、アイテム同士を比較する方が速く済みます。
• 共通の理解。 見積りの違いが、前提の違いを浮かび上がらせます。その後の話し合いの方が、数値そのものより役立つことがよくあります。
• 不確実性が組み込まれている。 リスクの高いアイテムに大きな数値が付けば、準備完了にする前に分割やスパイクが必要だというサインになります。
• スキルに左右されない。 上級の開発者と若手の開発者ではかかる時間が大きく異なるかもしれませんが、あるアイテムが別のアイテムの約2倍の大きさだという点では合意できます。
• より良い予測。 スプリントごとに完了したポイントからベロシティが得られ、スプリントプランニングとリリースの予測がより現実的になります。
• バックログの判断が早まる。 大まかな規模は、プロダクトオーナーが次を順序付けるときに、コストと価値を比較検討するのに役立ちます： プロダクトバックログ.

ストーリーポイントが最もうまく機能するのは、安定していて、似た種類のアイテムに取り組み、スプリントで計画するチームです。すでに作業を小さく似たアイテムに分割しているチームでは、単に数えればよいため、ストーリーポイントの付加価値は小さくなります。

ストーリーポイントと時間の違い

ポイントを時間に換算できるでしょうか？確実にはできません。アジャイルの見積りについて幅広く執筆しているMountain Goat Softwareのマイク・コーンは、各ポイントの値は固定された数ではなく、時間の 範囲 に対応し、その範囲は人によって異なると主張しています。3ポイントのアイテムは、上級の開発者なら半日、新人なら2日かかるかもしれませんが、それでも両者は3だと合意できます。「1ポイント = 4時間」と固定すると、ポイントは手間を1つ増やして時間に戻るだけです。

だからといって時間が役に立たないわけではありません。多くのチームはバックログアイテムの規模をポイントで見積もり、スプリントプランニングで選んだアイテムを数時間のタスクに分解して作業を計画します。組織が予算のために工数の数値を必要とする場合は、当サイトのガイド 工数見積り で時間ベースのテクニックを扱っています。

ストーリーポイントのスケール

ほとんどのチームは、数値の間隔が広がっていくスケールを使います。この間隔は大きなアイテムほど不確実性が高いことを反映しており、6か7かといった違いでチームが議論するのを防ぎます。

プランニングポーカーのデッキには特別なカードが加わることがよくあります： 0 はごく小さな作業、 ? は「まだ見積もれない」、コーヒーカップは「休憩しよう」を表します。 ? は通常、誰かが見積もる前にそのアイテムのリファインメントやスパイクが必要だという意味です。

基準表の例

スケールはチームごとに固有のものですが、数値が自分たちにとって何を意味するかを書き出しておくと、新しいメンバーの助けになり、見積りの一貫性が保たれます。ウェブプロダクトのチームの例です：

ストーリーポイントの見積り方（ステップごとに解説）

スクラムチームにストーリーポイントを導入する実践的な方法を紹介します。手順1～3は一度きりの準備で、手順4～8は日常的な作業になります。

1. 基準ストーリーを選ぶ。 最近完了したアイテムのうち、全員が覚えていて、小さすぎも大きすぎもせず、おおむね想定どおりに進んだものを選びます。それに値を付けます。多くは2か3です。
2. 基準をあと1～2つ追加する。 明らかに小さいアイテム（1）と明らかに大きいアイテム（5や8）があると、比較しやすくなります。これらが合わせてベースラインになります。
3. スケールとルールに合意する。 フィボナッチに似たスケールを選び、1スプリントで許容する最大サイズを決め、バグとスパイクの扱い方に合意します。
4. 見積もる前にリファインメントする。 なお、 バックログリファインメントでは、プロダクトオーナーが各アイテムを説明し、チームが受入基準を明確にします。不明確なアイテムを見積もるのは時間の無駄です。
5. 一緒に見積もる。 各開発者がアイテムを基準ストーリーと比較して考えをまとめ、全員が同時に公開します。たとえばプランニングポーカーを使います。
6. 平均を取るのではなく、違いについて話し合う。 見積りが2から8までばらついたら、最も高い人と最も低い人が理由を説明します。多くの場合、1人が他の人の知らないことを知っています。再投票し、近づいたらすぐに決めましょう。
7. 大きすぎるものは分割する。 アイテムが合意した最大値を超えたら、スプリントに入る前に、価値を保ったまま小さく分割します。当サイトのガイド エピック、ストーリー、タスク で方法を紹介しています。
8. 記録して見直す。 見積りをアイテムに記載します。数スプリントごとにレトロスペクティブで振り返りましょう。5とした複数のアイテムは本当に同じくらいに感じるか？過去の見積りではなく、基準となる例を調整します。

スクラムにおけるプランニングポーカー

プランニングポーカーは、ストーリーポイントに合意する最も一般的な方法です。速く、全員に発言の機会があり、最初に口にされた数値に引きずられるのを防げます。

1. プロダクトオーナーがアイテムを読み上げ、質問に答えます。
2. 各開発者がスケールからカードを1枚、他の人に見せずに選びます。
3. 全員が同時に公開します。
4. カードが近ければ、最も多い値を採用するか、数値に合意して次に進みます。
5. 大きくばらついたら、最も高い見積りと最も低い見積りを出した人が考えを説明し、チームは再投票します。

スクラムでは、 開発者 が投票します。プロダクトオーナーはアイテムを説明し、スクラムマスターはファシリテートしますが、自らも作業を行うのでない限り、どちらもカードを出しません。リモートチームは、シンプルなオンラインのプランニングポーカーツールや、プロジェクト管理ソフトウェアの見積り機能を使えます。

アフィニティ見積り、バケットシステム、Tシャツサイズ見積りなどの他のテクニックについては、当サイトのガイドをご覧ください： アジャイルの見積りとフィボナッチスケール.

具体例：バックログを見積もる

オンライン予約システムを構築しているチームは、 「顧客が確認メールから予約をキャンセルできる」= 3ポイント を基準ストーリーとしています。リファインメントで、次のアイテムを次のように見積もります：

13ポイントの手付金のアイテムは、1スプリントで確実に完了させるには大きすぎるため、チームはそれを「カードで手付金を支払う（正常系）」「キャンセル時に手付金を返金する」、そして決済プロバイダーのテスト環境に関する短いスパイクに分割します。SMSのアイテムが8になったのは主に不確実性のためで、チームが一度SMSサービスを使えば、同様のアイテムはおそらく小さくなるでしょう。

チームが一度も時間に触れていないことに注目してください。どの数値も3ポイントの基準との比較です。

誰がいつストーリーポイントを見積もるか

見積りのほとんどは次の中で行われます： バックログリファインメント。これにより、バックログの上位のアイテムは、次が始まるときにはすでに規模が見積もられています： スプリントプランニング 。理解が大きく変わった場合は、チームはプランニングで見積り直すこともあります。スプリントが始まったら、ほとんどのチームは見積りをそのままにし、差があればレトロスペクティブで学びます。

見積もるのは数スプリント先までにしましょう。バックログの下位のアイテムは変わる可能性が高いので、大まかなTシャツサイズを付けておき、近づいてきたらきちんとポイントを付けます。

ストーリーポイントからスプリントプランニングと予測へ

ストーリーポイントは合計したときに役立ちます。スプリントで 完全に完了 したアイテムの合計ポイントが、チームの ベロシティです。完了していないアイテムは、どれほど完了に近くても0点です。これがベロシティを正直に保ちます。

スプリントプランニングでベロシティを使う

あるチームの直近3スプリントの実績が28、33、30ポイントだったとします。平均ベロシティは約 30ポイントです。次のスプリントでは、開発者6人のうち1人が2週間ずっと休暇を取るため、チームは通常のキャパシティの約6分の5を見込みます。つまり約 25ポイントです。スプリントプランニングでは、一貫したスプリントゴールに沿う約25ポイントに達するまでバックログの上位からアイテムを取り込み、そこで止めます。

これは目安であってノルマではありません。どれだけ引き受けられるかを決めるのは引き続き開発者であり、合計を達成することよりもスプリントゴールの方が重要です。当サイトのガイド アジャイルのキャパシティプランニング では、休暇やその他の業務の考慮の仕方を説明しています。

リリースを予測する

リリースまでに見積り済みの作業が150ポイント残っていて、ベロシティが25～33の範囲だった場合、リリースには次がかかる可能性が高いでしょう： 5～6スプリント （150 ÷ 33 ≈ 4.5、150 ÷ 25 = 6）。必ず範囲で示し、ベロシティとバックログの変化に合わせてスプリントごとに更新しましょう。 ベロシティチャート を使えば、傾向を簡単に示せます。

バグ、スパイク、未完了の作業

チームによって扱い方は異なります。大切なのは、ルールを決めて一貫して適用し、ベロシティをスプリント間で比較できる状態に保つことです。

• 現在のスプリントの作業で見つかったバグ は、そのアイテムを完了させることの一部です。別にポイントを付けないでください。バグが修正されるまでアイテムは完了ではありません。
• 過去の作業や本番環境で見つかったバグ は新しいプロダクトバックログアイテムです。多くのチームは、労力がベロシティに表れるよう他のアイテムと同じようにポイントを付けますが、ポイントを付けない小さな枠を確保しておくチームもあります。一貫していればどちらでも構いません。
• スパイク （不確実性を減らすためのタイムボックス化された調査）は通常、ポイントを付けずにタイムボックス化するか、小さな固定値を与えます。そのアウトプットは、チームが本来のアイテムを見積もれるようにする知識です。
• 技術的負債 の作業は、バックログの中で公平に優先順位を競えるよう、機能と同じようにポイントを付けられます。参考： スクラムにおける技術的負債.
• 未完了のアイテム はプロダクトバックログに戻ります。ポイントをスプリント間で分けないでください。残作業が変わっていれば見積り直し、完了したときに数えます。

ストーリーポイントでよくある間違い

ベロシティは、いくつかある有用な指標の1つです。

ストーリーポイントへの批判と代替手段

ストーリーポイントには、それを広めた人の一部を含め、批判者もいます。よくある懸念は、チームが数値の議論に時間をかけすぎる、マネージャーがベロシティを生産性のスコアとして扱う、ポイントが見せかけの精度を与える、といったものです。これらの多くは誤用の問題ですが、現実の問題でもあります。

ストーリーポイントがチームの役に立っていないなら、次の代替手段を検討しましょう：

• アイテムを数える。 チームが作業をおおむね同じくらいの大きさの小さなアイテムに分割しているなら、スプリントごとに完了したアイテム数を数えるだけで、見積り会議なしにポイントと同じくらい正確に予測できることがよくあります。
• スループットと確率的予測。 過去の スループット と モンテカルロ・シミュレーション を使って、「3月14日までに完了する可能性85%」のような信頼度付きの予測を出します。
• Tシャツサイズ見積り。 ロードマップやエピックレベルの判断には、S／M／Lの大まかなサイズで十分です。
• #NoEstimates。 詳細な見積りそのものに疑問を投げかけ、作業を小さく切り分けてフローから予測することに重点を置く運動です。参考： かんばんの計画 （フローベースのチームの計画方法について）。

どの方法を使うにしても、スクラムガイドの要件は変わりません。開発者が、スプリントの計画に役立ち、プロダクトオーナーの判断に役立つ方法で作業の規模を見積もることです。

ストーリーポイントのテンプレートとツール

• スプリント計画テンプレート：スプリントゴール、キャパシティ、ストーリーポイント付きの選択したアイテム、担当者、タスク。
• ユーザーストーリーのテンプレート：ストーリー、受入基準、エピック、見積りを1か所に。
• プロダクトバックログテンプレート：価値と見積りの列がある順序付きバックログ。

ほとんどのスクラムツールには、見積りのフィールドとベロシティのレポートがあります。 Jira はスクラムボードとレポートにストーリーポイントの見積り機能を組み込んでおり、それがソフトウェアチームに人気がある理由です。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問