Story Point & Working Hours

[徐毅]

我们使用story point来评估product backlog item的大小，然后在sprint planning的时候，会对选择的item估出工作所需要的working hours。不知道大家是否也是同样的做法。

我的问题是，你们有否把story point和working hours联系起来，如一个story point大致表示100 working hours，如果有的话，为什么？有的话，给个您的SWOT分析。

--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Mater
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[ifire zhang]

我觉得没有太多必要吧。一般把sprint backlog分解为1天的粒度就OK了。然后，如果这个sprint里backlog过多，则去掉一些，少了则增加一些。

在08-4-9，徐毅 <kave...@gmail.com> 写道：

[Wang Lijie]

出于更好的计算工作量，我们直接使用的就是Working Hour, one task no more than 12 hours(2 days).

个人觉得，使用Story Point 就不应该再用working hours,二者还是有冲突的。

在08-4-9，ifire zhang <junlin.z...@gmail.com> 写道：

[徐毅]

这个联系不是我（Scrum Master）或者team member在关注的，我也是机缘巧合知道有这样的一个比较或者关联。貌似主要是upper用来进行resource planning的，即部门有多少人头，按照历史的story point消耗速率，和汇报的相关人员的capacity总和（working hours）来个除法，得到个系数，用这个系数来评估当前的资源状况等，如是否有足够的人力来完成项目。

在08-4-9，ifire zhang <junlin.z...@gmail.com> 写道：

我觉得没有太多必要吧。一般把sprint backlog分解为1天的粒度就OK了。然后，如果这个sprint里backlog过多，则去掉一些，少了则增加一些。

[徐毅]

在08-4-9，Wang Lijie <wangli...@gmail.com> 写道：

出于更好的计算工作量，我们直接使用的就是Working Hour, one task no more than 12 hours(2 days).

个人觉得，使用Story Point 就不应该再用working hours,二者还是有冲突的。

想知道，你用working hour是用于sprint backlog么，还是用于product backlog，或者两者都是？

[Gmark]

我们团队用xplanner跟踪过一段时间,得到过大概的评估小时->实际工作小时 比率.

[Liang Qiao]

统计数据在大方向上是没错的，但不要在细粒度上直接联系在一起，否则你会失去一些真正的东西"工作热情"。

个人认为，这些数据可以用于宏观上做预算，但不要直接再细分到人头。

2008/4/9 徐毅 <kave...@gmail.com>:

[徐毅]

可以的话能否share下这方面的经验，这个比率你们怎么用它，然后有啥好处啊

在08-4-9，Gmark <mark...@gmail.com> 写道：

[徐毅]

说得没错。

我关注的重点是，story point更多的是讲求相对大小，和working hour这种叫什么。。客观标准（？）的度量标准，究竟有没有必要或者有没有意义牵连到一起？这方面各位能否提供些意见。

在08-4-9，Liang Qiao <sagittat...@gmail.com> 写道：

[Liang Qiao]

请站在公司财务或者部门经理的角度，去试着做下一年的预算，你就知道你想要什么数据了。但这些数据用在个体上，显然不适用。

2008/4/9 徐毅 <kave...@gmail.com>:

[徐毅]

不好意思，从没接触过预算，这方面没经验。确实不知道这个"评估小时->实际工作小时 比率"如何影响到年度的预算。

在08-4-9，Liang Qiao <sagittat...@gmail.com> 写道：

请站在公司财务或者部门经理的角度，去试着做下一年的预算，你就知道你想要什么数据了。但这些数据用在个体上，显然不适用。

[blackanger]

不太会SWOT分析法，简单说下我们的做法。

可能是因为还不太会应用story point， 我们现在是把story point和working
hour挂钩的。也就是说，一个story point代表 1 hour， 然后根据实际花费hours
来评估团队生产力的值。 这样在一个迭代以后，可以评估团队的生产力。帮助计
算团队不断的进化的程度。

请各位同学指教。

[Jun Liu]

我觉得牵连在一起也不准确。因为story point/working hours在不同项目不一定是等比的。

2008/4/9 徐毅 <kave...@gmail.com>:

[blackanger]

预估小时和实际工作的比率，就是团队的生产力吧 ？ 我的理解有错没有，请指
正。

[Wang Lijie]

两者都是，但是Product Backlog不会很精确，都是一个粗略值

在08-4-9，徐毅 <kave...@gmail.com> 写道：

[Jun Liu]

Product Backlog比较粗略，只会用到story point，用sales部门提出的business value/story point来作为优先级的依据之一。

2008/4/9 Wang Lijie <wangli...@gmail.com>:

两者都是，但是Product Backlog不会很精确，都是一个粗略值

[Wang Lijie]

做预算的话，最好还是小时了！

在08-4-9，Liang Qiao <sagittat...@gmail.com> 写道：

请站在公司财务或者部门经理的角度，去试着做下一年的预算，你就知道你想要什么数据了。但这些数据用在个体上，显然不适用。

