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