在MSF Scrum 2.2的积压中，PBI的承诺意味着什么？

Question

试图了解我在TFS 2012 Web Access中的工作中看到的内容积压|产品Backlog，我使用“创建Backlog查询”按钮，然后在编辑中打开新查询以查看它是如何工作的。我注意到它显示了符合两种描述的PBI：

• 在新的/批准状态下根迭代（积压）下的任何地方的PBI。
• 新建/已批准/已提交状态的待办事项（根迭代）中的PBI。

为什么PBI符合第二种描述？为什么PBI会在积压中承诺？是否可能是某种方式在完善后维护主题或史诗级别的PBI，并在用户故事级别的孩子致力于真正的冲刺时将其设置为承诺？它可能只是一种补偿劣质簿记的手段，其中不完整的PBI被踢到积压但未将其状态恢复为已批准的状态？也许是其他原因？

Answer 1

新 - 这些是有人添加到产品待办事项中的PBI，未经产品所有者审核且尚未同意构建。

已批准 - 这些是产品所有者同意，编辑并确保团队可以理解的PBI。一旦获得批准，他们就可以让团队参与sprint计划了。

承诺 - Scrum团队在sprint规划中讨论了PBI，创建了一些任务并同意在当前sprint中构建PBI。

完成 - 在sprint审核中，产品所有者检查团队已完成的工作，如果他/她同意其符合要求和质量标准，则该项目将移至完成。

Answer 2

你是对的！从SCRUM角度来看，在积压中列出Committed PBI是没有意义的。该团队要么将PBI投入sprint ，要么他们没有。

有趣的是 - Sprint Planning或Sprint Backlog的SCRUM指南中未提及术语Committed。

我的猜测 - 微软使用术语Committed来描述开发团队在从Product Backlog移动到Sprint时对PBI的所有权，但没有使用Sprints。我想通过验证或自动更改PBI状态来强制执行规则。

如果您正在寻找更具权威性的来源 - MSDN上有状态图文章，其中描述了可用的状态点，而没有对if(!isset($_POST['Barcode']) || count($_POST['id']) == 0){ 进行裁判。