我在 TFS 中遇到了燃尽图的问题。铁。Sprint 1 - 我们有 9 个工作日。sprint 结束，剩下 6 个任务，因此必须将它们移至下一个 sprint（sprint 2）。我们正在将这些任务拖放到下一个 sprint（sprint 2），但在这种情况下，Sprint 1 的燃尽图有问题。这个 sprint 1 图表将把这个 sprint 视为完全成功，因为所有剩下的任务被转移到新的 sprint。
如何处理这个问题，以便我们为所有冲刺（甚至是前一个冲刺）提供一个良好的燃尽图？
问问题
162 次
4 回答
0
可以在这里想到一个替代解决方案。
如果问题是有一个一致的方式来表示在 sprint 期间承诺了多少与完成了多少，我会提倡使用 Sprint Burn-up Chart 而不是 Sprint Burndown 更好的处理方式。这添加了关于在冲刺中提交和修改的工作量与完成的工作量的详细信息。
不幸的是，我找不到有助于在 TFS 中创建链接的好链接。但是您可以在这里找到 Sprint Burn-up 图表的基础知识及其在 Burndown 图表上的优点： https ://www.sealights.io/software-development-metrics/burn-up-chart-exposing-scope-creep-并揭示你的实际进展/
总结变化的一个图像应该是这样的：
于 2019-08-26T10:21:43.053 回答
0
在冲刺结束时，烧毁已经达到了它的目的。您有机会调整分数并在团队中集中精力，以最好地尝试实现您设定的目标。
既然 sprint 已经结束，你即将开始一个新的 sprint，为什么还要关心之前的燃尽图的状态。你现在对此无能为力。桥下全是水。
唯一真正重要的是新的 sprint backlog 和团队为尝试实现这个新的 sprint 目标所做的工作。一个新的图表可能会帮助你。
如果你真的关心 sprint 结束后的烧毁状态，等到第二天将任务转移到新的 sprint 中，这将导致 sprint 的最后一天的历史被正确存储，并且烧毁将符合您的愿望。
如果您确实在 sprint 的最后一天将任务移出，Azure DevOps/TFS 将将此作为 sprint 中的故意范围更改进行跟踪，并将（正确地）将剩余工作设置为 0。
于 2022-01-21T18:04:51.550 回答
-1
通常，当外部输入在运行中的 sprint 中完成时会发生这种情况，该输入未正确估计最终导致 sprint 结束时未完成的任务。一个建议是您可以创建一个“障碍积压”，而不是将未完成的任务移动到下一个 sprint。“障碍积压”将直接作为您正在运行和即将到来的 sprint 之间的桥梁，并间接连接到实际积压本身。您可以通过此轻松跟踪未完成的任务。有关更多详细信息，请阅读以下主题：
于 2019-08-28T11:14:12.307 回答
-1
据我所知，这取决于您完成 sprint 并计划下一个 sprint 的日期：
- 如果日期是当前 sprint 的最后一天，当前 sprint 的燃尽将显示 0 剩余工作，这不是你想要的
- 如果日期是下一个 sprint 的第一天，当前 sprint 的燃尽将显示 sprint 结束时的实际剩余工作
如果以上是正确的，解决方案是在 sprint 的最后一天之后的一天结束 sprint。
于 2019-07-23T09:52:48.287 回答