使用 Scrum 2.1 流程模板，我注意到 TFS 中的 Sprint Backlog 查询返回了 sprint 的 Product Backlog 项目和任务的列表，但是当我查看它时，该列表看起来非常稀疏。在查询定义中浏览了一下之后，我意识到它首先匹配子链接，然后根据迭代过滤子链接。这很重要，因为几个任务没有被分配迭代，因此处于积压工作中。
不过，这让我开始思考——既然 sprint 的主要关注点是产品待办事项项目，而 PBI 意味着在单个 sprint 中开始和完成，那么为什么将任务放入其中是有意义的？不同的迭代？有原因吗？同样，Sprint Backlog 查询是否有这样的结构？
这取决于您如何使用 TFS 来计划您的 sprint。如果您打算使用TFS 2012 敏捷规划功能的全部范围，则需要维护工作项迭代。Scrum 板功能不受 Sprint Backlog 查询（或任何其他相关查询）的影响，它由团队管理中的调度和区域设置控制（可在团队的主页中获得）：
迭代取决于 PBI 的大小：如果一个 PBI，包括它的所有子任务可以适合单个 sprint，则应该将迭代设置为 sprint（例如：）\Release 1\Sprint 4\。
如果 PBI 大到足以跨越多个 sprint 来完成，请将其迭代保持在发布级别（例如：），\Release 1\并将其子任务保持在 sprint 级别。
如果您在 sprint 结束时有一个可行的功能，那么剩余的工作应该分解为一个新的产品 backlog 项目和与新 PBI 相关的任务。
如果你不这样做，你最终会管理一个部分完成的 PBI 集合，这很难跟踪并且会丢弃你的报告。
我不确定您将如何有效地整理您的积压工作并进行 sprint 计划，而不会将剩余工作拆分为新的 PBI。
如果您经常遇到这种情况，请考虑将您的 PBI 分解为更小的工作块。请记住，当您将 PBI 提交到 sprint 时，理想的 PBI 规模在 3-5 天（我的规模为 3 个故事点）或更短的范围内。
这是一个描述大小的好博客：http ://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/
讨论大小并包含对 3-5 天的引用的线程：何时根据功能请求创建 PBI 以及在哪里划线以将它们分开？
当您到 Sprint 结束并且 3/4 PBI 已经完成实施并被接受，而最终 PBI 有 2/3 任务完全实施时，您将做出一些艰难的决定。你：
a) 试图撕掉最后一个 PBI 的代码？
b) 将整个 Sprint 称为失败并重新开始？
c) 将未完成的子任务移动到下一个 Sprint？
这支持选项（c）。可能不是 Scrum.org 会推荐的，但这是它支持的场景。