Tfs 如何处理未完成的工作，但保持图表的形状？

我们最近完成了前几次冲刺，提出了一些我们不太清楚答案的问题

这两个问题都涉及到：当sprint结束时，我们应该如何处理未完成的积压项目、任务和bug？某个动作会如何影响燃耗或速度图

如果我们有一个20天的冲刺，我的猜测是我们应该从第一天开始，在第20天停止，留出一天时间参加下一个冲刺会议（第21天），然后在第22天开始下一个冲刺

假设我们有一个PBI，它有3个任务。一项任务已经完成，一项正在进行，还有一项被重新安排。PBI的工作量为6。如果我们在冲刺期间将项目移入或移出冲刺，这会影响冲刺消耗和速度图。但是一旦冲刺结束，我们移动这些项目，它还会影响图表吗？或者我们应该如何处理这些项目？我们应该关闭PBI（将其设置为Done，即使它不是），还是将其移动并保留在上一个sprint中完成的任务？我们是否应该将所有任务都设置为完成，即使有些任务没有完成？每项任务都已完成，因此使用了数小时。我们需要跟踪这些，或者至少，速度图应该还可以

---

一个类似的问题出现了。我们添加了一个测试状态，因此开发人员没有将状态设置为“完成”，而是将其设置为“测试”，以便测试团队知道要测试哪些PBI或Bug，并在完成后将其设置为“完成”。如果一个bug来自PBI，我们关闭PBI并为它打开一个bug。但是如果它是一个bug，并且没有修复，他们会重新打开它。通过将其设置为“已批准”或“已承诺”，但分配给它的工作会发生什么情况？如果在sprint结束时这个bug没有被修复，我们应该将它设置为Done并打开一个新的，还是仅仅将它移动到下一个sprint？

Scrum已经随着时间的推移进行了轻微的修改和澄清；中或多或少指定了最新版本

• Sprint计划会议是Sprint的一部分，通常在Sprint的第一天（第1天）进行。第20天将包括Sprint回顾和回顾。第21天实际上是后续冲刺的第一天

• 关于您关于未完成产品待办事项（PBI）的问题：您的目标是随着时间的推移为您的团队建立速度一致性是关键。因此，最重要的是，你应该建立一种方法，在每一次冲刺中都采用同样的方法。我看到团队以不同的方式处理这个问题；您需要根据完成的工作确定是否实际交付了Sprint Backlog项。如果未交付值，则可以将其保留为未完成，并可以选择更新任务的最终工作。您还可以在Sprint Backlog项的历史记录和/或描述中添加一条注释，说明已完成的工作以及达到的验收标准。如果项目的价值在某种程度上得到了传递，那么您可能会做一个类似的记录，并对项目进行计数。你不需要精确地描述冲刺中的分数，因为它们会随着时间的推移而趋于平均，所以你只需要运用你的判断。任何未完成的工作都可以作为产品待办事项，并相应地划分优先级。您的产品负责人可能会决定将其放在产品待办事项列表的较低位置，这取决于未完成内容的价值。当PBI代表未完成的工作时，您将为其创建一组新的任务（您可以从未完成的Sprint复制未完成的任务，以节省时间）。这里同样重要的是讨论事情是如何进行的，以及在Sprint回顾和Sprint回顾期间如何处理这一进展，以便您的团队能够相应地进行调整

• 关于bug，您可以考虑与PBI类似地进行处理，以进行规划和优先化和完成/未完成；您的团队需要定义“完成”；如果这包括测试，您应该考虑它只在测试之后完成。如果没有这样做，那么你应该以一致的方式处理。现成的，Scrum 1.0版本的Bug工作项有一个名为Committed的状态，表示Bug已经准备好进行测试，因此您不需要该测试状态。一旦通过测试，它将从提交状态变为完成状态。你可以找到那个。这或多或少是关于如何使用模板的说明

应将此信息发布到。