複数のプロジェクトで取り組む問題のストーリーの準備をモデル化する方法
当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定のプロジェクト用に特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。 Jiraプロジェクトを使用して、特定のプロジェクトの課題をホストし、さまざまなチームのスプリントにJiraボードを使用します。
私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。
そのため、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（1週間に1回）でレビュー、優先順位付け、推定され、将来の一部のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。
優先順位付けは、問題を並べ替えることによって行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの問題をバックログの先頭に手動で配置して、最初に取り組むようにします。一部のチームがそのような問題をスプリントに入れると、代わりに別のアイテムを手動でバックログの上部にドラッグする必要があります。
これはかなりエラーが発生しやすいです。基本的に、「オープン」と「進行中」の間の「ソート済み」および「推定済み」という追加の問題ステータスがあります。 sortedラベルとボード内でのそれらの位置を介してこれを反映することは、かなり面倒でエラーが発生しやすくなります。 （たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、チームが先週の広範なディスカッションで決定した可能性がある問題の順序を静かにスクランブルします。）
これを実装するより良い方法は何でしょうか？
JIRAでこれを追跡したい場合は、新しいタスクであるかのようにフォローします。
だから例えば：
CORE-75：Foo the Barというストーリーがあるとします。
どのチームがタスクを実行するかが決定したら、新しいタスクを作成できます：SUPPORT-123：Foo the Bar in Core。
次にblockCORE-75とSUPPORT-123を使用できます。 SUPPORT-123が終了したら、CORE-75に戻ることができます。レビューをマージするか、コードを2回レビューできます（指定されたチームが1回、コア固有のチームが1回）。
とにかく、これは実際に実行していることです。コアライブラリを独自の製品/顧客として考えてください。
1つのアプローチは、チームがスプリントの新しい問題を作成して、コアライブラリの問題にリンクを戻すことです。これは、タスクのサブタスクを作成しているようなものですが、ボード/バックログ全体です。
別のアプローチは、JIRAの外部でこれを個別に追跡することです。既存のバックログをCSVまたはスプレッドシートとしてエクスポートし、整理します。
問題をJIRAから分離することにより、計画会議で優先度を柔軟に定義でき、ボード上のJIRAのソートアルゴリズムについて心配する必要がなく、ラベルを使用する必要もありません。
コアライブラリの優先順位付け計画会議では、コアライブラリに対して完了するタスクの候補リストを作成できます。コアライブラリの責任者/責任者は、これらのタスクが異なるプロジェクトチームによって開始され、完了されることを確認できます。