ストーリーポイントの見積もり方｜基準表とプランニングポーカー手順

ストーリーポイントとは、バックログ項目の大きさを「基準にした項目の何倍か」で表す相対的な見積もりの単位です。 時間や人日ではなく、複雑さ・不確実性・作業量をまとめて1つの数にします。

この記事では、チームでそのまま使える基準表、基準ストーリーの決め方、プランニングポーカーの進行台本、ベロシティを使った予測の計算（Pythonの出力つき）を示します。題材は架空の会議室予約アプリです。

確認環境：Ubuntu 24.04、Python 3.11（ベロシティの予測計算を実行）。スクラムガイド2020（scrumguides.org）を今回開いて確認したところ、ストーリーポイント・ベロシティ・プランニングポーカーという語は載っていません。ガイドが定めているのは「作業をする開発者が大きさを決める」ことで、この記事の内容はその上でよく使われるやり方です。

ストーリーポイントの早見表

ポイントの基準表（1・2・3・5・8・13）

3つの観点のうち、いちばん大きく当てはまる行を選びます。複雑さは2相当でも、不確実性が5相当なら5です。

タブ区切りです。例の列を自分たちのプロダクトの項目に書き換えて使います。

ポイント    複雑さ 不確実性    作業量 自分たちの例
1   変更は1か所。判断の分かれ目がない   やることが全部わかっている   文言・設定値の変更程度 
2   既存の処理に1つ足す  似た作業をしたことがある    画面か処理のどちらか1つ    
3   画面と処理の両方に手が入る。条件分岐が少し   不明点は質問1〜2回で解ける  画面1つ＋処理1つ＋テスト   
5   条件分岐が複数。ほかの機能と関わる   進めながら決めることが1つある 画面2つ前後、または処理が複数 
8   複数の機能にまたがる。データの持ち方に手が入る 初めて使う仕組みが1つある   画面・処理・データのすべて   
13  全体の設計に影響する  やってみないとわからない点が複数ある  1スプリントの大半を使う    

ポイントには、実装だけでなく完成の定義を満たすまでの作業すべて（テスト、レビュー、ドキュメントの更新など）を含めます。

基準ストーリーの決め方（記入例つき）

基準表の言葉だけでは人によって受け取り方がずれます。全員が中身を知っている項目を「これが3」と決めて、ものさしにします。

1. 完成済み、または内容がよくわかっている項目を5〜8件選ぶ
2. 小さい順に左から並べる（数字はまだ付けない）
3. 真ん中あたりの、全員が作業を思い描ける項目を「3」にする
4. その半分くらいを「1〜2」、2倍弱を「5」、3倍弱を「8」と置いていく
5. 各ポイントに1件ずつ基準ストーリーを決め、表に残す

記入例です。

基準ストーリーは、ベロシティが落ち着くまで入れ替えないのがこつです。ものさしが変わると、過去のベロシティと比べられなくなります。

プランニングポーカーの手順と進行台本

プランニングポーカーは、全員が同時に数字を出して、差が出たところを話し合う見積もりの進め方です。先に出た数字に引っ張られるのを防げます。

オンラインでは、チャット欄に数字を入力しておき、合図で同時に送信すれば同じことができます。

進行台本：PB-07「予約の時刻を変更する」

登場するのは、進行役（スクラムマスター）、プロダクトオーナー（PO）、開発者A・B・C・Dです。

ラウンド1

• 進行役「次はPB-07です。POから説明をお願いします」
• PO「予約済みの会議の時刻を変更できるようにします。受け入れ基準は、空いている枠へ変更できること、埋まっている枠は選べないことの2つです」
• 開発者B「部屋の変更も含みますか」
• PO「今回は時刻だけです。部屋の変更は別の項目にします」
• 進行役「ほかに質問がなければ、カードを選んでください。……せーの」
• （A：3、B：5、C：5、D：8）
• 進行役「3と8に分かれました。まずDさん、8の理由を教えてください」
• 開発者D「変更の確定と同時に、ほかの人が同じ枠を取る場合があります。重複を防ぐ仕組みに手を入れると見ました」
• 進行役「Aさん、3の理由はどうでしょう」
• 開発者A「取り消しと新規予約を続けて呼べば済むと考えました。基準の『予約を取り消す』とあまり変わらない印象です」

ラウンド2

• 開発者C「重複を防ぐ処理は、予約の確定で使っているものをそのまま呼べます。新しく作るのは変更画面と、埋まっている枠を選べなくする表示です」
• 開発者D「それなら8ではないですね」
• 開発者A「取り消してから予約する方式だと、途中で止まったときに予約が消えます。1つの処理にまとめる分、3より大きいです」
• 進行役「では、もう一度お願いします。……せーの」
• （A：5、B：5、C：5、D：5）
• 進行役「5でそろいました。Cさんの話した前提を、項目のメモに残しておきます」

そろわない場合のラウンド3

• 進行役「5と8に分かれたままです。違いはどこにありそうですか」
• 開発者D「通知メールの差し替えが入るかどうかです」
• PO「通知は別の項目（PB-08）で扱うので、ここには含めません」
• 進行役「範囲がはっきりしました。もう一度出して、それでも分かれたら大きいほうにします」

