假设产品X值10个故事点。开发在sprint Y开始，但没有及时完成。在计算冲刺Y的速度时你对故事有什么看法？
你愿意：
一个。为冲刺Y分配0个故事点，为最终完成的冲刺分配10个点;
湾确定剩余工作的故事点（假设为3）并将差异分配给sprint Y（在我们的例子中为7）;或
℃。还有别的吗？
提前致谢！
答案 0 :(得分：6)
取决于您是否关心“瞬时”或“平均”速度。就个人而言，我不会让它变得比必要的更复杂，只需将它添加到完成它的sprint中。通过查看过去3个月，6个月和12个月内每个冲刺完成的平均点数来计算平均速度。希望这些最终能够融合，你会很清楚你可以在一个冲刺中完成多少工作。
答案 1 :(得分：4)
为故事Y分配0分，在故事最终完成时分配10分。无论是故事还是未完成。没有回旋的余地。你想避免完成50％的工作，或者你的团队可能会在中途完成很多故事，而不是完全没有。
完全可以不在冲刺期间完成一个故事并在下一个冲刺中完成它。但是，您不应该在冲刺审查期间向产品所有者提供此故事。
如果你有一个特定冲刺的故事，那么故事是在这个冲刺或下一个冲刺完成无关紧要的。事情将是平均的。
向团队和利益相关者解释速度有助于估计何时发布并且不是衡量团队绩效的指标也很重要。
应该根据他们产生的最终结果判断团队，而不是在产生这些结果时。
结合良好的优先订单，您将创建高质量的软件，这意味着您的客户需要。
答案 2 :(得分：2)
这是冲刺的一个想法，“完整性”是二元的，无论是否完成，随着时间的推移，团队将有更好的估计，这个问题将失去相关性
答案 3 :(得分：1)
但是...
接下来的问题是你如何计算你在Y之后对冲刺的承诺。如果你过去的天气显示你的平均速度为20分。如果你带着这个故事，你就会超过10分。但是，如果你认为故事只剩下3分：你是
A）再拿另一个17pt来填补你20ps的估计容量 B）只有10pt，因为故事结转最初估计为10分
我们陷入了混乱，试图做A.其他人怎么想？
[更新]
我发布了一个关于此的问题：
Work out sprint capacity when carrying over story points in scrum
答案 4 :(得分：0)
这里的情况并不令人满意，但目前我们估计未完成的故事的剩余工作。如果它只有大约20％或更少，我们就会留下故事和冲刺点。如果不止于此，我们会询问PO是否应该完成故事，如果是，那么我们将其移至新的sprint。 然而，由于几个原因，这并不令人满意。 第一个大的或有风险的故事应该在sprint开始时开始，这样可以避免未完成。 其次，我们得到了不准确（但可能更平滑）的速度估计，这些估计在未来不太有用 第三，它并不严格，团队就像一个2岁的孩子，表现出轻微的弱点，并且想要利用它。
最后，随着时间的推移，严格性正在加强，团队正在一定程度上找到自己的脚，并学习处理问题的最佳方法。我们已经有很大的速度变化 - 大多数团队对每个冲刺都有一个关于哪些因素（假期，疾病等）影响每个冲刺的评论......完全不好:(