1. ストーリーポイントとは何か？

ストーリーポイントはユーザーストーリー（プロダクトバックログ項目）を見積もるためにチームが使う架空の単位です。

2. ストーリーポイントは何を表すか？

ストーリーポイントはユーザーストーリーを実装するのに必要な作業量を表します。 アジャイルな人の中には、ストーリーポイントは複雑さの指標である、という人もいますが、ユーザーストーリーを実装するに際しての複雑度やリスクがその実装において考慮されている場合のみあてはまると言えます。

3. ストーリーポイントの見積りには何が含まれているのか？

ストーリーポイントの見積りには、そのストーリーを「完了」にするために必要なすべての作業が含まれているべきです。 ここでいう「完了」の定義（Definition of Done）は理想的には、ストーリーを実装するのに必要な開発作業とテストの双方が含まれているべきです。 ユーザーストーリーが実装された、ということは本番環境で利用可能ということであるべきなのです（テストが残っているべきではありません）。

4. 日にちや時間で見積もるのより何故ストーリーポイントの見積りが良いのか？

ストーリーポイントは既に見積もったストーリーをサンプルとして比較しながら相対的なサイズを算出することで行われます。 ストーリー間での相対的なサイジングは個々の独立したストーリーを個別に見積もるよりもより正確な結果となる傾向にあります。

たとえば、デリーからバンガロールまでの距離はムンバイからバンガロールの距離の2倍である、というのは、デリーからバンガロールの距離は2061kmであるというのに比べるとはるかに簡単です。

チームはそれゆえに個々のユーザーストーリーを完了させるのに必要な日時や時間を正確に算出するのに多くの時間をかけることなく、より簡単に見積りを行うことができるのです。

5. どうやってポイントで見積もるのか？

見積りをする一般的な方法は、ストーリーを1,2,4,8,16等に分類することです。 1,2,3,5,8といったフィボナッチ数列の値を使うことを好むチームもあります（訳注：フィボナッチであることの方が多いようです）。 見積り対象のストーリーを用意したら、チームは一番小さいと思うストーリーからサイジングを行います。

例えば、チームはユーザーがログインするストーリーを選択し、それを2ポイントとしました。 続いて、顧客の検索のストーリーを選択しましたが、それは先に見積もったログインストーリーの2倍くらいの作業量が必要だと考え4ポイントと見積もりました。 この作業は全てのストーリーに見積りが付与されるまで行います （訳注：全部を見積もる必要は必ずしもありません。優先順位の高いストーリーは必ず見積もられるべきですが、優先順位が低いストーリーは本当に実装するか分からないですし、ストーリーの要件が明確でないケースもあります）。

6. ストーリーポイントの見積りは誰がやるべきか？

ストーリーを「完了」にする責任をもつチーム自身が見積りを行います。 もしチームにストーリーをテストしたりテスト自動化を行うQAのメンバーがいる場合は、彼らもチームと一緒に見積りを行います。

QAは開発にはそんなにかからないとか、テストはもっとかかる等と言えるべきです。 例えば、チームは顧客検索の画面は4ストーリーポイントで2つの新しいブラウザへの対応は1ポイントだと考えましたが、QAとしてはテストにもっとかかるという意見を言うことができ、見積りに際してはQAはそれを反映した数字を出すことになります。

7. ストーリーポイントを時間や日数にどうやって変換するのか？

ストーリーポイントについては変換を行うべきではありません。 ストーリーポイントはベロシティと密接に関係しており、各イテレーションの最後にチームが完了したストーリーポイントの数でもってベロシティを測定します。

8. ポイントで見積もる場合に、うまくいく場合、まぁまぁの場合、うまくいかない場合のそれぞれのケースで見積もるべきですか？

うまくいった場合、まぁまぁの場合、うまくいかない場合の3通りの見積りをそれぞれのストーリーで行うこともありかもしれません。 これはまだコード量が少ないような初回リリースまでの間で大量のストーリーを見積もらなければならないようなケースでは効果があることもあります。

