Question

让我们举一个例子，假设我们有5个故事A，B和C，D，E。

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D

根据故事的重要性（优先级）对故事进行排序。你怎么估计它们？是根据功能的大小估算的吗？例如，我给了他们估计值：

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

让我们假设这是一个为期两周的冲刺。这是14天的时间大小= 5,14x5 = 70个人日。现在价值10是什么意思？这是指团队应该花费的时间（小时或天）吗？什么是故事点？假设这是第一次冲刺;当你没有最后一个冲刺的速度时，你将如何估计短跑的数量？

Answer 1

哎呀！从记忆中写作是正确的。

故事点与当然的估计有关，当你试图弄清楚你可以为冲刺做多少时，故事点是实现部分或整个功能所需的“工作”的一个单元。一个故事点可以是一天，一小时，或介于两者之间。我混淆了下面的“估计”和“故事点”，不知道我在想什么。

我最初写的是“估计”和“故事点”。我打算写的（并在下面编辑）是“故事点”和“速度”。

故事点和速度是相辅相成的，它们共同努力让你感受到“在给定的时间内我们能完成多少”。

我们举一个例子。

假设您想要以小时为单位估算要素，因此估计为4的要素将需要4个小时才能完成，因此您可以为所有要素指定此类估算值。因此，在竞争资源方面，您认为该特征或其“故事”值得4分。

现在让我们假设您的项目中有4个人，每个人每周工作40小时，但是，由于周围发生的其他事情，如支持，与营销，会议等交谈，每个人都只会能够在实际功能上工作75％，其他25％将用于其他任务。

因此，每个人每周有30个小时可用，当你统计所有4个人时，这个星期总计30 * 4 = 120个小时。

现在让我们说你正试图创建一个3周的冲刺，这意味着你可以完成3 * 120小时的工作。这是你的速度，你移动的速度，你可以完成多少“故事点”。

你的速度单位必须与故事点的单位兼容。你无法衡量“开发人员在实施这个过程中消耗了多少杯子”中的故事“我们有多少小时可用”。

然后，您尝试找到一组功能，这些功能一起接近但不超过120个点，按其优先级排序。这只是从顶部向下累加，直到你达到一个任务，提示总和超过或等于那120个点。如果它翻了过来，请不要包含任务。

您可以轻松估算开发人员消耗的天数或咖啡，就像数字代表您正在进行的工作类型一样，并且它可能与您将要执行的实际工作相关（即你有多少时间可用。）

您还应该在每次冲刺后评估您的工作量，以确定75％的数字是否准确。例如，如果您只管理了一半您要执行的操作，请确定您的功能估算是否错误，或者您的工作负载估算是否错误。然后在估算和规划以下冲刺时将您学到的知识考虑在内。

另请注意，如果功能太大，应将其拆分。这样做的主要原因是更大的估计值会在其中构建更多的不确定性，您可以通过将其分解为子特征并估计它们来减轻这种不确定性。然后，大的整体特征成为所有子特征的总和。它还可以让您通过为不同的人分配不同的子功能，将功能分成几个人。

一个好的经验法则是，估计超过1天的特征可能会被拆分。*

Answer 2

请记住，点数只是通过使用“Planning Poker”作为常规做法建立的ROM（粗略数量级）。前几个Sprint是当你开始确定这些点对团队意味着什么，你走的时间越长，团队就越准确。

另外，请使用间距更大的点。我见过和使用的一种做法是使用fibonacci序列，它确保你没有太多的1点差异。

另外不要忘记测试人员，当指向一个故事时，任何进行测试的人都需要权衡，因为有时一个简单的开发任务会导致大量的测试工作，如果他们是真的Sprint，那么想法就是尽可能完成所有事情。装运（建造，测试和记录）。因此，故事的估计是由团队而不是个人决定的。

Answer 3

值10仅仅是相对于其他估计值的值，例如它是20的硬度的一半，或者比9的硬度略高。没有特定的1点转换= x小时的努力值得指出。

在我工作的地方，我们拥有所谓的“史诗点”，这就是某些高级故事的难度，例如。将搜索集成到一个新网站中，该网站将包含多个要完成的故事，然后我们会根据每个史诗的内容估算每个故事的小时数，例如。只需在网站上搜索支持文档。 “史诗点”以斐波纳契数的变化（1,2,3,5,8,13,21,28,35）分布，因此更广泛，更模糊的史诗只会获得很大的价值，例如：任何大于8的东西都表明它可以被分解成更容易估计的故事。值得注意的是，在我工作的地方，我们每周只工作5天，在每个sprint中，每天都会失去会议，例如演示，迭代计划会议，回顾和审查，所以冲刺只有9天。为某些事情添加成对编程，修复错误的时间和其他非项目工作（如支持票据），很难说sprint中的少数开发人员将花费多少小时。

根据获得的经验，前几次冲刺是价值开始变得更具体的地方，估算值可以在如何猜测价值方面变得更清晰。

Answer 4

对于一个新的团队或项目，我们总是首先假设一个故事点是一个“理想的一天”，我们认为每个开发人员每周大约需要3.5天，这就是我们计算可能的初始速度的方法。 / p>

一旦你完成了“计划扑克”阶段并平衡/比较了你的所有故事，故事点的实际真实持续时间真的是未知的 - 你真正拥有的是的一个很好的想法相对持续时间，并使用你最好的判断来提出可能的速度。

至少，我就是这样做的！

如果你的目标是将你的故事点大致等于理想的一天，那么我建议将你的故事分解成更小的故事，否则你将无法在计划和跟踪迭代中度过美好时光。

Answer 5

周围的答案很好。

我想补充的一点是，你选择什么作为你的积分价值的基础并不是很重要（小时，理想的日子，等等）。重要的是要保持一致。

如果你保持一致，它将允许你发现团队的“真正的速度”。例如，假设你没有几次迭代：

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

现在你开始迭代4并且你在积压中有以下内容（按优先级排序）：

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

现在假设你的积分估计是一致的，你可以合理地确定球队将完成1,2和3的项目，但绝对不是4。

您可以应用相同的内容来发布积压，以改善您对发布日期的预测。这就是Scrum团队在进行评估时可以改进估算的原因。

Answer 6

JB King有最好的答案，但没有投票意味着不正确的信息正在传播，并导致对scrum的解释普遍不佳。请在这里看到设计Scrum的人之一的真实答案：

http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

请记住，这是关于努力，而不是复杂性。

现在阅读并观看视频：

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points

如何衡量Scrum的估算和故事点？

6 个答案: