分裂或不分裂，它真的很复杂。
在我们最近的Sprint审查中，我正在教练的团队完成了所有但三个故事。因此，在Sprint审查中，我们试图决定与故事有关，以及是否将它们移动到规划或分割它们。所有三个故事都有外面的依赖性。所有三个已完成任务，其中两个仍然被依赖关系阻止。虽然可能有很多第二次猜测我们如何让自己进入这个修复，但当时的燃烧问题是该点的做法。我们看了三个可能的场景：
- 将故事转移到计划和所有要点上。
- 分割故事，留下一个带有完成任务的0点故事，并将故事移动到包含所有点的计划中。
- 分割故事并重新估计分割的每个部分。
现在，我想说的是，这个团队是敏捷的新手，最近开始关注速度差异和故事完成率，以了解是什么影响了他们的可预测性。对于所有新的度量标准，团队都非常关注它们。我们将速度方差计算为这个冲刺的速度-三个冲刺的平均速度除以三个冲刺的平均速度乘以100。故事完成率计算的是sprint计划中完成的故事/ sprint计划中承诺的故事。你可以看到这可能引起的焦虑，三个故事影响了这两个措施。
场景1- 移动故事，所有任务和所有指向下一个冲刺。我在采用这种方法的团队中工作。我们不介意我们的速度趋势的几块肿块。对于这支球队，虽然，有一个反对用三个故事来膨胀冲刺，其中一个是5指针。他们看到额外的点作为方差计算的潜在diNing。他们也刚刚计划了大量的三个短跑，并没有让承诺如此害羞地拥有一个非常大的数字。此外，有了他们所完成的任务的故事，他们感到误导，因为他们中的一些人相当大，所以数学看起来很有趣。我已经完成了15个小时的故事一天的一天。
场景2-将完成的任务拆分为一个0点故事，并计划在一个故事的所有点的剩余任务。这解决了冲刺中完成时间过多的问题，但仍然会导致冲刺看起来很膨胀。拆分的另一个好处是，我们的跟踪工具减少了滚动，团队可以专注于剩下的任务。平均速度将继续保持尽可能的准确，尽管方差仍然会在2个sprint中受到影响，故事比率只会在“失败”的sprint中受到影响。
场景3-将已完成的任务拆分为一个故事，将未完成任务的故事进行规划并重新评估拆分后的每个部分。虽然不是传统的分裂方式，它将减轻对速度变化的关注。这引发了很多关于拆分是否真的有价值，是否可能是一个“真实的”故事的讨论，这表明故事本身可能不够小。当团队运行几个例子时，我们发现大多数未完成的任务要么是数据操纵，要么是测试。团队认为这表明故事被阻塞问题所控制，并不是太大而无法在sprint中完成数据和测试。
该团队选择实施方案2，并修改它们不会计划冲刺中的被阻塞故事。在两个被封锁的故事的情况下，一个人在等待数据文件，另一个是等待法律团队的措辞。这导致我们团队的另一个最佳实践，仅当在Sprint规划之前已经解决了所有外部依赖项时，才能进行计划。
最大的胜利是热闹的讨论和赋予团队的赋权证明了解决不完整的工作问题。
评论(4)
达明
我认为场景1是我的大多数团队所采取的选项 - 只需将整个东西移入下一批次。但是，我们再次在Sprint期间追踪时间 - 我们将跟踪留给完成的故事 - 所以我们对15小时的驼峰没有看见。
而喜欢你的最后一个陈述 - 这也是我们最大的胜利。
谢谢你的评论。我同意帮助团队合作，是最大的胜利。
jeevan mathew.
你好！
如果所有故事没有由于（外部）依赖性未完成所有故事，我并不清楚 - 但假设如此......我会考虑以下选项（第4个？）
将故事留在小组完成任务的Sprint中。他们留在的是测试和验收。一旦依赖的故事也完成，我也会测试3个故事并接受它们。任何缺陷都将在即将到来的Sprint中解决 - 取决于优先级。这样，您的速度和方差不会受到影响。是的，它带来了技术债务，但它更好地选择了我。在回顾期间，我肯定会添加这种情况，并戳为什么依赖性也没有与这些故事一起完成，未来的规划应该反映它。
问候,
jeevan.
伊恩维尔吉布森
这是一个有趣的问题。我们通常的方法是分割，将一些点分配给故事的完成部分，一些分配给故事的剩余部分和它的任务。就像你说的，有一些问题，故事太大了吗?尽管如此，我们仍然需要一个务实的解决方案来解决这个问题。
我们最大的问题，就是在我们使用的工具中，如果我们拆分，那么与故事相关的对话仍然存在于故事的原始部分，并且在剩余/分裂部分中不再可见。理想情况下，这应该通过在分割它时通过向史诗推广故事来解决这个工具中，结果是有多个儿童故事构成了分割。
由于对话，我考虑将不完整的故事移动到下一个Sprint中而不拆分。你怎么看？