こうすることによって、チームが考えた想定事項次第で変化する見積りの範囲を明らかにできるでしょう。 例えば、ユーザーログインのストーリーにおけるベストケースはローカルのLDAPサーバと接続することで実装する案で2ポイントですが、想定が崩れてサードパーティ製の認証プロバイダを利用する場合は最悪で8ポイントになる、といった具合です。

9. ストーリーポイントを使ってどうスケジュールや計画をたてるのか？

ストーリーポイントをスケジュールに変換するためには、チームは自分たちのチームが1イテレーションあたりにデリバーできるストーリーポイント（これをベロシティと言います）を計算する必要があります。 過去3イテレーションの値の平均を「昨日の天気」として使うのが一般的です。

チームができたばっかりであれば、チームのベロシティは低いでしょう。 ベロシティが低い状況下においては、チームはスプリントの終了までにどれだけのストーリーを完了させられるか決めなければいけません。

例えば直近3つのスプリントの結果が6,8,10ストーリーポイント分達成していたとすれば、チームのベロシティは8ポイントとなります。 したがってスケジュールはチームが8ストーリーポイントを完了すると想定して算出します。

10. ストーリーポイントは様々なチーム間で共通化できるのか？

異なるチームでは彼らがサイジングしたサンプルストーリーに基づいた異なる尺度のストーリーポイントを利用しています（訳注：相対的な指標なので、チーム同士でストーリーポイント1の意味が違いますし、案件毎にも異なります）。 同じシステムを作っているのでない限り、チームAの1ストーリーポイント完了の作業量とチームBの1ストーリーポイントあたりの作業量は異なります。 そしてこの差は合計値であるベロシティにも現れます（したがって同一案件でない限りベロシティの単純比較も意味がありません）。

11. スパイク(技術的検証)ストーリーはどうやってポイントで見積もるのか？

スパイクストーリーとはチームが特定の機能を実装するに際してどうやったらより良い実装ができるか理解するために行う技術的検証です。 またこれは概念実証にも使われます。 スパイクにおいてはどのくらいの作業が必要かはあまり分からないことが多いので、一般的にはタイムボックスを定めます（時間で縛る）。 そして、これはベロシティの傾向をみることでおおよそのポイントに変換できます。 例えば、1週間の長さのスパイクを必要とし、チームのベロシティが16ポイントの場合、スパイクは8ポイントが割り当てられることになります。

12. 1ポイントあたりのコストを計算する方法はありますか？

1ポイントあたりのコストは一般的には「スプリントのコスト / スプリントにおけるベロシティ」で算出できる。

13. ストーリーポイントの見積りは日数や時間で正確に見積もれないことに言い訳じゃないの？

言い訳ではなく、ユーザーストーリーを日数や時間で正確に見積もることは現実的にムダです。

さらには、日数や時間での見積りはしばしばチームに対して想定した日数や時間でデリバリすることについてのプレッシャーをかけることになってしまい、間違ったコミットメントを達成するために燃え尽きてしまう結果になりかねません。 これではチームが持続的なペースを維持することができません。

14. ストーリーポイントはビジネス価値と関連しているか？

ストーリーポイントはユーザーストーリーを実現するにあたっての内部的な指標です。 したがって、ユーザーストーリーが生み出すビジネス価値については何ら反映しているものではありません。 1ストーリーポイントのストーリーが同じシステムの4ストーリーポイントのストーリーよりもビジネス価値があるかもしれないということです。 ビジネス価値はプロダクトオーナーやステークホルダーが決定できるようにしておくのが良いでしょう。

15. チームがよりうまく見積もれるようになったことはどうやって分かるか？

チームが理想日で見積もっていれば、見積りがよければトラッキングするのは簡単です。 しかし、チームがデリバリについて圧力をかけられない程度に安全な見積りをすることは生産的とは言えません。 チームが相対的なポイントで見積もっていれば、似たようなサイズのストーリーは似たような時間で実装されることが傾向として現れてきます。 もし悪い見積りであれば、自動的に例外として悪い見積りであることの証拠が現れるでしょう。