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

ここでストーリーポイントをアジャイル開発に使用し始めていますが、説明するのが難しく、またそれらが何であるかについての明確な答えも見つけることができません。私ができる最善のことは、他のサイト（http://blog.mountaingoatsoftware.com/tag/story-pointsなど）をポイントし、それらが何であるかについて漠然とした一般化を与えることです。私は、他の人が使用するのに役立ついくつかの使用例を含む良い説明を探しています。ストーリーポイントを説明するのに役立つリソースはありますか？

これはスターターとして役立つかもしれません：ストーリーポイントのマイクコーン。しかし、これははるかに優れています：アジャイル開発チーム：Mike Cohnのスコープとスケール

Mikeのソフトウェア推定メトリックに対するソリューションは、シンプルで効果的です。生物学的事実：

• 人間の脳は時間内に正しく推定することができません。特に数時間以上の場合。
• これは、ソフトウェア開発者の不確実性の量、経営陣からの心理的プレッシャー（推定するとき、コミットするとき）、およびチームのスキルの違いによって大きく増幅されます。
• ただし、比較するのはかなり上手です。そこでは非常に正確です。

アイデアは、1つの参照ユーザーストーリーを取得し、任意の数の（ストーリー）ポイントを与え、他のストーリーがその参照に関連するポイントを取得することです。

参照ストーリーが100ポイントで、別のストーリーが3倍大きい場合、300ポイントになります。

ストーリーポイントを計画の時間に変換するには、速度を知る必要があります。

正確な速度を得るには、数回の反復を行い、指定された時間内にチームが完了したポイント数を計算する必要があります。

動作します。

私は@Pierre 303のすべてに同意します：上記のとおり：（100の参照ポイントを除く）。

追加したい（強調）唯一のことは、タスクの見積もりが得意ではないということです。タスクがほぼ同じサイズである限り、他のタスクに関連するタスクを推定できます。タスク間の差が大きいほど悪化します。

したがって、100の開始点を使用することに同意しません。

次のタスクを参照タスクの42％と見積もるわけではありません。仕事の半分、仕事の2倍、仕事の3倍などです。

私たちのチームはPlaning Pokerを使用しています。これには、2つのストーリーポイントの参照タスクがあります。次に、フィボナッチ数列を使用してタスクを推定します：1,2,3,5,8,13,21、Huge ,? 参照タスクに関連して（フィボナッチではなく、他のチームが2の累乗を使用しているのを見たことがあります。1,2,4,8,16,32、Huge ,?） 2）、large（3）、XLarge（4）、速度を計算したとき、まだ機能していました。）

ポイントは、タスクのサイズが参照タスクに比べて大きくなると、そのコストを正確に推定することができなくなることです。だから、試しても意味はありません。これは、推定証跡の終わりのより大きな勾配に反映されます。

したがって、参照タスクが2SPの場合。タスクのサイズが似ているため、1/2/3/5の見積もりは比較的簡単です。参照タスク（5SP）の3倍を超えると、見積もりが難しくなります（8/9 / 10SPが問題になります）言うことができるのは、5SPより大きく13SPより小さい場合、8SPが収まります。

SP値が13/21 / Hugeの値は、スプリントバックログには大きすぎます。これらは、まだ実際に作業する準備ができていない（したがって、小さなタスクに分割されていない（必要になるまで分割しないでください）ものの推定値です。）ただし、製品バックログのタスクのサイズの見積もりは提供されます（これにより、将来の計画が可能になります）。それらに取り組む時点までに、スプリントバックログの小さなタスクに分割し、個別に再評価するための十分な知識が必要です（注：パーツはオリジナルと同じです）。

• 巨大であると推定するものはすべて、より小さなタスクに分解する必要があります。
• と推定されるものは何ですか？推定するには十分に定義されていないことを意味し
  ます。具体的にタスクを追加して、タスクを定義する必要があります
  （つまり、ドキュメントやプレゼンテーションを作成します）。

ストーリーポイントは、タスクの難易度を相対的に測定したものです。これは、人間は正確な測定よりも相対推定の方が実際に優れているためです。

ストーリーポイントの使用方法は、プロジェクトで約2つのタスクを実行し、2つの異なるストーリーポイント値を割り当てます。次に、これらの2つのストーリーポイントの近似を推定の基礎として使用して、他のタスクを推定します。つまり、タスクCはタスクAよりもそれほど難しくはありませんが、タスクBよりも信じられないほど簡単なので、タスクAよりも作業が2ストーリーポイントだけ多くなります。

これまでに必要なすべての要件の見積もりが完了したら、スプリントで何ができるかを見積もります。次の数回のスプリントで、完了した数を推定します。要件のストーリーポイントは、要件が満たされた場合にのみ完了としてカウントされます。スクラムには「80％完了」はありません。これは、人間が完全性を推定するのが実際には苦手だからです。数回のスプリントの後、スプリントごとにいくつのストーリーポイントを実行できるかを把握する必要があります。

どのように推定しますか？プランニングポーカーを使用して、開発者が基本要件に比べて要件にかかると感じる作業量を決定できます。

アジャイルサムライを読むこともお勧めします。私の意見では、これらおよびその他のアジャイルの概念を説明するのに適しています。

ストーリーポイントに関する詳細情報へのリンクを次に示します。

ここに別のリンクがあります。

時間の無駄です。

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

興味深いことに、この意見はトレンチからスクラムとXPを書いた人から来ており、その会社名（Crisp）は世界中の非常に多くのチームが使用する非常に多くのプランニングポーカーカードのデッキにあります。

OPの最後の文：「ストーリーポイントを説明するための優れたリソースはありますか？」はい、この本は良いリソースです。思考の糧。

私が思いつく最も簡単な説明は、具体的で具体的な例を提供できるオブジェクトを使用することです。

モバイルホームを取ります。私がモバイルホームビジネスにいた場合、単一のワイドを構築するのに通常5（ポイント、カエル、ウィジェット...測定フォームは任意）かかるので、ダブルワイドの構築には約2倍または10（ポイント、カエル、ウィジェット）。

プログラマーの考え方はこの時点で始まり、合理化されたアプローチについて話します。インフラストラクチャが最も多くの時間を費やしているため、2倍の時間がかかっていません。これは避けられません。これは（ポイント、カエル、ウィジェット）の推定であるという事実をハープします。これは、時間を正確に見積もることができないためです。

何かが構築されるのにどれくらい時間がかかるかを知るために、私たちは時間の経過とともにトレンドを利用します。したがって、時間の経過とともに見積もりがより正確になります。

チームの準備が整ったらポーカーを計画することを忘れないでください。

他の人が述べたように、ストーリーポイントはユーザーストーリーの複雑さの相対的な測定値です。ストーリーポイントの真のメリットは、次の場合に実現します

1. ポイントは、実装を担当するユニット（個人またはチーム）によって測定されます。
2. 一定の期間（速度）内に同じユニットによって完了した集約ポイントの数のメトリックが保持されます。

ストーリーポイントの測定と速度の追跡を数回繰り返した後、特定のタイムブロック（スクラムを使用する場合は反復またはスプリント）に収まるストーリーポイントの数を正確に推定できるはずです。この手法をグループに適用し、それらのメトリックを別のチームに使用しようとするとうまく機能しないことに注意してください。これは、チームaが2週間のスプリントで120ストーリーポイントを完了することができる場合、チームbが同じ結果を得ると期待するのは非現実的です。

他の誰かが言ったように、ポーカーを計画することは、この方法を使用する際の大きな助けとなります。