要件ドキュメントをユーザーストーリーに変換するにはどうすればよいですか？
昔ながらの大きな要件ドキュメントを受け取りました。しかし、私のチームはアジャイルメソッド（スクラムとかんばんの組み合わせ）を使用して作業しているため、必要なのはser storiesです。
要件をユーザーストーリーに「変換」するためのガイダンスはありますか？
誰かがそのドキュメントをコンパイルするために良い仕事をしたので、明らかに私はゼロから始めたくありません。しかし、現在の形では、それは本質的に役に立たない。ドキュメントは数百ページの長さで、ユーザーの観点から書かれていません。翻訳はゼロから始めるのに時間がかかるかもしれません...
つまり、これに直面したことがある人からのヒントをいただければ幸いです。
たとえば、関連する主要なセクションを探して、それらをエピックに変換しています。名詞と動詞を探し、それらをロール、アクション、エンティティなどに変換する、もう1つの古いトリック。
近道はありません。システム要件がプロジェクトの要件であることを正式に確認する場合、あなたが持っているものは素晴らしいです。システム要件を正式に検証する必要がない場合は、通常、正式な要件をスキップできます。いずれにせよ、ユースケース/ユーザーストーリーを作成することは常に役立ちます。そのため、通常行うことをスリム化したバージョンであっても、それらを作成する必要があります。
それ以外は、単に各要件をループで処理するだけです。各要件を読み、要件をカバーするユーザーストーリーを特定し、要件をユーザーストーリーにマップします。ユーザーストーリーがまだ存在しない場合は、要件のユーザーストーリーを作成します。
最初はたくさんのように見えるかもしれませんが、最初のカットを行うのにそれほど長くはかかりません。ほとんどの場合、正式な要件はとにかく関連するストーリーにグループ化されるため、ユーザーストーリーの作成時に一度に10以上の要件をノックアウトすることは驚くことではありません。さらに時間がかかるのは、よくわからない要件について質問に回答することです。あなたはこれらを最終的に答えてもらう必要があったでしょう、それはあなたが後でではなく今あなたがそれらを識別したというだけです。
1つのユーザーストーリーに完全には適合しないかなりの数の要件に遭遇する可能性があります。そのような場合は、個々のストーリーにより明確に適合する、より具体的な要件を導出する必要があります。派生した要件をユーザーストーリーにマッピングし、元の要件への追跡可能性を維持します。そのため、システムレベルの要件とソフトウェア要件があります。 （プロジェクトによっては、中間レベルの要件も存在する可能性があります）。
これで、「正式な要件」とそれらの要件がマッピングされたユーザーストーリーが得られたので、ユーザーストーリーに基づいて要件を正式に検証するテスト手順を簡単に作成できます。
要約すると、申し訳ありませんがショートカットはありません。プログラムで要件を正式に検証する必要がある場合は、正式な要件をすでに記述しておくと、作業がはるかに簡単になります。正式な要件をユーザーストーリーにマッピングする場合でも、一連のユーザーストーリーよりも正式な要件ドキュメントを作成する方がはるかに困難で時間もかかります。
しかし、私のチームはアジャイル手法（スクラムとかんばんの組み合わせ）を使用して作業しているため、必要なのはユーザーストーリーです。
これは誤解です。スクラムもカンバンも、ユーザーストーリーで要件を指定する必要はありません。どちらもこの問題については黙っています。
スクラムガイド は「製品バックログアイテム」を指します。これらのアイテムには、説明、順序、見積もり、値など、いくつかの属性しかありません。スクラムに必要な形式やスタイルについては何もありませんが、ユーザーストーリー形式が使用されていることがよくあります。 かんばん アイテムの要件はこれよりもさらに少なくなっています。
要件仕様をユーザーストーリーに変換する代わりに、要件が 適切な要件の特性 -一貫性、完全、一貫性、アトミック、追跡可能、現在、明確、重要性を満たしていることを確認してください、および検証可能です。次に、要件間の技術的な依存関係を特定し、それらが適切に優先順位付けされるようにします。
アジャイルを採用している場合は、要件の仕様が「完成」していないことがわかります。これらの要件は変更される可能性があります。代わりに、アジャイルソフトウェア開発の原則に焦点を当てます。すばやく反復します-要件仕様で指定された機能のスライスを実装して、それをソフトウェアを評価し、将来の反復に組み込むためのフィードバックを提供できます。開発チームに主題の専門家、製品マネージャー、および利害関係者の代表と密接に協力して、ユーザーとそのニーズを理解させます。優先度の高い要件に最初に焦点を当てます。実際には、ユーザーが許容できるすべてのものを実装する必要はなく、実行されない作業を最大化できます。チームがどのように機能するかを反映し、改善します。
少し「スクラムぺダンティック」であることをお詫びしますが、プロダクトオーナーが記載されていないことに驚いたのは私だけですか？
それは@Thomas_Owensの答えの意味です：チームのプロセスに適したもので要件ドキュメントを変換できますが、POがあなたを助けるためにここにない場合（読み取り：通知）、項目を優先して調整できない場合、それはほとんど価値がありません:)。
あなたはこの状況についてほとんど選択の余地はないと思いますが、個人的に、この文書で私が最初に行うことは、私にそれのすべてのビットを説明し、POとして指名できる人を見つけることです。多分それを書いた人？