我们最近完成了我们的第一次冲刺，并提出了一些我们不太了解答案的问题。
这两个问题都涉及到：当sprint结束时，我们应该如何处理积压项目，任务和错误？某个行为将如何影响燃尽或速度图表？
如果我们有20天的冲刺，我的猜测是我们应该从第1天开始，在第20天停止，在下一个冲刺会议（第21天）离开一天，并在第22天开始下一个冲刺。
假设我们有一个PBI，它有3个任务。一个任务是完成，一个是进行中，一个是回到待办事项。 PBI的努力为6.如果我们在冲刺期间将项目移入或移出冲刺，则会对Sprint Burndown和Velocity图表产生影响。但是一旦冲刺结束，我们移动这些项目，它是否仍会影响图表？或者我们应该如何处理这些物品？我们应该关闭PBI（将其设置为Done，即使它不是），或者只是移动它并保留上一个sprint中完成的任务？我们应该将所有任务设置为完成，即使有些不是吗？每项任务都已完成，因此使用了数小时。我们需要跟踪这些，或者至少速度图表仍然可以。
类似的问题也出现了问题。我们添加了一个测试状态，因此开发人员不会将状态设置为Done，而是将其设置为Testing，因此测试团队知道要测试哪些PBI或错误，并在完成后将其设置为Done。如果PBI出现错误，我们会关闭PBI并为其打开一个错误。但如果它是一个错误，并且它没有修复，它们会重新打开它。通过将其设置为已批准或已提交，但分配给它的工作会发生什么？如果在sprint结束时没有修复bug，我们应该将它设置为Done并打开一个新的，或者只是将其移动到下一个sprint？
答案 0 :(得分：2)
随着时间的推移，Scrum已略有修改和澄清;最新版本或多或少在The Scrum Guide (2011)
中指定Sprint计划会议是Sprint的一部分，通常在冲刺的第一天（第1天）执行。第20天将包含Sprint Review和Retrospective。第21天实际上是后续Sprint的第1天。
关于未完成的产品待办事项（PBI）的问题：您的目标是为您的团队建立一段时间的速度。 一致性是关键。所以最重要的是，你应该建立一种方法，每个Sprint 都这样做。我看到团队处理这种方式是不同的;您需要根据完成的内容确定您是否实际交付了Sprint Backlog Item。如果未传递该值，则可以将其保留为未完成，并可选择更新任务的最终工作。您还可以在Sprint Backlog项目的历史记录和/或描述中记下已完成的内容和达到的验收标准。如果物品的价值在某种程度上被传递，那么您可以制作类似的注释并计算该项目。你不必确切地了解Sprint所涵盖的各点，因为它们会随着时间的推移而平均，所以你只需要运用你的判断。无论做什么，都可以制作产品待办事项并相应地确定优先顺序。您的产品负责人可能会决定将其放在产品积压的较低位置，具体取决于未完成的产品的价值。当PBI代表未完成的工作时，您将为它创建一组新的任务（您可以复制那些未完成的未完成的任务，以节省时间）。这里最重要的是讨论事情的进展以及如何在Sprint Review和Sprint Retrospective中处理这一进展，以便您的团队可以相应地进行调整。
关于Bug，您可以考虑与PBI类似地处理它以进行规划和优先排序以及完成/未完成;你的团队需要完成的定义;如果这包括测试，您应该在测试后认为它已完成。如果没有完成，那么你应该以一致的方式处理它。开箱即用，Bug工作项的Scrum 1.0版本有一个名为Committed的状态，表明Bug已准备好进行测试，因此您不需要该测试状态。一旦通过测试，它就会从Committed状态变为Done状态。你可以找到Process Guidance for the Scrum 1.0 template on the Microsoft site。它或多或少是如何使用模板的说明。