产品待办事项和任务是否应该在不同的迭代路径中？
使用Scrum 2.1过程模板，我注意到TFS中的sprint Backlog查询返回了Sprint的Product Backlog项和任务的列表，但当我查看它时，该列表看起来相当稀疏。在仔细研究了一下查询定义之后，我意识到它首先对子链接进行匹配，然后根据迭代来过滤子链接。这很重要，因为有几个任务没有分配迭代，因此处于积压状态。
然而，这让我思考--既然sprint中的主要焦点是Product Backlog项，而PBI意味着在单个sprint中开始和结束，那么为什么任务在不同的迭代中是有意义的？有理由吗？同样，Sprint Backlog查询会有这样的结构吗？
回答 3
Stack Overflow用户
发布于 2013-04-15 13:21:37
这取决于你如何使用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级别上。
Stack Overflow用户
发布于 2013-04-15 11:30:48
当你在Sprint的末尾，3/4的PBI已经完成、实现和接受，而最终的PBI有2/3的任务完全实现时，你需要做出一些艰难的决定。您是否：
a)试图撕开最后一个PBI的代码？
b)称整个Sprint是一个失败，然后重新开始？
c)将未完成的子任务移动到下一个Sprint？
这是为了支持方案(c)。可能不是Scrum.org推荐的，但这就是它所支持的场景。
Stack Overflow用户
发布于 2013-07-10 21:55:16
如果您在冲刺结束时有一个可工作的特性，那么剩余的工作应该被分解到一个新的产品待办事项和与新的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?
https://stackoverflow.com/questions/15953575
复制
腾讯云开发者
