产品待办事项项和任务是否应该处于不同的迭代路径中？

Question

使用Scrum 2.1流程模板，我注意到TFS中的Sprint Backlog查询返回了sprint的产品Backlog项目和任务列表，但是当我查看它时，列表看起来很稀疏。在查询定义中略微探讨之后，我意识到它首先匹配子链接，并根据迭代过滤子项。这很重要，因为有几个任务没有被分配迭代，因此坐在积压中。

这让我想到了 - 因为sprint的主要焦点在于产品Backlog项目，并且PBI意味着在单个sprint中启动和完成，那么为什么它对任务有意义？要进行不同的迭代？有原因吗？同样，是否有理由以这种方式构建Sprint Backlog查询？

Answer 1

这取决于你如何使用TFS计划短跑。如果您打算使用维护工作项迭代所需的TFS 2012 Agile Planning功能的完整范围。 Scrum Board功能不受Sprint Backlog查询（或任何其他查询）的影响，它由团队管理中的scheduling and areas settings控制（在团队的主页中可用）：

迭代取决于PBI的大小：如果PBI（包括其所有子任务）可以适合单个sprint，则应将迭代设置为sprint（例如：\Release 1\Sprint 4\）。

如果PBI大到足以跨越多个sprint完成，请将其迭代保持在发布级别（例如：\Release 1\）及其子任务到sprint级别。

Answer 2

当你到达Sprint结束时，3/4 PBI已经完成实施并被接受，而最终的PBI完全实现了2/3任务，你需要做出一些艰难的决定。你：

a）试图撕掉最后一个PBI的代码？

b）将整个Sprint称为失败并重新开始？

c）将未完成的子任务移至下一个Sprint？

这是对选项（c）的支持。可能不是Scrum.org会推荐的，但这是它支持的场景。

Answer 3

如果您在sprint结束时有一个可行的功能，剩下的工作应该分解为新产品积压项目和与新PBI相关的任务。

如果你不这样做，你最终会管理一个部分完成的PBI的集合，这是一个很难跟踪并将丢弃你的报告的痛苦。

我不确定如何在不将剩余工作分成新的PBI的情况下有效地整理待办事项并进行冲刺规划。

如果您经常遇到这种情况，请考虑将您的PBI分解为较小的工作块。请记住，理想的PBI大小是在3-5天（我的规模上为3个故事点）或更小的范围，直到您将PBI提交到冲刺点为止。

这是一篇描述大小的好博客：http://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/

讨论大小的主题并包含3-5天的引用：When to create PBI's from a feature request and where to draw the line into splitting them up?