您应该在初始冲刺中分配多少个故事点？

在团队中首次实施Scrum时，如果不了解团队的速度，应该如何确定初始冲刺中的故事点数量？

您是否应该基于估计的小时数，而仅在以后使用积分？

您没有可利用的历史事实，因此我建议您不要打扰任何猜测。尝试仅基于某些公式来计算速度只是浪费时间。

只需估计足够的故事，并让团队在第一阶段就可以处理它们。他们无论如何都会完成他们完成的事情。经过最初的冲刺，您将获得实际速度。由于您的冲刺是（出色的！）1周，因此您会在很早的时候获得真实的速度。

没有人能说出您第一次冲刺能获得多少故事点。首先，故事的重点是无单位的价值。您不应做出像1个故事点= 6个小时之类的初步决定，因为在许多情况下，以后它们会对您不利。每个项目也可以具有不同的故事点“大小”。

应当根据与产品负责人的计划会议做出承诺。您将浏览用户故事，PO将解释有关它们的一些详细信息。他还将提供一些验收标准（完成的定义）。计划会议是有时间限制的（基于团队的sprint长度和规模），因此首先要观察的是您能够讨论多少个用户故事。基于从PO接收到的信息，团队应该能够对sprint中可以处理多少个讨论过的用户故事做出专业判断。因为团队知道这是最初的冲刺，但尚未完成任何工作，所以该团队可能只会承担少量工作，但这会在将来的冲刺中增加。

不应将纯故事点值用于计划和时间估算。应该用它来描述相对复杂性，但实际上8个故事点仍然可以表示介于6-12（Fibonacci）个故事点之间的值，因此说8个故事点等于4天确实很危险，因为它也可能是3或6 +初始冲刺中的“浪费”（开销）。

敏捷人的主要宗旨之一是“赋予人权利”。计划和承诺正是您赋予团队的权力。团队负责传递通勤的用户故事，但是他们当然会失败，并且在最初的冲刺中不能因承诺失败而受到指责。初始冲刺用于校准。

一种技术是选择一些中型用户故事，为他们提供任意大小的分数，然后由团队将其分解为任务。然后，团队以小时为单位估算每个任务，将其汇总后即可大致估算每个故事点的工作时间。知道冲刺的总工作量后，您可以推断出一些故事点，您可以在理论上在冲刺中完成这些故事点。

但是，这不应被解释为要达到的确切目标，而当第一个冲刺结束时，一旦团队的第一个实际速度出现，就应该将其忘记。

您必须猜测，因为您尚无任何要继续的信息。但是，如果您已经在Scrum之外但与同一个团队一起完成了工作，则可以使用以前的估算经验来指导您的猜测。或者，您也可以选择其他故事，直到时间用完为止。

无论如何，您并不完全依赖点估计来进行冲刺计划。在计划过程中，您的速度可以帮助您在提出最终承诺之前快速“提出”冲刺计划和/或协助进行健全性检查。但是，无论您拥有多少速度数据，团队最终都需要专注于故事，而不是观点。

请记住，对于1的极小值，5 x 1点的故事不等于1 x 5点的故事。对于长期计划而言，它们仅大致相等。

这就是积分的主要价值所在：何时您需要猜测何时可以完成史诗或发行，或者在计划的发行日期您的盘子上没有太多东西。

也就是说，一个成功的团队最终将发现自己正在计划每个冲刺的点数相同。但是，根据该冲刺中的特定故事会有差异。一个成功的团队可以在计划过程中阐明为什么一些5点故事实际上并不能抵消最初提出的所有5点故事...