依存しているストーリーをスクラムでどのように処理しますか？

私が現在取り組んでいる会社では、時々、いくつかの物語が互いに結び付いていることに気づきました（あまりに結合されているように）。これは、それらが同じ全体的な機能に属している、または異なる機能である可能性がありますが、次の機能を続行するために最初に完了する必要があるものなどがあります。

イテレーションのワークフローを停止することなく、このケースをどのように処理しますか？私たちは何か間違ったことをしていますか？

これは素晴らしい質問です。理論によると、ユーザーストーリーは独立しているべきですが、それを完全に達成することはできませんでした。

私の意見では、最も重要なのは依存関係を伝えることであり、それによってチームと製品の所有者の両方がそれを認識できるようになります。これにより、製品の所有者は、依存関係が削除されるように（たとえば、ユーザーストーリーをマージすることによって）ユーザーストーリーを再定義するか、ビジネスプライオリティを定義して、主要なユーザーストーリーが最初に実装されるようにします。

優先順位とPOの決定に基づいて、同じスプリントに両方を実装するか、プリンシパルが既に完了しているため、依存するものは後で問題なく実装されます。

最悪のケースは、AがBに依存し、BがAに依存している場合です。このような場合、ユーザーストーリーはおそらく誤って定義されており、おそらくAとB（ほとんど独立しているか、一方向の依存関係のみ）に書き換え、CはAとB

それに応じて計画してください。

それらを同じスプリントに入れると、ユーザーストーリーもスプリントバックログで優先されるため、問題は発生しません。

あなたのチームはこれに参加しているため、依存関係を認識しているので、心配する必要はありません。彼らは大人であり、依存関係について説明すると（通常、彼らはあなたにそれを説明します）、物事はスムーズに進みます。

アジャイルでは、ウォーターフォールのように、一度に1つのことしか実行できません。また、BがAを必要とする場合、通常Bの前にAを実行します。これは常識です。

依存関係は、システムを縦方向ではなく横方向にストーリーをスライスしているようなにおいかもしれません。特定の機能の開発には、データベース設計の変更からユーザーインターフェースに至るまでのすべてが含まれます。データベースルックアップ用のハンドラルーチンの記述など、システム構造のより低いレベルのユーザーストーリーにすべての労力を費やしていることに気付いた場合、ストーリー間の依存関係を作成している可能性が高くなります。そして、あなたはおそらくユーザーストーリーを間違って書いているのでしょう。

あなたの最善の策は、依存しているユーザーストーリーをできるだけ独立した小さなビットに分割することです。彼らはあなたが最初に最も依存している物語に取り組むべきです（あなたが言ったように：他を続けるために最初に終了する必要があるもの）。依存インデックスのようなものを作成します。ストーリー3にストーリー1よりも多くの被抑納者がある場合は、最初にストーリー3にタックする必要があります。

依存関係が原因で多くの停止が発生している場合は、作業を完全に停止し（現在のスプリントの真ん中です）、優先ユーザーのストーリーを再評価して、最初に対処することをお勧めします