试图了解我在 WORK | 下的 TFS 2012 Web Access 中看到的内容积压|产品待办事项列表，我使用“创建待办事项列表查询”按钮，然后在编辑中打开新查询以查看其工作原理。我注意到它显示的 PBI 符合两个描述:
- 处于新/已批准状态的根迭代(待办事项)下的任何位置的 PBI。
- 处于新建/已批准/已提交状态的待办事项(根迭代)中的 PBI。
为什么 PBI 适合第二个描述？为什么 PBI 会被提交到积压的工作中？是否有某种方式可以在细化后维护主题级或史诗级 PBI，并在用户故事级子级致力于真正的冲刺时将其设置为已提交？这是否可能只是一种补偿劣质簿记的方法，即不完整的 PBI 被踢到积压中，但没有将其状态恢复为“已批准”？也许还有其他原因？
最佳答案
新 - 这些是某人已添加到产品待办事项列表中但尚未经过产品负责人审核且尚未同意构建的 PBI。
已批准 - 这些是产品所有者已同意、编辑并确保团队可以理解的 PBI。一旦获得批准，他们就可以让团队开始进行冲刺计划。
promise - Scrum 团队讨论了冲刺计划中的 PBI，创建了一些任务并同意在当前冲刺中构建 PBI。
完成 - 在冲刺审核中，产品负责人检查团队已完成的工作，如果他/她同意工作满足要求和质量标准，则该项目将移至完成。
关于tfs - 在 MSF Scrum 2.2 中，在待办事项列表中提交 PBI 意味着什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16923202/