この図に遭遇し、これらの数値を確認するのに役立つ別のよく知られたソースがあるかどうか疑問に思いました。
正常に完了したスプリントについて分析したデータに基づいて、チームは1人のスプリントにつき1人のユーザーストーリー（実際にはあらゆる種類の製品バックログアイテム）を平均1〜1-1 / 2にする必要があると判断しました。
出典：Mike Cohnのブログ「毎日のスタンドアップは1人ずつですか、それとも1枚ずつですか？」
回答:
生産性は、組織の文化、言語とツールの使用経験、プロジェクトの知識、使用されているプロセスの詳細、規制などの外部要因、および結束の単位としてのチームの能力など、多くの要因に影響されます。これが、プロジェクトを見積もるときに最も役立つデータが、作業を実施する特定のチームのデータである理由です。組織、産業、そしてソフトウェアプロジェクト全体に一般化すると、生産性はあいまいな領域になります。
反復的な開発の利点の1つは、単一のプロジェクトですべてのフェーズを何度も通過できるため、プロセスとチームについての洞察を得ることができることです。過去のプロジェクトの組織データから開始する場合がありますが、非常に迅速に（2〜4回の反復）、プロジェクト計画のためにチーム固有のデータを取得します。
引用する数値（スプリントごとに1〜1.5ユーザーストーリー）は、最高レベルの抽象化です。この数値を使用するのに最適な時期は、製品が属するドメインからの業界固有のデータ、組織データ、チーム固有のデータがない場合です-スクラムを使用する最初のプロジェクトの初期。それはおそらく、スクラムを他のプロセス改善技術（かんばん、CMMI、リーン）と組み合わせることを含む、あらゆる種類のスクラムのバリアントを使用しているチームからのものです。Mike CohnとMountain Goat Softwareは評判の高いアジャイルコンサルタントであるため、この数値をそのまま使用すると信頼できます。ただし、組織（またはさらに良いのはチーム）からのデータを入手したらすぐに、そのデータをスプリントの計画に使用してください。
これは心配したり測定したりするのに適さないものです。この数は、プログラマーのスキル、ストーリーの複雑さ、プログラマーとチームの経験、ストーリーを作成した経験、コードベースの保守性によって大きく異なります。 。
誰もが自分の能力を最大限に発揮しているように見えるか、クライアントが昨日よりも今日より幸せであるか、このプロセスが私たちが試した最後のプロセスよりもうまく機能していると誰も/ほとんどが考えているかなどについて心配する必要がありますか？
細かいレベルでは、「誰もがスプリントごとに1.5ストーリーを完了する必要がある」と言うのは、分析の危険な解釈です。私が見つけたのは、時間の経過とともに、チームは同様の複雑さのストーリーを指定することに落ち着くことです。これは、今後適切に計画できるベースラインを形成します。つまり、速度。ストーリーの数ではなくストーリーポイントで速度を測定するのは好きではありません。一般的には、ストーリー間のサイズの違いにより洗い流されます（小さいストーリーは大きいストーリーを相殺します）。
ここでの影響について、彼がスプリントの長さ（長いスプリントは大きなストーリーに取り組む傾向がある）とチームサイズの違いについて説明しているのを見るのは素晴らしいことです。また、カーテンを引き戻す（つまり、ストーリーに関連する詳細なタスクを実行する）と、ストーリーを完成させるために何が行われるか（最終的には、その投稿に関するもの-視認性）がさらにわかりやすくなります。
したがって、大まかな原則として、コーンは、スプリントごとの開発者あたり1〜1.5ストーリーをターゲットとしています。それよりはるかに多く、そしてあなたがスプリントの奥深くにいるまで、あなたはストーリーの進行を聞かないリスクがあります。リーン氏は、開発に取り掛かる準備ができるまでストーリーをバックログに残しておくことで、これに対処しています。Mikeが言っていることは、開発のための効果的なWork In Progressは1.5Xに制限する必要があるということです。Xは開発チームのサイズです。
私にとって、それはあなたのスプリント、または実行されるタスクのレベルに依存します。現在の経験から、私はいくつかのユーザーストーリーを作成したシステムに取り組んでいます。すべてのタスクが完了したら、毎週、その週に実行するように割り当てられたストーリーを実行します。スケジュールが進んでいても、次のスプリントに移動します（タスクが正しく実行されていると仮定します）。
私のチームでは、すべての人に3つのストーリーが必要です。そして、私たちが限界を超えていることに驚いています。
それは単にプログラマーに依存します。しかし、このようなことは問題にはなりません。ここでの問題は、クライアントが希望するものや要求したものを取得することです。
ダフトの質問ですが、a）スプリント計画セッションからのストーリーポイント（または何でも）の最初のチーム推定、およびb）スプリント速度および/またはバーンダウンを通じて答えが導き出されていませんか？
私たちは時々、最初のスプリントで星に手を伸ばし、すべての物語が彼らが見ているものではないことをすぐに発見します（何かが常に隠されています）。次に、バックログからの次のストーリーのプルダウンのために次のスプリントの見積もりを再調整します。
開発者1人あたり最大1つか2つのストーリーは、私のチームのモバイルアプリプロジェクトの大部分が、さまざまな組織、プロジェクト、プラットフォーム開発者にまたがって到達した場所です。