> 我们使用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
> - - - - - - - - - -

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

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

> > 我们使用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
> > - - - - - - - - - -

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

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

> > 我们使用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
> > - - - - - - - - - -

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

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

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

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

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

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

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

> > > 我们使用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
> > > - - - - - - - - - -

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

> 我们团队用xplanner跟踪过一段时间,得到过大概的评估小时->实际工作小时 比率.
> On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:

> 我们使用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
> - - - - - - - - - -

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

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

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

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

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

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

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

> > > > 我们使用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
> > > > - - - - - - - - - -

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

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

> > 我们团队用xplanner跟踪过一段时间,得到过大概的评估小时->实际工作小时 比率.
> > On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:

> > 我们使用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
> > - - - - - - - - - -

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

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

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

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

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

> > > 我们团队用xplanner跟踪过一段时间,得到过大概的评估小时->实际工作小时 比率.
> > > On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:

> > > 我们使用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
> > > - - - - - - - - - -

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

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

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

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

> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
>         请站在公司财务或者部门经理的角度，去试着做下一年的预算，你就知
>         道你想要什么数据了。但这些数据用在个体上，显然不适用。

>         2008/4/9 徐毅 <kaverj...@gmail.com>:
>                 可以的话能否share下这方面的经验，这个比率你们怎么用
>                 它，然后有啥好处啊

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

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

>                         On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:
>                         > 我们使用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
>                         > - - - - - - - - - -

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

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

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

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

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

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

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

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

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

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

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

> > > 我们团队用xplanner跟踪过一段时间,得到过大概的评估小时->实际工作小时 比率.
> > > On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:

> > > 我们使用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
> > > - - - - - - - - - -

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

> On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
>> 不好意思，从没接触过预算，这方面没经验。确实不
>> 知道这个"评估小时->实际
>> 工作小时 比率"如何影响到年度的预算。

>> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
>>        请站在公司财务或者部门经理的角度，去试着
>> 做下一年的预算，你就知
>>        道你想要什么数据了。但这些数据用在个体
>> 上，显然不适用。

>>        2008/4/9 徐毅 <kaverj...@gmail.com>:
>>                可以的话能否share下这方面的经验，这个
>> 比率你们怎么用
>>                它，然后有啥好处啊

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

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

>>                        On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:
>>> 我们使用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
>>> - - - - - - - - - -

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

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

> 基本上是这样.
> 其实我觉得跟徐毅说的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:

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

> > 吧 ？ 我的理解有错没有，请指
> > 正。

> > On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
> >> 不好意思，从没接触过预算，这方面没经验。确实不
> >> 知道这个"评估小时->实际
> >> 工作小时 比率"如何影响到年度的预算。

> >> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
> >>        请站在公司财务或者部门经理的角度，去试着
> >> 做下一年的预算，你就知
> >>        道你想要什么数据了。但这些数据用在个体
> >> 上，显然不适用。

> >>        2008/4/9 徐毅 <kaverj...@gmail.com>:
> >>                可以的话能否share下这方面的经验，这个
> >> 比率你们怎么用
> >>                它，然后有啥好处啊

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

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

> >>                        On Apr 9, 2008, at 1:02 PM, 徐毅 wrote:
> >>> 我们使用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
> >>> - - - - - - - - - -

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

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

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

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

>         基本上是这样.
>         其实我觉得跟徐毅说的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:

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

>         > 吧 ？ 我的理解有错没有，请指
>         > 正。

>         > On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
>         >> 不好意思，从没接触过预算，这方面没经验。确实不
>         >> 知道这个"评估小时->实际
>         >> 工作小时 比率"如何影响到年度的预算。

>         >> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
>         >>        请站在公司财务或者部门经理的角度，去试着
>         >> 做下一年的预算，你就知
>         >>        道你想要什么数据了。但这些数据用在个体
>         >> 上，显然不适用。

>         >>        2008/4/9 徐毅 <kaverj...@gmail.com>:
>         >>                可以的话能否share下这方面的经验，这个
>         >> 比率你们怎么用
>         >>                它，然后有啥好处啊

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

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

>         >>                        On Apr 9, 2008, at 1:02 PM, 徐毅
>         wrote:
>         >>> 我们使用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
>         >>> - - - - - - - - - -

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

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

>         - - - - - - - - - -

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

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

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

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

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

> >         基本上是这样.
> >         其实我觉得跟徐毅说的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:

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

