1

我们最近完成了前几个冲刺，提出了一些我们不太知道答案的问题。

这两个问题都与：我们应该如何处理在 sprint 结束时未完成的积压项目、任务和错误？某个动作将如何影响燃尽图或速度图？

如果我们有一个 20 天的 sprint，我的猜测是我们应该从第 1 天开始，在第 20 天停止，为下一次 sprint 会议（第 21 天）留出一天，并在第 22 天开始下一个 sprint。

假设我们有一个 PBI，它有 3 个任务。一项任务已完成，一项正在进行中，一项已放回待办事项。PBI 的努力为 6。如果我们在 sprint 期间将项目移入或移出 sprint，这会对 Sprint Burndown 和速度图产生影响。但是一旦 sprint 结束，我们移动这些项目，它仍然会影响图表吗？或者我们应该如何处理这些物品？我们应该关闭 PBI（将其设置为 Done，即使它不是）还是只是移动它并保留在前一个 sprint 中完成的任务？我们是否应该将所有任务都设置为完成，即使有些不是？每项任务都已完成，因此使用了数小时。我们需要跟踪这些，或者至少，速度图表应该仍然可以。

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

4

1 回答 1

2

随着时间的推移，Scrum 进行了轻微的修改和澄清；最新版本或多或少在The Scrum Guide (2011)中指定

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

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

  • 关于 Bug，您可以考虑与 PBI 类似地处理它来规划和优先级以及完成/未完成；你的团队需要一个完成的定义；如果这包括测试，则应仅在测试后将其视为完成。如果它没有完成，那么你应该以一致的方式处理它。开箱即用的 Scrum 1.0 版本的 Bug 工作项有一个名为 Committed 的状态，表明 Bug 已准备好进行测试，因此您不需要该测试状态。一旦通过测试，它就会从 Committed 状态变为 Done 状态。您可以在 Microsoft 站点上找到 Scrum 1.0 模板的流程指南。它或多或少是关于如何使用模板的说明。

于 2012-07-25T18:22:49.513 回答