JIRA/Agile：错误的 Sprint 命名？还是方法错误？或者 ..？ [关闭]

Question

我在第 3 个 sprint 上完成了一个项目，这是关于后端处理的。假设 sprint 名称是“3. 数据合并和表单生成”。我在该 sprint 中有 4 或 5 个功能与该任务直接相关，但我已经完成了一半 - 有些已完成，有些尚未完成。

在这个 sprint 中，我展示了一些发生在客户身上的事情，他们立即（有点出乎意料地）给了我几页纯粹与 UI 相关的反馈。非常前端的东西，与我当前的 sprint 无关，但仍然具有相关性和好东西。

当时看来，放弃我目前的后端工作并处理反馈是合适的。原因是通过解决 UI 问题，它将停止将“错误”传播到应用程序的其余部分（Lotus Domino：这就是它的工作原理）。

JIRA 不具备暂停 Sprint 并开始新的 Sprint 的功能。你必须结束一个 sprint。

在我当前的 sprint 中添加一项功能会很好，但会在 sprint 名称中包含大量 UI 问题，以明确与后端处理有关。

感觉就像方钉圆孔，我不确定这与 Agile 或 JIRA 的“应该如何”搭配。

所以我的问题是：问题是..

1. Sprint 的命名不应包含对其性质的过多承诺，因此包含旨在用于后端处理的 Sprint 的 UI 任务不会令人不安。
2. 如果一个 sprint 像这样被“中断”，我将它搁置并转移到另一个 sprint 的想法不是敏捷的工作方式（因此 JIRA 不会让你这样做）。应该会发生其他事情（如果是，会发生什么？）
3. JIRA 不如敏捷需求灵活（似乎不太可能！）
4. 其他一些我没有想到的事情。

Answer 1

在冲刺中期改变范围的典型方法如下：

如果更改相对较小，并且团队和产品负责人都同意，那么您继续进行。通常，团队会补偿任何更改，例如，当他们引入一个新故事时，他们也会取出一个类似大小的故事，这样对 sprint 的净影响接近于零。

如果更改很重要the Product Owner may terminate the sprint。团队立即开始以与往常相同的方式规划新的 sprint。

使用 sprint 包含的详细信息来命名 sprint 并不常见。只需使用简单的数字 sprint 名称（例如 sprint 1、sprint 2）就可以帮助明确 Scrum 团队愿意改变。

在 JIRA 中，如果一个 sprint 提前终止，我会将其标记为完成，然后创建一个新的 sprint。这可能会稍微影响您的速度计算，但应该很容易弥补。