ストーリーポイントとは何ですか？
アジャイル開発のためにここでストーリーポイントを使用し始めましたが、説明するのが難しく、それらが何であるかについての明確な答えも見つかりません。私ができる最善のことは、他のサイト（ http://blog.mountaingoatsoftware.com/tag/story-points など）をポイントして、それらの漠然とした一般化を与えることです。私は他の人が使用するのに役立つと思われる使用例を含む良い説明を探しています。ストーリーポイントを説明するための優れたリソースはありますか？
これはスターターとして役立つかもしれません： Mike Cohn on stories points 。しかし、これははるかに優れています： アジャイル開発チーム：Mike Cohnによるスコープとスケール
ソフトウェア推定指標に対するマイクのソリューションはシンプルで効果的です。生物学的事実：
- 人間の脳は時間を正確に見積もることができません。特に数時間以上の場合。
- これは、ソフトウェア開発者の不確実性の量、管理からの心理的プレッシャー（見積もるとき、コミットする...）、およびチームのスキルの違いによって大幅に増幅されます。
- しかし、私たちはものを比較するのはかなり得意です。私たちはそこにかなり正確です。
アイデアは、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、巨大、？）他のチームが（small（1）、medium（ 2）、large（3）、XLarge（4）で速度を計算したところ、まだ機能していました。）.
ポイントは、タスクのサイズが参照タスクに比べて大きくなると、コストを正確に見積もることができなくなることです。ですから、試しても意味がありません。これは、推定軌跡の終わりにある大きな勾配によって反映されます。
したがって、参照タスクが2SPの場合。次に、タスクのサイズが類似しているので、1/2/3/5の見積もりは比較的簡単です。参照タスク（5SP）の3倍を超えると、見積もりが難しくなります（8/9/10SPで問題ないでしょう）。5SPより大きく13SPより小さく、8SPで十分です。
SP 13/21/Hugeの値はすべて、スプリントバックログには大きすぎます。これらは、まだ実際に作業する準備が整っていない（したがって、小さなタスク（必要になるまで分割しないでください））ですが、製品のバックログにあるタスクのサイズの見積もりを提供します（これにより、将来の計画が可能になります）。スプリントバックログの小さなタスクに分割し、個別に再推定するための十分な知識が必要です（注：パーツの合計が元のパーツと等しいという一般的な誤解）。
- Hugeと推定するものはすべて、より小さなタスクに分解する必要があります。
- 推定されるものは何ですか？推定するには十分に定義されていないことを意味します
タスクを実行して定義するには、タスクを追加する必要があります
（つまり、ドキュメントまたはプレゼンテーションを作成します）。
それらは時間の無駄です。
http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/
この意見が興味深いのは、- Scrum and XP from the Trenches を書き、会社名が（Crisp）は、世界中の多くのチームで使用されている非常に多くの計画用ポーカーカードのデッキにあります。
OPの最後の文：「ストーリーポイントを説明するための優れたリソースはありますか？」はい、この本は良い情報源です。思考の糧。
ストーリーポイントは、タスクの難易度を相対的に測定したものです。これは、人間は正確な測定よりも相対的な推定が実際に優れているためです。
ストーリーポイントの使用方法は、プロジェクトで約2つのタスクを実行し、それらに2つの異なるストーリーポイント値を割り当てることです。次に、これらの2つのストーリーポイントの近似を推定の基礎として使用して、他のタスクを推定します。つまりタスクCはタスクAよりもはるかに難しくはありませんが、タスクBよりも非常に簡単なので、タスクAよりも約2ストーリーポイントだけ多くの作業が必要です。
これまでに持っているすべての要件の見積もりが完了したら、スプリントで実行できる要件の数を見積もります。次の数回のスプリントで、完了した数を見積もります。要件のストーリーポイントは、要件が満たされた場合にのみ完了としてカウントされます。スクラムには「80％完了」はありません。これは、人間が完全性の推定が実際に下手だからです。数回のスプリントの後、スプリントごとにいくつのストーリーポイントを実行できるかがわかるはずです。
どのように推定しますか？ planning poker を使用して、基本要件と比較して、要件が必要だと感じる開発者の作業量を決定できます。
The Agile Samurai もお勧めします。私の意見では、これらのアジャイルコンセプトや他のアジャイルコンセプトをうまく説明しています。
他の人が述べたように、ストーリーポイントはユーザーストーリーの複雑さの相対的な測定値です。ストーリーポイントの真のメリットは、
- ポイントは、実装を担当するユニット（個人またはチーム）によって測定されます。
- メトリックは、一定の期間（速度）内で同じユニットが完了した集約ポイントの数について保持されます。
ストーリーポイントの測定と速度の追跡を数回繰り返した後、特定のタイムブロック（スクラムを使用している場合は反復またはスプリント）内にいくつのストーリーポイントが収まるかを正確に推定できるはずです。この手法をグループに適用し、別のチームでこれらのメトリックを使用しようとすると、うまく機能しないことに注意してください。つまり、チームaが2週間のスプリントで120ストーリーポイントを完了することができる場合、チームbが同じ結果を期待するのは現実的ではありません。
他の誰かが述べたように、ポーカーを計画することは、この方法を使用する場合に非常に役立ちます。ポーカーを計画することは、さらに改良が必要なストーリーを特定するのに役立ちます（投票の間に不一致がある場合、要件に不確実性があることを意味します）。
私が思いつくことができる最も簡単な説明は、有形で具体的な例を提供できるオブジェクトを使用することです。
携帯を家に持ち帰ってください。モバイルホームビジネスの場合、シングルワイドの構築には通常5（ポイント、カエル、ウィジェット...測定フォームは任意）であることを知っているので、ダブルワイドの構築には約2倍の労力または10（ポイント、カエル、ウィジェット）。
プログラマの考え方は、この時点で始まり、合理化されたアプローチについて話します。インフラストラクチャが時間の大部分を消費しているため、2倍の時間がかかりません。これは避けられません。これは（ポイント、カエル、ウィジェット）での推定であるという事実に気をつけてください。時間内で正確に推定することはできません。
何かを構築するのにかかる時間を知るために、時間の経過に伴う傾向を利用します。したがって、時間の経過とともに、推定値はますます正確になります。
チームの準備ができたら planning poker を忘れないでください。