小型敏捷用户故事降低了速度的可变性，提高了可预测性
如果您在相对故事点中估计您的敏捷用户故事的大小，请意识到您在积压中拥有的大故事，可靠的可靠将是您的速度（趋势），用于规划未来的工作。当缓冲区中有更大的故事时，速度趋势值将不那么准确，而不是用户故事较小时。速度较低的速度趋势不是未来规划的良好基础，即下一个版本的规划速度。这个原因在于相对故事点估计的性质，也有一些统计数据也可以备份。让我们参加这一点。
通过设计，对于更大的估计，相对故事点估计越来越不准确。这斐波那契序列(嗯，它的一个改进版本:1,2,3,5,8,13,20,40,100)被用作点尺度来建模。这个想法是，一个估计大小为3的故事可能在2到5个实际点的小范围内(如果我们要测量实际点——我们没有测量，但那是另一个故事)。然而，一个估计为13大小的故事在“实际”大小上可能是8到20大小，依此类推。
这种对故事大小估计准确性的模型类似于不确定性的锥体“（COU）软件开发项目的概念。随着项目的进展，该科描述了项目估计中的指数下降的不确定性。COU表明，随着有关实际要求，设计和实现的更多细节，不确定性降低。“在初始概念时间内创建的估计可以在低侧或4倍上的4倍的因子不准确（也表示为0.25倍，只有1除以4）。”[Constux公共网页]。随着项目的进展，估计变得越来越肯定，直到例如，实际项目完成日期前一天，该日期近100％已知。下面显示了不确定性的锥形图。
以一种类似的方式，在一个项目中，工作没有细节分解 - 我们有史诗和特征。随着项目的进展，我们通过将史诗和功能缩小到敏捷用户故事（并估算其大小）来优化积压。这在下图中描绘。
敏捷用户故事：相对故事点估计
回到相对的故事点估计，思考以下问题。由于不确定性锥效应，估计的敏捷用户故事规模越大，与敏捷用户故事的“实际”规模相比，估计的误差就越大。不确定性锥效应是由斐波那契(Fibonacci)(或其他非线性)点尺度建模的。例如，一个估计为13的故事可能只比另一个真实为8的故事大一点，或者只比20的故事小一点。8-er可以是5到13，等等。如您所见，这种估计误差对于较大的故事更大。当您将估计的敏捷用户故事大小添加到计算速度时，这个错误就会累积起来。以30为例，大多数是小型敏捷用户故事，这与大型敏捷用户故事达到30的速度是不同的。在预测未来的速度时，你更有信心使用这30秒中的哪一个?
添加警告，“平均”，可能是制作上述一些陈述的更准确的方法。敏捷的用户故事估计为13尺寸可以平均（意味着在估计为13的许多敏捷用户故事中，从实际大小为8到20的任何地方。“实际尺寸”的概念是什么？我们没有衡量它，这些都是相对尺寸，对吧？但一旦故事交付，必须有一些实际规模。无论它是什么，无论其单位 - 代码线条，功能点，努力，复杂性和风险的一些功能 - 它确实存在，并且所有敏捷用户故事一旦完成，都有一个实际尺寸。我们不必知道实际规模或单位，以使这个参数对估计中的错误及其对速度的影响。
这也可以在统计数据方面解释。对于那些对数学不感兴趣的人，您可以跳过两段。我相信对积压中的较小敏捷用户故事的案件降低了速度的可变性。
如果我们认为错误的任何特定故事大小估计(大小与“实际”)作为一个随机变量(例如,在所有敏捷用户故事估计为一个特定的大小,说5),然后为大误差的方差较大尺寸的敏捷用户故事,由于定的效果。故事大小总结时,产生的误差的方差(速度)和方差之和(假设为简单起见,这个故事大小是独立的和正态分布估计错误,他们可能没有,但我有预感-方差只会变得更糟/大其他发行版)。在任何一个scrum团队规模的项目中，这种统计属性可能很难理解，但是在一个包含许多项目的整个大型组织中考虑它。统计结果在大量的样本中显示出来。在整个组织的sprint backlog中，规模越大的敏捷用户故事，在速度上的差异就越大，因此基于这些速度的发布承诺就越不可靠。
这强烈地表明，如果您的待办事项列表中大部分都是小故事，那么您(和您的组织)在预测您的进度(速度)方面会更好。不仅数学告诉我们这一点，它也通过了常识测试。如果您的待办事项列表中混合了小型、中型和大型的故事，那么只需要在sprint中计划一到两个更大的故事而没有完成，就会大大降低您的计划速度。下一个冲刺阶段，你的速度可能会因为大量的“宿醉”故事而飙升。如果这个模式重复着一个又一个的冲刺，那么你的速度将会有很大的变化，基于它的预测也不会是非常可靠的。另一方面，如果你在sprint的backlog中有很多小的用户故事，那么如果团队偶尔没有完成一个故事，这不会显著影响速度统计数据……平均速度应该足够可靠，可以进行预测。
理想情况下，我们会破坏所有敏捷用户故事到大约相同的小尺寸，忘记大调它们 - 只需计算它们并使用计数速度。但是，在实践中，我发现这是不实际的 - 通常会限制我们如何/多少我们可以分解敏捷用户故事。此外，也许更重要的是，在实践中，我们发现故事大小估计周围的讨论往往在开发清晰，共同理解敏捷用户故事方面往往是非常有价值的。
概括
故事的寓意是......分解那些敏捷的用户故事，或者更一般而言，将你的工作分解为小块的实际。除了降低的可变性之外，使用小敏捷用户故事有许多好处。这些优势包括：焦点增加，有助于防止失败;早期发现/更快的反馈;较短的提前期/更好的吞吐量;并降低测试开销。这些是未来文章主题的候选人。
从这个观察中产生的一个推论是，如果您不能将所有的敏捷用户故事分解成相对较小的，那么要意识到速度可能不是一个可靠的规划参数。例如，您可能还想查看故事周期时间(每个大小)。此外，还可以跟踪和监视平均故事大小(velocity/num_stories)。这个想法是越低越好——当历史积压的平均故事大小较低时，速度对计划来说更可靠。
为了帮助改善您的用户故事阅读关于更好的故事评估的10个建议Jann托马斯。
评论(10)
乔治·迪维迪
你好,道格,
我同意你把故事写得小一点，但你的文章有一些细节让我感到不安。
首先，这种不确定性的锥体本身不确定。看https://leanpub.com/leprechauns例如，更深入的讨论，但是，例如，我们的“详细设计”增加了可变性而不是减少它。绘图是一个概念模型，而不是经验的模型。我怀疑生命不会跟随它以及人们想要的。
第二，你会说，“一个估计为13的故事可能比另一个8的故事大一点，或者比20的故事小一点。”实际上，估计为13的故事可能小于8，或者大于20。这些只是估计毕竟。当团队非常强调故事点时，我经常听到他们想要在回顾时重新评估故事点。
第三，您说“如果您的backlog中大部分都是小故事，那么您(和您的组织)在预测您的进度(速度)方面将会更好。”我曾经这样想过，但后来发现并非如此。当然，你可以更容易地判断小故事的大小。但它们是正确的故事吗?关于这个问题，我在http://blog.gdinwiddie.com/2014/01/18/long-range-planning-with-user-stories/
第四，你说把故事拆得更小，然后数一数是不实际的。我不同意。如果您确定了验证故事所需的接受场景，那么您可以将其分解为这些部分。如果它们仍然很大，你可能错过了一些场景。你也可以为小故事做一些简化的假设，这些假设将在后面的故事中被阐明和扩展。虽然/你/可能很难把故事写得更小，但这并不意味着它不实用。人们能够以这种方式工作的事实就是实用性的存在证明。是的，在工作中存在差异，但与估计的更大的故事相比(或者可能更小)。
继续推，
乔治
嗨乔治，谢谢你阅读和评论我的帖子。要诚实地，我确实认为Cour Number（+/- 4x等）基于一些研究的经验数据来完成后回来。由于数字大致匹配了我的经验（无论如何在高端），我只是接受它们足够接近以用作模型。因此，请谢谢将我指向Leprochaun书，这显然明确了。但是我在这件作品中的COU的引用只是概念，而不是数字。不幸的是，我使用的图表拥有数字。所以我理解你的抗议。但是，我想我可以在不参考宾馆的情况下提出我的案件。我很高兴我做了，因为它导致了我（希望我们的读者）学习来自您的评论的新事物！
引用您的评论：
“第二，你说，”估计是13的故事可能只是比另一个真正8的另一个故事更大，或者只是小于尺寸20的故事。“实际上，估计为13的故事可能小于8，或者大于20。这些只是估计毕竟。当团队在故事点上施加了很多重视时，我经常听到他们想要重新估计它们。“
同意这些只是估计。我并不是指估算的准确性或精确度。但我认为，规模为13的故事小于8或大于20的概率较低(游戏邦注:比规模在8至20之间的故事要低)。这些估计都有概率分布。斐波那契数列(或任何非线性尺度，如几何尺度)被用来模拟精度的下降(更大的误差分布)的更大的估计。
第三，您会说“如果您的backlog中大部分都是小故事，那么您(和您的组织)在预测您的进度(速度)方面将会更好。”我曾经这样想过，但后来发现并非如此。当然，你可以更容易地判断小故事的大小。但它们是正确的故事吗?关于这个问题，我在http://blog.gdinwiddie.com/2014/01/18/long-range-planning-with-user-stories/”
我并不是说我们需要在发布计划阶段分解即将发布的所有工作/需求，以便更准确地估计下一个发布的范围(点)。(尽管我支持这样做长达3个月的积压)。我只是说，当历史速度与小故事的积压相关联时，基于历史速度的未来速度预测将更加可靠。故事越小，历史速度作为未来速度的预测就越可靠。我仍然不太满意我想要表达的措辞，但请耐心听我说。
“第四，你说把故事拆得更小，然后数一数是不现实的。我不同意。如果您确定了验证故事所需的接受场景，那么您可以将其分解为这些部分。如果它们仍然很大，你可能错过了一些场景。你也可以为小故事做一些简化的假设，这些假设将在后面的故事中被阐明和扩展。虽然你很难把故事写得更小，但这并不意味着它不实用。”
By “not practical” I meant that teams I’ve worked with (which are typically new or newer to Agile) generally have a hard time breaking _all_ the work down to small story size (and still have them be good stories, in terms of the INVEST criteria). There are at least some large stories that the team just struggles to slice further. It’s hard work and requires a special skill. I agree wholeheartedly that acceptance criteria/ scenarios are a great way to slice large stories. We (LeadingAgile) include this along with several other strategies for slicing features and large stories in our “How to Write Better Stories” training class. Getting back to the practicality point… if most of the team’s stories are small, and large stories are outlier exceptions, then the velocity statistics should be able to absorb / average out the error in the estimates of the large stories.
“人们可以以这种方式工作的事实是实用性证明。是的，努力方差，但比估计的更大的故事相当（或许少）。“
对不起，我不明白。
再次感谢您的评论。
埃迪
这是一个小狡辩，而不是“相对故事点估计越来越小，对于更大的估计，”我认为说“相对故事点估计越来越小估计，而是更大的估计，并且有意地估计。
同样重要的是要认识到故事点估算是团队的主观度量;它们只有在特定团队的背景下以及他们在旅途中的位置才有真正的意义。脱钩估计因此我认为这是不明智的计划——即使有大小的产品待办事项列表他们仍然需要仔细检查在sprint计划,他们有信心提供故事的全部选择冲刺,不仅把分数加起来并确认之和相同或低于他们的速度。由许多小故事组成的sprint backlog与包含许多大故事的相同规模的sprint backlog是非常不同的;然而，这并不一定意味着团队只应该同意小故事的sprint backlog，或者接受任何类型的backlog，只要它不超过他们的速度。敏捷团队以增量式和迭代式的方式构建，这样他们就有办法和机会处理由各种故事大小组成的产品backlog，并在此过程中不断学习和调整。
埃迪，谢谢你的评论。我喜欢你的观点。我相信你是在说，团队不应该盲目地在基于历史速度的sprint中承诺一定数量的点，即使他们有所有的小故事。而且，仅仅因为他们有一些大故事，这也不应该阻止他们做出承诺。同意了。速度(趋势)只是一个因素。团队做出谨慎决策的集体、共享的理解应该超越这一点和任何其他“机械”数据点(如果他们有强大的理由这样做)。我对你的观点理解对吗?
汤姆Henricksen
这是很好的信息，谢谢分享!关于这一点，我与敏捷教练进行了一些讨论。这似乎证实了我们很多人的想法。
汤姆，我很高兴听你这么说。谢谢你的评论。
Mike Cottmeyer
乔治......我不同意你对Doug的帖子的分析。我们的练习大多是以帮助大型复杂的，非敏捷组织组成团队，选择和分解正确的工作，并有效地与上游的流程和群体进行交付，从Scrum团队进行交付。在这种情况下，我认为Doug的积分有效。
道格用“不确定性锥”作为比喻，说明我们早期知道的比后期知道的少。这应该是普遍正确的，这是我们努力追求的，如果不是，那么你就不知道你的目标是什么，也不知道你什么时候要做。
I’d suggest that if you are going to allow that much variability in your estimates, even using story points, and are constantly re-estimating, and thus re-baselining, again… you have no idea what you are tracking toward or any way to communicate with people what they are going to get when you run out of time and money.
根据我们的经验，用户故事越小越好。我们教团队如何做适当的前瞻性计划，积极的风险管理，以及如何在过程中进行权衡，以便随着时间的推移更好地进行评估。当您积极地管理backlog时，您会期望评估，至少评估趋势应该开始收敛于现实。同样，如果没有，你就没有办法告诉你的业务人员，当你用尽时间和金钱时，他们会得到什么。亚博vip9通道我们没有放弃评估，并认为它是过程的关键部分……也就是说，为了评估工作，组织中的许多事情都必须经过处理。
最后，我建议对分类故事有理由有一个实际限制。我同意Doug，有一个点在突破某些东西，因为你可以，实际上并没有帮助这个过程。
我们每个人在社区中所做的每件事都有明显的细微差别。我们都在努力根据自己的经验为特定的客户解决问题。仅仅因为你的经历与我和道格每天的工作不同，并不意味着你的经历是无效的或错误的。这可能使它们不适用于您的环境。它们在我们的语境中是完全有效的。
坦率地说，我觉得你的评论有点讽刺，教条和居高临下。I think Doug’s has a valid point of view, especially in the large enterprise contexts we are working in. If you have any absolute data, that goes past personal experience or opinion, that proves Doug wrong in our context, I’d be happy for you to post it.
也就是说，谢谢你的评论。我正在呼吸;-)
克林顿基斯
篇好文章。这些评论很有趣，并强调了我们与不同团队在不同类型产品上的工作经验可能会产生不同的体验。将一篇文章或评论中的任何内容解读为“这是一种方法，因为它对我很有效”，会造成障碍和暴力交流。我一直在努力不把事情想成那样。
谢谢你的文章!
埃迪
嗨Doug，绝对！你把它更好地比我更好。充满乐趣，我在周五有这种确切的情况，同时帮助一个小队进行冲刺规划。他们已经陷入了速度的数量，并开始落下兔子洞试图说服他们的Sprint积压可以像上次冲刺的速度一样完成。我帮助他们通过要求他们探索他们提供Sprint的计划来回归现实;当他们调查_how_时，他们将作为一个团队工作，他们对犯下冲刺的信心增加，但他们也认识到涉及很多复杂性，因此风险，他们需要注意整个冲刺执行。然而，在挑战的核心，这是他们的故事可能太大，所以流量是块状和速度波动，使Sprint规划通常很难。他们是一个成熟的团队，所以可以应对大故事（有时没有选择），但不应该在每个冲刺中承担这么多，他们不必要地增加风险和不确定性。
联豪李
我同意将故事分割成合理的小故事，但与普遍理解相反，小故事的“相对”差异并不会更小。
一个故事的特征是其复杂性。当一个故事很小时，它的“绝对”方差也很小，例如，1点故事方差可能是1天的工作期限，而13分故事方差可能是几周的。但是，当我们看看故事的相对方差时，我们观察与普通信念相反的是什么：
1点故事方差110%
2点故事方差89%
3点故事方差70％
这可以通过实际数据更轻松地理解：1点故事覆盖工作跨越0-1 +工作日，相对方差比3点故事更大，涵盖可能在实际交付中工作2-4天的工作。那么这里实际发生了什么？虽然小故事的绝对方差很小，但由于故事本身的大小也很小，但相对方差保持相对相同或者可以更大，就像我们上面所看到的那样更大。
相对方差=故事的绝对方差/大小
当故事的大小很小时，绝对方差保持相对恒定的时，分母是相对方差的主导因素。
另一方面，大故事的相对差异是由提名者主导的-即大量的未知因素。因此，当故事大小变大时，相对方差也会变大。
因此，如果你把所有的故事都放在一个点上是不好的，因为你最终会得到高方差。你也不想拥有所有的大故事，因为你失去了敏捷性。相反，你需要将不同大小的故事自然地融合在一起。
也就是说，如果可追溯性(每天看到递增进度的能力)是您所追求的全部，那么就以可预测性(预测交付日期的能力)为代价，追求所有的1点故事。
一种可能的方法来规避小点故事的高相对方差是通过更粒度的故事点定义，例如1点均值1-2小时工作，2点平均半天工作，3点平均工作，5点平均2日工作等等
但故事越变越大,故事点估计基于时间的神经越来越开发人员,我们可以变成规模复杂性,例如选择一个故事与5点(或2天的工作)作为基线,和“大”的故事都比较反对这个的复杂性,和标签符合5、8、13等。
使用适当的项目管理工具，可以从相应的故事点中获得时代，我们可以拥有高可预测性，敏捷性和快乐开发人员。