当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。
私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。
したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（週に1回）でレビュー、優先順位付け、推定され、将来のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。
優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。
これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。（たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。）
これを実装するより良い方法は何でしょうか？