現在のスプリント バックログのアイテムは、優先順位に従って、チーム全体で一度に 1 つずつアプローチする必要があります。
誰が言ったのかはわかりませんが、少なくとも強調されたテキストのようなものをこれまで聞いたり読んだりした覚えはありません。もちろん、あなたにとってのアイテムがストーリーなのか単発なのかにもよります。
ストーリー（通常は複数のタスクで構成される）であれば、これを達成できる可能性があります。ただし、あなたが言うように、ストーリーには全員を忙しくさせるのに十分なタスクが含まれていない場合があります。また、ストーリーに関連するタスクは互いに強く依存していることがよくあります。たとえば、デザイン セッション (チームの一部または全体が関与)、1 つまたは複数のコーディング タスク、コード レビュー、機能テスト、ドキュメンテーションなどがあります。コーディングの前に機能テストを行う必要はありません。
誰もが何かをしなければならないので、少なくともチーム メンバー (またはペア) と同じ数のタスクがいつでも開かれます。タスクがさまざまな理由 (タスク間の依存関係、外部関係者から必要な情報など) で保留になることがあることを考慮してください。
4 人の開発者のチームによる 1 つのスクラム プロジェクトでは、非常によく似た状況がありました。私たちは可能な限りストーリーを優先順位付けするように努めており、通常はいつでも複数のストーリーといくつかのタスクが開かれていました。最初は、スプリントの終わりにいくつかの半分完成したストーリーで問題が発生することがよくありました。そのため、未解決のタスク / ストーリーの数を最小限に抑えることが重要であることに気付きました。つまり、新しいタスクを開始する前に、未解決のタスク / ストーリーを最初に終わらせようとします。しかし実際には、その最小値が 1 になることは決してありませんでした。
スプリントあたりのストーリーの数については、(ストーリー、次にタスク レベル) の見積もりに基づいて快適に収まる数だけ入れました。もちろん、それは私たちの速度に大きく影響されました。最初は速すぎると見積もられていました。数か月後、私たちはそれを 60% まで減らしました。
チーム全体で各項目にアプローチするというアドバイスは、スプリント内で項目が専門のグループから別のグループに渡される小さなウォーターフォールを作成しないようにするためのものです。これは、テスターがスプリントの最初の数日間は何もすることがなく、コーダーが親指をいじる最後の数日間は残業するようなものにつながります. チームは、それぞれの「専門分野」の外であっても、全員が参加して全体として問題に取り組む必要があります。はい、コーダーはテストでき、テスターはコーディングでき、両方ともアーキテクチャなどを設計できます-そして、その過程で何か新しいことを学びます(驚くべきこと)。これは、誰もがすべてのことに優れているべきだと言っているわけではありません。「私はテストを行いません。私はコーダーです」または「私はこのスクリプトを書きません。私はテスターです」などの態度を示すべきです。スクラムチームには居場所がありません。
また、スプリント内で 1 つずつアイテムに取り組み、最後に何かが実際に配信されることを確認することもお勧めします。進行中の作業 (WIP) を制限することで、全員が各アイテムでいくつかのタスクを実行したが、スプリントの終わりまでにアイテムが完了していないという状況を防ぎます。
ただし、これは厳密なルールではなく、アドバイスと見なされるべきではありません。たとえば、2 つの小さなストーリーと 10 人のチームがある場合、チーム全員が 1 つのストーリーだけに集中するのはおそらく意味がありません。
要するに、誰もチームに作業を分割する方法を教えてはいけませんが、スプリント計画でコミットしたことを提供することが期待されるべきです.
チームの構成次第だと思います。ユーザー ストーリー内の任意のタスクを誰でも引き受けることができるチームがある場合、これはうまく機能します。そうしないと、一部のユーザーがアイドル時間になる可能性があります。
優先度に基づいてユーザー ストーリーを作成するポイントは単純です。最も優先度の高いユーザー ストーリーを最初に完成させます。これは、実際に優先度を設定した顧客の観点から、最も価値のあるものです。
スプリント中にコミットするユーザー ストーリーの数は、チームの可用性、チームのベロシティ、スプリント期間などのいくつかの要因によって異なります。したがって、スプリント中に他の人が取り組むストーリーの数を知ることで、どれだけの価値が得られるかはわかりません。
ノエル、あなたのチームはスクラムチームで働くように訓練されていますか？プロジェクトを始める前にスクラムコースに送ったのですか？
ブログの本に書かれていることを誤解したという理由だけで、多くのチームがスクラムで失敗するのを見てきました。
また、経験豊富なスクラムプラクティショナーまたはスクラムコーチがいると大いに役立ちます。
あなたの質問に具体的に答えるために、他のものとは異なるこの素敵な無料の電子ブックをチェックしてください：
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf