为什么它建议故事的大小是2-3天？

Question

如果短跑平均10天，为什么它经常建议故事的大小是2-3天？

相关问题：如何处理长于一个sprint的待办事项？

Answer 1

在估计时，较长的任务有更大的可变性空间。多变性意味着很多事情--有人生病休息一天，有人被迫参加会议，有人必须支持另一个项目，你需要和其他人分享时间资源，或者teams...the列表继续下去。通过缩短给定任务的时间范围，你正在努力减少那些做工作的人可能被拖走或阻止他们完成你所估计的工作的时间。

这种想法并不是Scrum (或任何敏捷方法)所独有的。对于任何工程项目，它都是一个很好的评估技术的一部分。拥有更细粒度的任务往往会产生更精确的估计，而这种精确性就会冒出来。

Answer 2

你对“通常建议的故事平均为两天”有什么参考资料吗？

我曾见过一些人建议，任务最多需要一天才能完成。主要的一点是，我们不善于估计，你估计完成任务所需的时间越长，你就越有可能犯错误。

您可以在以下网站找到更多信息：

http://www.xqa.com.ar/visualmanagement/2009/02/one-day-tasks

和

http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

Answer 3

为什么它经常建议故事的大小是2-3天？

我真想知道你从哪里得到这个建议的，因为它是错误的。这项建议一般有两个问题：

• 估计在几天内完成。
• 这个建议决定了你的平均故事应该花多少钱。

这两个问题都违反了敏捷方法中使用的简单估计原则:您不知道需要多少时间才能完成一个故事。您只是试图比较积压中的故事的大小(复杂性)，而在计划会议期间，您只承诺很少有您认为可以在sprint期间完成的最优先的故事。在sprint完成之后，您将检查完成了多少个用户故事，并且您可以假设完成其他故事所需的时间--您完成的sprint越多，这个假设就越精确。随着你对完成故事所需要的实时时间的假设，你的承诺也会提高。

正因为如此，人们使用相关的方法来估计故事情节，比如故事点或T恤衫的大小，并计算出提供一个故事点或其他单位所需的平均时间。有了一致的估计，您应该稳定您的平均时间交付一个故事点在3-4冲刺。

因为单元是相对的，所以您也不需要在所有项目中使用相同的规模。你通常从一个用户故事开始，你对它的内容非常肯定，并把它当作有一定大小的标准龙。然后，您将继续估计其他故事，将它们与您的标准具和其他已经估计的故事进行比较，以选择预期的大小。在故事点的情况下，您通常会使用一些预期大小的序列，比如Fibonacci，因为随着故事的复杂性越来越大，估计起来更加困难，并且包含了更多的不确定性。大的故事应该被分解，如相关问题中所描述的那样。