16

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

  • PBI 在根迭代（积压）下处于 New/Approved 状态的任何位置。
  • 待办事项（根迭代）中的 PBI 处于 New/Approved/Committed 状态。

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

4

2 回答 2

75

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

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

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

完成- 在 sprint review 中，产品负责人检查团队所做的工作，如果他/她同意它符合要求和质量标准，则该项目被移至完成。

于 2013-06-16T12:10:00.647 回答
7

你是对的！从一个角度来看，在 backlog 中列出 PBISCRUM是没有意义的。Committed团队要么已将PBI 提交给 sprint，要么他们没有。

有趣的是，该术语在Sprint 计划或Sprint BacklogCommitted的 SCRUM 指南中没有提及。

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

如果您正在寻找更权威的来源 - MSDN上的状态图文章描述了可用的状态点，而无需参考Sprints.

在此处输入图像描述

于 2016-10-28T20:36:29.710 回答