【发布时间】：2012-07-11 04:27:04
【问题描述】：
在 TFS 中处理未结束 sprint 的任务和用户故事的最佳方法是什么？
我的做法：
- 使用正确的原因子状态将每个任务设置为“已关闭”。我将此任务 + 原始估计 + 剩余时间复制到记事本。
- 从用户故事中删除迭代（使其再次出现在产品待办列表中）
下一个冲刺：
- 将记事本中的任务作为新任务添加到 TFS，将其分配给正确的用户故事并将用户故事设置为当前 sprint。
这只是一种方法。您有更好的想法或建议吗？
【问题讨论】：
【发布时间】：2012-07-11 04:27:04
【问题描述】：
如果你真的在做 Scrum，你会发现对任何团队来说唯一重要的指标就是“剩余工作量”。问题是很多人都痴迷于指标、统计数据、数据以及对 Scrum 本质的松散跟踪。
所以保持简单。在 sprint review 中，只需与 PO 商定何时完成工作，然后将未完成的任务分配给约定的 sprint。
如果您想提高一点生产力；然后创建一个未完成任务的查询，只需将迭代列值替换为下一个 sprint 并发布回 TFS。
【讨论】：
-
检查！这是我在一些 sprint 中真正喜欢和评估的方式。我们专注于剩余的工作，这是真实的故事。
有两种思想流派：
- 保留这些并在产品待办列表迭代中创建新的（通常是团队项目根目录）。我们会留下它们并删除这些点（用于速度报告），因为它们代表了我们的 sprint 计划。
- 将迭代更新到产品待办列表，并在下一个冲刺期间像处理任何其他故事一样处理它们。 （我会订阅这个）。
每个团队的任务都不同。如果您在接下来的 sprint 中再次选择故事，请更新任务迭代路径并完成。如果您不选择备份，我会删除这些任务，以便您讨论如何在您确实选择备份时在软件的上下文中满足需求。将任务留在故事中超过一个 sprint 会给我们一种错误的安全感，即这些仍然是所有必要的事情。我宁愿重新评估我们将如何实现它。
【讨论】：
-
如果只是更新任务的迭代，那么未完成的任务就会出现在任务板上。因此，当您查看前一个 sprint 的迭代积压工作时，您会看到包含已完成任务的用户故事。当您查看当前 sprint 时，您会看到包含未完成任务的用户故事。
我们做与您完全相同的事情，但我们不使用记事本，而是简单地将任务copy 放入一个新的任务中，然后将其分配到新的迭代中。默认情况下，复制任务链接到原始任务的所有工作项，以及原始任务本身。
较旧的任务保留在旧迭代中并被标记为“已关闭”。
【讨论】：
也许我没有解决您的问题，但这是我的看法： 撤销任务的主要思想是未完成待办事项/用户故事。因此，在冲刺之后，所有完成的 backlogitems/userstories -> 新增量。如果一个 backlogitem 没有完全准备好，那么整个 backlogitem 就不会被交付，即使它只剩下几个任务。只需将所有内容回滚（保留代码:)）并完成冲刺。 backlogitem/userstory 进入下一个 sprint。
【讨论】：
在我看来，没有必要将它们标记为关闭。只需保留剩余的任务，将它们标记/标记为未完成，开始新的 sprint，并将具有该特定标记的所有任务应用为新的/即将到来的 sprint（如有必要，重新评估它们的时间和困难）。
【讨论】：
-
您能否更详细地描述您如何将它们“标记/标记”为未完成？
这是一个非常常见的场景，我们的待办事项中有一些东西可以为此创建一个适合目的的解决方案，但我们尚未将其优先于其他工作。
如果您认为这很重要，请随时在user voice 添加建议。我们优先使用该网站：这是您影响我们的机会
Ewald Hofman（TFS 产品组）
【讨论】：
-
今天我们的第一个 TFS 2012 sprint 即将结束。所以我期待听到一些关于这方面的“官方”建议。我想我们只是将未完成的 PBI 和错误工作项移回产品 backlog，并在合适的时候将它们移到下一个 sprint 迭代中。
-
请注意，我的方法是以跟踪“旧”/以前的迭代积压图表的方式完成的。将 WI 移动到下一个 sprint 时，您会丢失原始图表视图...