スクラムで一度に複数のストーリーを行うのは悪いことですか？
スクラムの定義では、一度に1つのストーリーで実行する必要があるとされています。しかし、チームが十分に大きい場合（たとえば、6歳以上）、1つのストーリーだけをとることが疑わしい場合があり、複数の小さなストーリーがある場合はさらに多くなります。
そのため、私が現在協力しているチームでは、2つのストーリーに取り組むことが多い場合があります。これは悪いことですか？
いいえ、悪くはありません。計画会議中に、チームは次のスプリントで配信されるユーザーストーリーにコミットします。スプリントはチームにとって安全なゾーンであり、チームはユーザーストーリーの配信方法を決定します。すべてのチームメンバーが（ビジネスの優先順位によって）最も重要なユーザーストーリーのタスクに取り組むことができない場合は、時間容量を最大限に活用するために、別のユーザーストーリーにも取り組む必要があることは明らかです。
ところで。チームが一度に複数のユーザーストーリーに取り組むべきではないことをどこで見つけましたか？あなたはスクラムマスターとして問題を見ることができます。チームが一度に1つのユーザーストーリーのみに取り組み、誰かが他に行うタスクがない場合、彼は立ち往生=障害になります。スクラムマスターとしてどのように解決しますか？ルールを削除して障害を取り除き、開発者がこれ以上立ち往生しないようにして、別のユーザーストーリーを続行できるようにします。
チームメンバーは一度に複数のユーザーストーリーで作業するべきではないため、このルールはおそらく言及されたと思います（現在のユーザーストーリーでの作業が別の障害によってブロックされるシナリオを除く）。人間の脳のコンテキスト切り替えは費用がかかり、破壊的であるため、これは理にかなっています。また、進行中のユーザーストーリーのセットが限られているため、スクラムプロセスの制御が大幅に向上します。これは、かんばんの仕掛品制限に対応します。
そのような制限はありません。ストーリーが互いに独立している場合、またはストーリー間の依存関係が最小限である場合は、確実に並行して行うことができます。もちろん、1人のメンバーは一度に1つのストーリーにのみ取り組むことになり、理想的には、ストーリーが終了した後にのみ次のストーリーに移動する必要があります。ただし、ストーリーの80％を終了し、残りの20％が他の誰かを待っている場合は、同じスプリント内でコーディングとテストを終了できる限り、間違いなく先に進むことができます。
スクラムには、チームが同時に引き受けることができる作業量を指定するルールはありません。チームに最適なものを見つけるのはあなたの仕事です。
スクラムは進行中の作業（WIP）をスプリント全体に制限します。これは、たとえば、このスプリントで20の作業項目を提供することを約束することを意味します。あなたがコミットメントを果たしている限り、あなたが同時に取り組んでいるそれらの数は関係ありません。
これを かんばん と比較してください。これもWIPを制限しますが、ワークフローの状態ごとです。たとえば、「テスト」のWIP制限は3です。これは、テストフェーズで同時に許可されるアイテムが3つ以下であることを意味します。