让我们说下一个冲刺是10点/天。 3位开发人员正在努力提供增量。每个开发人员将有10个点完成。
冲刺开始了，
每位开发人员的原始估算值：10
当sprin结束时，
每个开发人员的已完成工作：10但是他们仍然没有制作并接收增量，因此剩余工作将为每个开发人员增加3分。
计算总数：
原始估计：30分
已完成的工作：30分（注意：完成工作我的意思是开发人员真的花了一天时间完成任务但不一定完成任务）
剩余工作：9分（注意：剩余工作是开发人员完成任务所需的扩展点）
如何计算冲刺速度？我在考虑：[（完成工作 - 剩余工作）/原始估算] * 100
这是sprint的70％工作点
我是在正确的轨道上吗？
答案 0 :(得分：9)
速度是完成的行为（或故事，如果这是你的计算方式）的总和。
如果他们真的完成了30分的故事，但是在他们的工作中他们创造了值得9分的新故事，然后速度是30.但是如果他们没有完成任何故事，实际上通过39分获得70％< em>值得的故事，然后他们的速度是0。
如果他们完成22分并且剩下的8分故事现在被估计为17分，那么他们的速度是22分。
分数完整的故事不计入速度。甚至没有一点点。
在计算速度时，完成一项不完整任务的工作计算根本不计算。我知道这听起来不公平，但事实就是如此。它有效。计算速度时最重要的是开发团队已完全完成任务。它已经过测试，它在CI中，自动传送系统的软件包含了肮脏的小SSD。任何不足之处都不会计入您的速度。如果你计算完成的工作而不是释放的行为，那么你就是在做自己和客户是一种伤害。不要忘记99％完成的故事来自这次迭代，它的速度为0，将在下一次迭代中并计入其速度。最后这一切都变得平淡无味。
可以重新估算，或者从现有故事中创建一个新故事。但是，不要追溯性地改变冲刺中获得的积分。它无助于团队或公司取得任何额外成果，只会夸大团队对自己的信心。与所有指标一样，速度是性能的大幅降低，不能用于证明最近的结果。充其量它可以用来鼓励未来的努力。