> >         > 吧 ？ 我的理解有错没有，请指
> >         > 正。

> >         > On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
> >         >> 不好意思，从没接触过预算，这方面没经验。确实不
> >         >> 知道这个"评估小时->实际
> >         >> 工作小时 比率"如何影响到年度的预算。

> >         >> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
> >         >>        请站在公司财务或者部门经理的角度，去试着
> >         >> 做下一年的预算，你就知
> >         >>        道你想要什么数据了。但这些数据用在个体
> >         >> 上，显然不适用。

> >         >>        2008/4/9 徐毅 <kaverj...@gmail.com>:
> >         >>                可以的话能否share下这方面的经验，这个
> >         >> 比率你们怎么用
> >         >>                它，然后有啥好处啊

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

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

> >         >>                        On Apr 9, 2008, at 1:02 PM, 徐毅
> >         wrote:
> >         >>> 我们使用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
> >         >>> - - - - - - - - - -

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

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

> >         - - - - - - - - - -

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

> 比如说有一个product
> backlog，内有若干item。在场的会大概扫描一下list，然后挑选一个size居中的item出来，分析其技术难度，及所需effort等，然后设为 3个story
> point大小，为方便，称此item为"标杆item"。之后针对其他的item进行评估，以相比前面的"标杆item"的技术难度等，估出相对大小，比如i tem
> 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 <blackange...@gmail.com> 写道：

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

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

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

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

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

> > >         基本上是这样.
> > >         其实我觉得跟徐毅说的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:

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

> > >         > 吧 ？ 我的理解有错没有，请指
> > >         > 正。

> > >         > On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
> > >         >> 不好意思，从没接触过预算，这方面没经验。确实不
> > >         >> 知道这个"评估小时->实际
> > >         >> 工作小时 比率"如何影响到年度的预算。

> > >         >> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
> > >         >>        请站在公司财务或者部门经理的角度，去试着
> > >         >> 做下一年的预算，你就知
> > >         >>        道你想要什么数据了。但这些数据用在个体
> > >         >> 上，显然不适用。

> > >         >>        2008/4/9 徐毅 <kaverj...@gmail.com>:
> > >         >>                可以的话能否share下这方面的经验，这个
> > >         >> 比率你们怎么用
> > >         >>                它，然后有啥好处啊

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

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

> > >         >>                        On Apr 9, 2008, at 1:02 PM, 徐毅
> > >         wrote:
> > >         >>> 我们使用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
> > >         >>> - - - - - - - - - -

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

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

> > >         - - - - - - - - - -

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

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

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

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

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

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

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

> On 09/04/2008, 徐毅 <kaverj...@gmail.com> wrote:

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

> > 比如说有一个product
> > backlog，内有若干item。在场的会大概扫描一下list，然后挑选一个size居中的item出来，分析其技术难度，及所需effort等，然后设为 3个story
> > point大小，为方便，称此item为"标杆item"。之后针对其他的item进行评估，以相比前面的"标杆item"的技术难度等，估出相对大小，比如i tem
> > 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 <blackange...@gmail.com> 写道：

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

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

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

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

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

> > > >         基本上是这样.
> > > >         其实我觉得跟徐毅说的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:

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

> > > >         > 吧 ？ 我的理解有错没有，请指
> > > >         > 正。

> > > >         > On Wed, 2008-04-09 at 14:20 +0800, 徐毅 wrote:
> > > >         >> 不好意思，从没接触过预算，这方面没经验。确实不
> > > >         >> 知道这个"评估小时->实际
> > > >         >> 工作小时 比率"如何影响到年度的预算。

> > > >         >> 在08-4-9，Liang Qiao <sagittatius.q...@gmail.com> 写道：
> > > >         >>        请站在公司财务或者部门经理的角度，去试着
> > > >         >> 做下一年的预算，你就知
> > > >         >>        道你想要什么数据了。但这些数据用在个体
> > > >         >> 上，显然不适用。

> > > >         >>        2008/4/9 徐毅 <kaverj...@gmail.com>:
> > > >         >>                可以的话能否share下这方面的经验，这个
> > > >         >> 比率你们怎么用
> > > >         >>                它，然后有啥好处啊

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

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

> > > >         >>                        On Apr 9, 2008, at 1:02 PM, 徐毅
> > > >         wrote:
> > > >         >>> 我们使用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
> > > >         >>> - - - - - - - - - -

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

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

> > > >         - - - - - - - - - -

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