JIRA/Agile:Sprint 命名错误?还是错误的方法论?或者 ..?

JIRA/Agile: Wrong Sprint naming ? Or wrong methodology? Or ..?

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

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

看来那个时候,我应该放下目前的后端工作并处理反馈。原因是通过解决 UI 问题,它会阻止 'wrongness' 传播到应用程序的其余部分(Lotus Domino:这就是它的工作原理)。

JIRA 没有暂停 Sprint 并开始新 Sprint 的工具。您必须关闭冲刺。

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

感觉就像是方钉圆孔,我不确定这是怎么回事 'supposed to' 使用敏捷或 JIRA。

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

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

冲刺中期范围变更的典型方法如下:

如果更改相对较小并且团队和产品负责人都同意,那么您可以继续进行。通常情况下,团队会补偿任何更改,例如,当他们引入新故事时,他们也会删除一个类似大小的故事,以便对冲刺的净影响接近于零。

如果变化显着the Product Owner may terminate the sprint。团队立即开始以与往常相同的方式计划新的冲刺。

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

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