1人のスプリントにつき1人のユーザーストーリーを完了する必要がありますか？
この図に出くわし、これらの数値を確認するのに役立つ別のよく知られたソースがあるかどうか疑問に思いました。
正常に完了したスプリントについて分析したデータに基づいて、チームは1人のスプリントごとに1〜1-1/2ユーザーストーリー（実際にはあらゆる種類の製品バックログアイテム）を平均化する必要があると判断しました。
出典：Mike Cohn's Blog on " Should the Daily Standup Be Person-by-Person or Story-by-Story ？"
生産性は、組織の文化、言語とツールの使用経験、プロジェクトの知識、使用されているプロセスの詳細、規制などの外部要因、および結束の単位としてのチームの能力など、多くの要因の影響を受けます。これが、プロジェクトを見積もるときに最も役立つデータが、作業を実施する特定のチームのデータである理由です。組織、業界、そしてソフトウェアプロジェクト全体に一般化すると、生産性はあいまいな領域になります。
反復的な開発の利点の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つのストーリーが必要です。制限を超えていることに驚いています。
それは単にプログラマーに依存します。しかし、このようなことは問題にはなりません。ここでの問題は、クライアントが希望または要求したものを取得することです。
最後に聞いたのは、チームメンバー数の1.5/2倍でした。
また、Mike Cohnはこれらの数値を使用する必要があることを示唆していないことに注意してください。業界での長年にわたって、彼が指導してきた多くのチームにおいて、チームメンバーあたり1.5x/2xのストーリーが最も効果的であることがわかりました。彼が理想的なユーザーストーリーサイズであると彼が考えているものを私が彼に尋ねたとき、彼はこの答えを出しました。