ストーリーの推定についての私の理解では、法律の「合理的な傍観者」の概念に少し似た、想像上の平均的な開発者の場合のように、ストーリーのサイズを推定する必要があります。つまり、ストーリーのサイズを推定するべきではありません。
例を挙げると、以前の仕事で、私はチームの一部であり、最も自信のあるRuby開発者でした。私のチームメイトは、「XがRubyでどのように機能するかわからないので、何年もかかるだろう」というような議論をして、Ruby関連のストーリーを私よりはるかに大きく見積もっています。
これに対する私の議論は、スプリント計画がチームの能力の出番であるという事実から来ています。これが正しいフォーラムです。「タスクの大半はRubyベースであり、強力なRuby開発者は1人しかいないため、このスプリントの能力は通常よりもわずかに低くなります。」推定中にこれを考慮すると、この側面が倍になります。
回答に権威ある参考文献があれば感謝しますが、単純な意見も素晴らしいでしょう。
回答:
ストーリーポイントは相対的な推定値です。したがって、2倍のポイントは2倍の努力レベルを意味します。相対的な見積もりは、スキルレベルの変動の影響を受けにくくなっています。問題は、1ポイントにどれだけの時間をかけるかということではありませんが、2ポイントは2倍の潜在的な努力を必要とします。個々の生産性レベルを想定しているため、ストーリーポイントの代わりに理想的な日をとる場合、スキルレベルはより重要になる可能性があります。
相対推定値はより堅牢です。さらに、ストーリーポイントの評価は個人が行うべきではなく、チームによる共同作業の結果として行われるべきです。それほど複雑ではないストーリーについては、通常、迅速な合意があります。より困難なストーリーの場合、チームはほとんどのメンバーが同意する結果を得るため、チームの集合的なスキルレベルを暗黙的に考慮します。
最後に、ストーリーの評価は、チーム内の割り当てが必ずしもまだ決定されていない瞬間に実行されます。これは、個々のスキルレベルを考慮しないもう1つの議論です。スプリントプランニングでは、チームのストーリーポイントキャパシティを使用します。これは、実際のパフォーマンス数値に基づいて進化する数値であり、チームのグローバルスキルレベルに自己調整します。
結論として、個々の能力は推定のために考慮されるべきではありません。しかし、たとえ集団的推定と相対アプローチの堅牢性のためにそれが行われたとしても、それはそれほど重要ではないでしょう。
標準的な答えは、開発者ごとに見積もりを変更すべきではないということです。これは、スプリントごとに同業他社よりも多くのポイントを獲得することを意味し、ポイントは開発者ではなくチームの速度を測定するので問題ありません。ビジネスでは、チームがどの程度の成果を上げて配達の大まかな予想を得ることができるかを見積もることができ、すべてが素晴らしいです。
しかし、それは実際にはあらゆる種類のトラブルを引き起こします。その週に休暇を取っている場合はどうなりますか？レビューの時間が来て、平均給与の110％に対して平均ストーリーポイントの200％を生み出していることに気付いた場合はどうなりますか？チームの速度を人で割ったものが実際に正確な近似であるとビジネスが考え始めると、どうなりますか？同僚よりもはるかに多くのバグを作成していることにビジネスが気付いたとき（あなたはより多くの機能を作成していることを無視しながら）、どうなりますか？人々がそのような様々な咬傷を持っているとき、「咬傷サイズの」物語を構成するものは何ですか？
私のキャリアを通じて見つけたのは、それは大したことではないということです。プロセスはあなたに奉仕するためのものであり、その逆ではありません。組織で開発者が過負荷になっているかどうかを判断する必要がある場合は、開発者ごとのストーリーポイントが適切なソリューションです。組織でチームの速度を測定する必要がある場合、開発者にとらわれないストーリーポイントにより、より明確な画像が提供されます。しかし、それらは常に近似値であり、常に悪用され、誤解されます。
最終的には、環境に適応するために必要な構成プロセスのポイントになります。
TL; DR
常に、有能な開発者のみが特定のストーリーに割り当てられると想定する必要があります。コンピテンシー（またはその欠如）はin辱ではありません。それは単に遅れをとったり、例外的に経験したりしていない開発者のスキルの合理的な尺度です。
これは、特定の会社のアプローチの問題になる可能性があります。企業が特定の開発者に合わせて見積もりを調整しているのを見てきました。また、ランダムに選択された3人の開発者が、最初の3人のうちの1人ではない開発者をタスクにほぼランダムに割り当てる前に、ストーリーの見積もりを行うシステムを実施している企業を見てきました。
すべてのシステムが機能し、すべてのシステムが故障する可能性があります。問題は、どちらのシステムが優れているかということではなく、会社がどの欠陥を処理できるか/処理するかです。
原則として、言語/フレームワークを習得するための学習時間を含めるべきではありません。マイナータンジェント：理想的な世界に存在すべきではありませんが、プロジェクトまたはストーリー固有の障害の学習時間を含める必要があります。
そうすることには多くの正当化がありますが、このアプローチはワークロードを推定する意図に忠実であり続けるため、一般的にこのアプローチがより良い選択だと思います。これは客観性というよりもむしろ私の意見の問題かもしれません。確かに言えません。
勉強時間は個人的です。特定の技術に取り組む必要がある特定の開発者を対象としています。ユーザーストーリーはアプリケーション（およびアプリケーションが使用するテクノロジー）の範囲内にあるため、ユーザーストーリーのワークロードを評価する際には関係ありません。
学習時間は通常、積み重なりません。私たちのルーキーはC＃についてほとんど知らないので、仕事をする前に環境を把握するのにさらに3日かかると推測します。私が働いてきた多くの企業で一般的であるように、私たちは現在、いくつかのユーザーストーリーを（個別に）推定することが期待されている会議に参加しています。例として、取り組むべき3つのストーリーがあるとしましょう。
注：
学習時間が積み重なるケースは他にもあります。たとえば、3つのストーリーが非常に異なるトピックであり、異なるスキルが必要な場合です。
しかし、これが事実かどうかを判断するには、3つのストーリーすべてを同時に調べる必要があり、独立したユーザーストーリーを持つという原則に徐々に違反し始めます。おそらく異なる開発者が参加して、別々の会議でこれらの見積もりに取り組んだ場合、ストーリー間の重複を正確に測定することはできません。
どのストーリーが実際に行われるか（顧客が大きな見積もりを拒否する可能性があります）および誰に割り当てられるかを保証できないため、特定の開発者が特定のストーリーに割り当てられることを説明しようとしても無駄です。水を濁らせるだけです。
代わりに、ルーキーがすでに高速化されている（したがって、同僚と同等の開発者である）と仮定して、ワークロードの推定値をレンダリングする必要があります。
そのような見積もりは開発者に依存しないため、見積もりの正確性はストーリーに割り当てられる開発者によって変動しません。
注
特定の開発者が特定のストーリーに取り組むことができるようになる前に、学習に余分な時間を必要とする可能性があることを認識することは依然として重要です。それは依然として非常に重要な考慮事項です。ただし、この考慮事項はストーリーに添付するのではなく、この特定の開発者をこの特定のストーリーに割り当てる必要があります。
しかし、私が始めたとき、これは会社によって異なる可能性があります。一部の企業は、学習時間について大騒ぎしていないかもしれません（たとえば、開発者がとにかくテクノロジーの使用方法を学ばなければならない場合）。他の顧客は、顧客への請求に影響を与えるため、これらの推定値の精度に大きく依存する場合があります。
最後に、それはあなたの毒を選ぶ問題です。これらのアプローチのいずれも、他のアプローチよりも正確であることは保証されていません。
これは複雑なトピックであり、トピックについて頻繁に議論が行われています。私はこれに関する「標準的な」意見の概念が好きではありません。価値のあるさまざまな意見があります。しかし、アプローチを導くべき価値、原則、および実践をサポートするものがあります。
以下は、10年以上にわたってスクラムチームと協力してきた私自身の意見に基づいています。しかし、それは私の意見です。
予測方法としてのストーリーポイントストーリーポイントの本来の目的は、チームが一定期間に何を完了することができるかを予測する目的で、労力を見積もる簡単な方法を見つけることでした。一部の「著名人」は、ポイントは長期的な範囲を予測するためだけに使用されており（たとえば、リリースにわたって）、スプリントレベルで容量を決定するためではないことを述べています。また、コンセプトは、チームが履歴値に基づいて「相対的なサイジング」を適用するというものです（エフォートXはエフォートBに似ており、これは3ポイントでした）。これにより、推定プロセスが高速化されるため、チームは将来の作業を詳細な作業パッケージに分解し、すべてのタスクに時間を費やす必要がなくなります。優秀なチームは、すべてのテクニカルワーカーを同様のスキルレベルの非常に有能なメンバーに成長させるよう努めています。（この概念については、ポイント＃4でさらに詳しく説明します）これが達成されると、個々のスキルレベルは実際にはサイジングの変数になりません。しかし、その目標を達成するには、通常かなり長い時間と協調した努力が必要です。SO ...そこに着く前に何をしますか？
タスク時間はスプリント容量を決定します：ポイントは長期予測に使用されると述べている同じ「著名人」によれば、ポイントではなくタスク時間を使用してスプリント容量を決定することも提案します。私の意見では、それは結構ですが、コーチチームを「高性能」に支援したとき、彼らのレベルアウトされたスキルは、ストーリーポイントのみを使用してスプリントで何を完了することができるかを正確に判断できるレベルまで平均化されました。繰り返しますが、それは私たちが目指している目標ですが、新しいチームはその準備ができていません。したがって、1つのスプリントで、12タスク時間の労力を持つ2ポイントのストーリーと、25時間の労力を持つ別のストーリーを見つけることができます。それで、あなたは何をしますか？私が「アジャイル純粋主義者」と呼ぶ一部の人々は、ストーリーのサイズ（ポイント単位）は期間にとらわれないようにすべきだと述べるでしょう。他は同意しません。項目＃3のロジックを読んで、あなたの考えを見てください。
したがって、チームは作業を検討し、努力レベルのプロキシとなるポイントに同意する必要があります。正しい？すべてのスキルが同等であると仮定すると、コンセンサスに到達しやすくなります。しかし、多くの場合、チームにはJavaの第一人者、Javaがそれほど優れていない人（C＃または.NetまたはCobolの人でJavaを学んでいる人）がいます。したがって、BobのタスクXは非常に簡単です。ジェーンにとっては、もっと難しいです。
アジャイルチームは、集合的なコードの所有権、および専門知識の成長/拡大を促進しようとします。そのため、通常は、専門知識に基づいてストーリーを人々に割り当てることはありません。チームが共同でストーリーに取り組み、一緒に学習することを好みます。これは、「スピードを落としてスピードを落とす」という概念に沿ったものです。JaneにJavaの経験を与えるために時間をかけると、最初はスピードが落ちますが、後に有能なJava開発者が生まれます。実際、Javaの専門家が1人だけで、誰もが自分の専門分野で作業している場合、複数の潜在的な「失敗のポイント」がある状況を作り出しています。仕事の90％がJavaであるが、ボブ（私たちのJavaの専門家）が病気または休暇中の場合、スプリントで何が起こりますか？スキルを拡張することにより、潜在的なボトルネックを排除し、リスクを軽減します。それを念頭に置いて：チームがストーリーを見るとき、サイジングの際にいくつかの概念を念頭に置いておく必要があります。これを覚えて頭字語VUCKを考えることができます。
ボリューム：一部の作業は非常に単純ですが、大量の繰り返しタスクが必要です。（50以上のテーブルをコピーして再フォーマットする必要がある人がいましたが、それは簡単だから1ポイントだったと言っていました。移動および最適化されます。したがって、作業量に応じてポイントを再調整する必要がありました）
未知数：何をすべきかを知っていると思うこともありますが、いくつかの未知数も識別します。これらはリスクを表しています。これは、解決、再設計、または別の解決策を試さなければならない予期しない問題に遭遇する可能性があることを意味します。
複雑さ：これは非常に明白です。一部のソリューションは技術的に複雑です。私たちは何をすべきかを正確に知っていますが、技術的な専門知識が必要です。複雑さもある程度のリスクを意味しますよね？だから、私たち全員が平等なスキルを持っているとしても、技術的な複雑さは予期せぬ課題に直面する可能性があることを意味します。したがって、このストーリーをより大きくすることができます。
知識：解決策を本当に知っていますか？顧客が望むソリューションについて完全に明確でない場合があり、私たちは少し実験しています。または、おそらく誰もこのソリューションを実装したことがないため（新しいテクノロジーはこれまで使用されたことがない）、私たちは知らないことを知りません。
私の意見では、これらの考慮事項のすべてが実際には延長期間のプロキシです。簡単な話、たくさんのボリューム？時間がかかるか、ストーリーを分割する必要があります。不明ですか？リスク、研究、実験を追加しました。時間がかかるか、ストーリーを分割する必要があります。繁雑？追加のリスク、バグの修正、再設計などが必要になるため、時間がかかる場合があります。必要な知識があるかどうかわかりませんか？追加のリスクがあるため、実験が必要な場合があるなど、時間がかかる場合があります...
これがどこに行くのか見てください？そのため、ストーリーポイントの概念は、推定する際に期間について考えることを思いとどまらせますが、一方で、4時間で完了することができる1ポイントストーリーと、単純だが時間がかかる別の1ポイントストーリーを持つことは非論理的です2週間。
ジェーンがそのJavaの努力を志願し、それがボブがそれを行うことになった場合、同じ努力の2倍または3倍の時間になるとしたら、どうしますか？時間が経つにつれて、私のチームは、作業を行っている人々の努力レベル（LOE）/ VUCKに基づいてストーリーのサイズを決定しました。チームの第一人者であるボブが「1だ」と言うのは意味がありません。ジェーンにとっては簡単ではなく、完了するのに1週間かかり、さらにペアコーディングとコードレビューにボブの時間が必要です。したがって、実際のLOEを反映するためにこれらのポイントを増やしました。似たような話が次に来たとき、ジェーンにとって8だったものは以前5になりました。最終的に、誰もが簡単な3であることに同意しました。その時点で、チームとして成長していることがわかりました。
TLDR
いいえ、しかし、おそらくあなたが考える理由のためではありません。
ロングバージョン
他の回答の多くは、ストーリーポイントは他の作業に関連して純粋に計算されるべきであると説明しています。これは絶対に真実です。ストーリーポイントは、完了するために必要な時間ではなく作業量を推定するため、個人に基づいてストーリーポイントを与えることはほとんど意味がありません。
たとえば（私のお気に入りの1つ）、「穴を掘る」というタスクを検討してください。これは、除去する地球の量または地球を除去するのにかかる時間に基づいて推定できます。私の友人は、1時間に3メートルの速度で全体を掘ります。100を管理できるように、大きな機械掘り機を持っています。唯一の定数は地球の量です。したがって、それが推定単位として使用されます。
ただし、ユーザーストーリーを推定するための開発者の能力を割り引く2番目の（そして私の見解ではより重要な）理由は、ほとんどすべてのユーザーストーリーが複数の人によって処理される可能性が高いという事実です。
アーキテクト、開発者、テスター、UIを実行する2番目の開発者がいる場合があります。ユーザーストーリーが完了（理想的に展開および完了）としてマークされる前に、多くのさまざまな人々が作業します。問題の開発者に基づいて推定するという考え方は、ほとんど意味がありません。チームの労力を正確に推定する唯一の方法は、チームの速度を測定し、チームが完了するための作業を推定することです。
チームには「私」はいませんし、アジャイル計画には絶対にありません！