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

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个点.如果它翻了过来,请不要包含该任务.

你可以很容易地估计开发人员消耗的天数或杯子,就像这个数字代表你正在做的工作类型一样,它可能与你将要执行的实际工作有关(即如何你有多少时间可用).

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

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

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

Answer 2

请记住,点数只是通过使用" 规划扑克 "作为常规做法建立的ROM(粗略数量级).前几个Sprint是当你开始确定这些点对团队意味着什么,你走的时间越长,团队就越准确.

另外,请使用间距更大的点.我见过和使用的一种做法是使用斐波纳契序列,它确保你没有太多的1点差异.

同样不要忘记测试人员,当指向一个故事时,任何进行测试的人都需要权衡,因为有时一个简单的开发任务会导致大量的测试工作,如果他们是真的,Sprint的想法就是让一切都完成,因为它可以发货(内置) ,测试和记录).因此,故事的估计由团队决定,而不是由个人决定.