台本のとおり、数字の差は、前提や範囲の受け取り方の差であることがほとんどです。差が出たら、まず「何を含めて考えたか」を聞きます。

時間見積もりとの違い（比較表）

両方を使い分けるチームも多くあります。項目はポイントで、スプリントに取り込んだあとのタスクは時間で見積もると、見通しと日々の計画の両方が持てます。

ベロシティから完了までのスプリント数を予測する（Python）

ベロシティは、1スプリントで完成した項目のポイントの合計です。途中まで進んだ項目は0として数えます。1つの平均値ではなく、範囲で予測します。

# velocity_forecast.py  ベロシティの平均と範囲から、残りを終えるスプリント数を予測する
import math
import statistics

velocities = [21, 18, 25, 19, 23, 20]   # 直近6スプリントで完成したポイント
remaining = 160                         # 並べ終えたバックログの残りポイント
sprint_weeks = 2

avg = statistics.mean(velocities)
sd = statistics.stdev(velocities)
low3 = statistics.mean(sorted(velocities)[:3])    # 少なかった3回の平均
high3 = statistics.mean(sorted(velocities)[-3:])  # 多かった3回の平均
recent3 = statistics.mean(velocities[-3:])

print(f"平均 {avg:.1f} / 最小 {min(velocities)} / 最大 {max(velocities)} / 標準偏差 {sd:.1f}")
print(f"直近3回の平均 {recent3:.1f}")
print()
print("見方              ベロシティ  スプリント数  週数")
for label, v in (("慎重（下位3回の平均）", low3), ("標準（6回の平均）", avg), ("順調（上位3回の平均）", high3)):
    n = math.ceil(remaining / v)
    print(f"{label:<14} {v:>6.1f} {n:>10} {n * sprint_weeks:>8}")

print()
print("残りポイントが増えた場合（標準のベロシティで計算）")
for extra in (0, 10, 20, 30):
    n = math.ceil((remaining + extra) / avg)
    print(f"  残り {remaining + extra:>3} ポイント → {n} スプリント")

実行結果です。

平均 21.0 / 最小 18 / 最大 25 / 標準偏差 2.6
直近3回の平均 20.7

見方              ベロシティ  スプリント数  週数
慎重（下位3回の平均）      19.0          9       18
標準（6回の平均）        21.0          8       16
順調（上位3回の平均）      23.0          7       14

残りポイントが増えた場合（標準のベロシティで計算）
  残り 160 ポイント → 8 スプリント
  残り 170 ポイント → 9 スプリント
  残り 180 ポイント → 9 スプリント
  残り 190 ポイント → 10 スプリント

読み方は次のとおりです。

• 残り160ポイントは、7〜9スプリント（14〜18週）で終わる見込みです。関係者には「8スプリント前後、遅くとも9」と範囲で伝えます。
• 残りが10ポイント増えると、標準の見方で8から9スプリントに変わります。項目の追加が見通しにどう響くかを、同じ計算ですぐ示せます。
• 直近3回の平均（20.7）は全体の平均（21.0）とほぼ同じで、ベロシティは落ち着いています。差が大きいときは、直近の値を優先します。
• 最初の3スプリントほどはベロシティが揺れます。その間は範囲を広めに取ります。

避けたい使い方と、代わりのやり方

よくある質問

Q. なぜフィボナッチ数列を使うのですか？ A. 数が大きいほど間隔が広がるからです。大きな項目ほど見立ての幅も大きいので、「6か7か」のような細かい議論を省けます。1・2・4・8のような倍々の数や、S・M・LのTシャツサイズでも、相対で比べるという考え方は同じです。

Q. 新しいチームで、ベロシティがまだありません。どう計画しますか？ A. 最初のスプリントは、開発者が「これなら完成できる」と見立てた量を取り込みます。2〜3スプリント続けると、平均と範囲が使えるようになります。

Q. 0や0.5、20や40のカードは使いますか？ A. 市販のカードには入っていることがあります。この記事の基準表では、扱いを単純にするため1〜13の6段階にしています。13を超える項目は、数字を付けるより先に分割します。

Q. メンバーが入れ替わったら、ポイントは付け直しますか？ A. 付け直しません。ポイントは項目の大きさなので変わらず、変わるのはベロシティです。次の数スプリントのベロシティを見て、見通しを更新します。

まとめ

• ストーリーポイントは、基準ストーリーとの比で表す相対的な大きさです。
• 1・2・3・5・8・13の基準表を作り、複雑さ・不確実性・作業量のいちばん大きい行で決めます。
• 各ポイントに基準ストーリーを1件ずつ決めて、ものさしを固定します。
• プランニングポーカーでは同時に出し、最大と最小の理由を聞きます。差の多くは前提の違いです。
• 見通しはベロシティの範囲で出します。例では残り160ポイントが7〜9スプリントでした。
• 時間への固定換算、個人の評価、チーム間の比較には使いません。

参考

• スクラムガイド2020（Ken Schwaber、Jeff Sutherland）: https://scrumguides.org/scrum-guide.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。