[Gmark]

基本上是这样.
其实我觉得跟徐毅说的story point是一个意思.假设2个人.

估算 实际 实际工作小时数
迭代1 80 85 120
迭代2 60 56 100
迭代3 45 50 80

类似意思,经过几个迭代以后就能大概知道这个团队或
者其中某个人的velocity了,比如以上数据,这个团队一周
(80个working hour)能完成45个估算小时.
只是很粗略的方法.

On Apr 9, 2008, at 2:38 PM, blackanger wrote:

> 预估小时和实际工作的比率，就是团队的生产力

[徐毅]

你这里的"估算小时"和我所言的story point所想要起到的作用是一样的。不过我认为你这里，"估算小时"和"实际小时"两个词汇都用到"小时"这个词汇，小时可以是一个客观的度量标准，所以，从粗颗粒角度衡量项目进度和细到sprint backlog中某个task的大小，两个标准容易引起误解诶。。

感觉应该很容易把估算小时的小时当作是实际的小时，也即60分钟，而其实从你这里的统计看来，应该是80/45=1.78个小时。不如更换为另一个概念，比如说story point。

在08-4-9，Gmark <mark...@gmail.com> 写道：

[blackanger]

老徐可否把你如何估算sotry points用实际数据或者说具体的虚拟数据拿出来说明
一下呢 ？

On Wed, 2008-04-09 at 16:04 +0800, 徐毅 wrote:
> 你这里的"估算小时"和我所言的story point所想要起到的作用是一样的。不过

[徐毅]

首先，我没有阅读过敏捷估计那本书。
其次，是所经历的一些grooming session得到的经验，然后自己思考消化的。参加过Bas主导的，也参加过Craig主导的。

比如说有一个product backlog，内有若干item。在场的会大概扫描一下list，然后挑选一个size居中的item出来，分析其技术难度，及所需effort等，然后设为3个story point大小，为方便，称此item为"标杆item"。之后针对其他的item进行评估，以相比前面的"标杆item"的技术难度等，估出相对大小，比如item b肯定比标杆item大，但肯定不到两倍那么多的effort，然后可以用planning poker的方式，得出一个值，比如说5.然后循环评估其他item。

在sprint planning的时候，也许这个item b，通过team的详细分析，由sprint backlog得到的数据发现，此item完成所需要的人工为500人.小时。

上面是我的所见，或实际数据。然后下面是我的思考：

将story point和working hours联系起来究竟是否有用呢？我看未必。在某个sprint planning中，估计出需要完成任务的工作时间，受人员能力，工作环境，及其他相关因素的影响。而至少我们的情况是团队成员或多或少总会变化，这就导致多个sprint中，team的整体能力其实是不等的。换个角度讲，即使team成员不变，其能力也是变化的，包括环境，和当时所能获取的资源，都会影响团队完成任务所需要的时间。也就意味着，即使是同一个item，换在不同的sprint，可能就会有不同的工作时间估计值，更不要说换给不同的team。

在08-4-9，blackanger <blacka...@gmail.com> 写道：

[Anchuan Qian]

"即使是同一个item，换在不同的sprint ，可能就会有不同的工作时间估计值"

既然是估算，我有两个问题：
1、估算的目的是什么？
2、估算的标准和单位是什么？

1、不可能每个人的目的都一样。我们的目的是更清楚的了解自己的开发能力和工作进度，然后科学的做下一步的计划，更好的控制项目。

2、既然是这样，那么估算就一定要客观和一致。而且毫无疑问，前提是在目前的团队和项目中进行（或者同等的团队和项目）。否则去比较这些数据就没有任何意义了。下面是我用过的两种方式：

一、功能点数。比如说：1、2、5、8、16，这是按照一个功能的复杂度（一般是一张卡片，即User Story）的大小给值。最重要的就是要保持一致，后面的评估，都是参照前面的相似或类似的功能。

难点就是Story的粒度，和评估时候保持一致。

二、真实天数。我们现在就用这个，并且用Mingle管理项目，很科学。在做计划的时候，开发者会评估每张Story的大小（真实天）；然后开发者在开始开发之前，会再评估一下Story的大小；然后Mingle也会记录一个开发者完成这张Story花费的真实时间（可以根据这些数据自动生成你需要的报表）。而且，真正开发时间特别有价值，它不仅是最好的参考，还可以用来推算其它方面的成本。

[Liang Qiao]

真实天数很好，但这个数据的有效性受多方面因素的影响。

最大的因素就是：公司是否用它来衡量每个人的绩效，做考评。

这不仅仅是agile遇到的问题，CMMI也有同样的问题。

曾做过某个使用快速迭代的项目，公司想用它story point来考评我们团队成员的绩效，我的回答是可以记录，以便为公司积累数据，但不做为个人绩效考评。

2008/4/9 Anchuan Qian <qiana...@gmail.com>: