MSFスクラム2.2のバックログにある間にPBIがコミットされるとはどういう意味ですか？
TFS 2012 WebAccessのWORK |に表示されている内容を理解しようとしています。バックログ|製品バックログ、[バックログクエリの作成]ボタンを使用し、編集で新しいクエリを開いて、どのように機能するかを確認しました。次の2つの説明に適合するPBIが表示されることに気付きました。
- 新規/承認済み状態のルートイテレーション（バックログ）の下の任意の場所のPBI。
- 新規/承認済み/コミット済み状態のバックログ（ルートイテレーション）のPBI。
PBIがこの2番目の説明に適合するのはなぜですか？なぜPBIがバックログでコミットされるのでしょうか。洗練された後、テーマレベルまたはエピックレベルのPBIを維持し、ユーザーストーリーレベルの子供が実際のスプリントにコミットしたときにコミットするように設定する方法はありますか？不完全なPBIがバックログに追いやられたが、状態を承認済みに戻さずに、見苦しい簿記を補うための手段にすぎないのでしょうか。多分他の理由？
新規-これらは、誰かが製品のバックログに追加し、製品の所有者によってレビューされておらず、構築することに同意していないPBIです。
承認済み-これらは、製品の所有者が同意し、編集して、チームが理解できることを確認したPBIです。承認されると、チームはスプリント計画を立てる準備が整います。
コミット済み-スクラムチームは、スプリント計画でPBIについて話し合い、いくつかのタスクを作成し、現在のスプリントでPBIを構築することに同意しました。
完了-スプリントレビューでは、製品の所有者がチームが行った作業を検査し、要件と品質基準を満たしていることに同意した場合、アイテムは完了に移動します。
あなたが正しい！ SCRUMの観点からは、バックログにCommittedPBIをリストすることは意味がありません。チームは、PBIをスプリントにコミットしたか、コミットしていません。
興味深いことに、Committedという用語は、 スプリント計画 または スプリントバックログ のスクラムガイドには記載されていません。
私の推測-MicrosoftはCommittedという用語を使用してProduct BacklogからSprintに移動したときの、開発チームのPBIの所有権を説明しましたが、ルールに強制したくありませんでした検証またはPBIステータスの自動変更を通じて。
より信頼できるソースを探している場合は、 [〜＃〜] msdn [〜＃〜] に状態図の記事があり、Sprintsを参照せずに使用可能なステータスポイントについて説明しています。
