WORK | TFS 2012 Web Access で表示されている内容を理解しようとしています。受注残 | Product Backlog では、[Create Backlog Query] ボタンを使用してから、編集で新しいクエリを開いて、その動作を確認しました。次の 2 つの説明に当てはまる PBI が表示されていることに気付きました。
PBI がこの 2 番目の説明に当てはまるのはなぜですか? バックログで PBI がコミットされるのはなぜですか? 改良後にテーマレベルまたはエピックレベルの PBI を維持し、ユーザーストーリーレベルの子が実際のスプリントにコミットされたときにそれらをコミット済みに設定する方法はあるでしょうか? 未完成の PBI がバックログに追い出され、その状態を承認済みに戻すことなく、見掛け倒しの簿記を補う手段にすぎないのでしょうか? もしかして何か別の理由？
新規- これらは、誰かが製品バックログに追加した PBI であり、製品所有者によってレビューされておらず、構築することに同意されていません。
承認済み- 製品所有者が同意し、編集して、チームが理解できるようにした PBI です。承認されると、チームがスプリント計画で取り上げる準備が整います。
コミット済み - スクラム チームは、スプリント計画で PBI について話し合い、いくつかのタスクを作成し、現在のスプリントで PBI を構築することに同意しました。
完了- スプリント レビューでは、プロダクト オーナーはチームが行った作業を検査し、要件と品質基準を満たしていることに同意した場合、アイテムは完了に移されます。
あなたが正しい！観点からは、バックログに PBISCRUMをリストすることは意味がありません。Committedチームは、PBI をスプリントにコミットしたか、コミットしていないかのどちらかです。
興味深いことに、この用語Committedは SCRUM Guide for Sprint PlanningまたはSprint Backlogには記載されていません。
Committed私の推測では、Microsoftは、 から に移動したときに、開発チームの PBI の所有権を説明するためにこの用語を使用しProduct BacklogましたSprintが、検証または PBI ステータスの自動変更を通じてルールを適用したくありませんでした。
より信頼できる情報源をお探しの場合は、MSDNに状態図の記事があり、参照せずに利用可能なステータス ポイントについて説明していますSprints。
