アジャイルを使用して（TFSを使用して）新しいプロジェクトを開始しようとしています。製品のバックログに関して、「良い実践」の質問がいくつかあります。
ユーザーのストーリーを最初に追加するとき、（たとえば）「バックログ」イテレーションに入れるか、イテレーションを空白のままにしておくのが良いでしょうか？明らかに、米国での作業を開始する時が来れば、それは適切な反復バックログに移動されます。
エピックをより小さなUSに分割するとき、元のエピックは不要になったので、単に閉じますか？それとも、叙事詩の子供として新しい米国を作成する必要がありますか？（すべての子USが完了したら、エピックを閉じるのは誰かの責任です）。
最後に、製品のバックログには、ステータスに関係なくすべてのUSが表示されますか、それとも開始されていないUS（つまり、提案された「バックログ」イテレーション）のみが表示されますか？
これらの質問は生死にかかわるものではないことに気づきましたが、最初から適切に整理できるように、他の人が製品のバックログをどのように管理しているかを知っておくとよいでしょう。
回答:
私はTFSに詳しくありません（それはソフトウェアツールですか？）が、Schwarberに基づいていくつかの答えを出すことができます。
考えるべきストーリーのコンテナは2つしかありません。それは、製品バックログとスプリントバックログです。スクラムを追跡するためのソフトウェアツールを使用すると、履歴分析のために古いスプリントバックログを保持することができますが、それでも問題ありません。ただし、次のスプリントバックログ。
時々、現在のスプリント中にソフトウェアツールで次のスプリントのバックログを作成する傾向があります。こんなことしないで。その将来のスプリントバックログが存在する場合、人々はそれにストーリーを入れようとします。これにより、適切な計画プロセスが混乱し、緊張が高まり、スケジュールの問題が混乱します。
スプリント間の適切な境界を維持できない場合は、基本的に、複数の同じようなスプリントを実行しています。あなたはマルチタスクです。少なくとも、タスク切り替えのオーバーヘッドは遅くなります。研究によると、パズルAからパズルBへの人間の完全なコンテキスト切り替えには15分かかります。私の経験によれば、この抗力は生産性の50％以上になる可能性があります。
エピックを持ち歩きましょう。誰かがこの機能を要求しました。おそらく戻ってきて、叙事詩のステータスを知りたいでしょう。その人、部門、または顧客は、彼らが提出した「物語」を考え、今では叙事詩に昇進します。彼らは関係する小さな話については考えず、話Fooが彼らの要求に関連していることさえ認識しないかもしれません。エピックは、開発と顧客の間の通信に便利なハンドルです。
エピックは実際には関連するストーリーだけでは機能しないため、エピックは製品のバックログから完成した山に直接移動します。
ストーリーは一度に1つのコンテナーにのみ存在する必要があります。製品バックログで開始し、スプリントバックログに移動して、終了する必要があります。誰かが製品のバックログでストーリーを探しに来ても見つけられない場合、それは処理中であるか終了していることを意味するはずです。
製品バックログに何百ものアイテムがある場合、強制ランク付けされた順序はかなり意味がなくなります。確かに、アイテム20〜70の配置方法はかなり意味があるかもしれませんが、＃300が＃301の前か後かを本当に気にしているのは誰ですか。
これに対する考えられる解決策の1つは、メインの製品バックログにフィードする複数のサブコンポーネントバックログを持つことです。たとえば、サブコンポーネントとして、UI、DB、バックエンド、API、インフラストラクチャ、および技術的負債がある場合があります。各コンポーネントのバックログは、管理のために別の人に委任される場合があります。定期的な会議では、メインの製品バックログに移動するストーリーを決定する必要があります。製品バックログ内のストーリーの適切なバランスを維持するために、メインバックログにプロモートされるストーリーの比率のガイドライン（ルールではない）を事前に決定するのが最善です。2つのUIストーリーごとに1つのAPIストーリー？必要なバックエンドストーリーの数と比較して、テクニカルデットからいくつのストーリーを取得できますか？
このシステムはかなりの複雑さを追加し、多くの追加の調整を必要とします。これは、製品のバックログが非常に大きくなり、製品の所有者がすべてのストーリーを一度に考えることができない場合にのみ実行する必要があります。
アジャイルのイテレーションは、SDLCに続いて短時間で簡単に管理できる小規模なソフトウェアリリースであるため、ユーザーストーリーのコンテナではありません。
バックログは反復ではなく、本質的には、現在のスプリントで対処する時間のないユーザーストーリー、エピック、およびタスクのコンテナーです。次のスプリントに向けて計画を立てるときは、バックログ内のアイテムの現在の優先度と、次のイテレーションで何が属するか、何が属していないかを決定する際にそれぞれを提供するための努力のレベルを再評価する必要があります。
これはアジャイルではなく、反復開発の目的全体を打ち負かします。通常、ビジネスニーズと要件は不安定であるため、厳密なソフトウェア要件について長期計画を立てることはできません。そのため、現在のイテレーションと、このイテレーションを提供したらすぐに作業を行うことに専念しています。
経営者が（現時点で存在する現在のバックログに基づいて）長期的な見積もりを希望している場合は、現在のバックログ項目のサイズを確認して、完了予定日を確認できます。
バックログストーリーをどのイテレーションに入れるかについてのあなたの質問は、おそらくあなたはイテレーションをあまりにも先に計画しようとしていることを教えてくれます。
エピックをより小さなUSに分割するとき、元のエピックは不要になったので、単に閉じますか？それとも、叙事詩の子供として新しい米国を作成する必要がありますか？（すべての子USが完了したら、エピックを閉じるのは誰かの責任です）。
叙事詩は、指定されたビジネス目標を十分に達成したときに受け入れられる必要があります。これは基本的に、そのすべての子ユーザーストーリーが完成して受け入れられたときです。