文章

根据待办列表中的一项估计整个列表

在本文中我想讨论一下最近经常被提及,几乎每个月都要被问到的一个问题。这个问题就是我们如何能够在没有可参考的历史数据的情况下,估算完成整个产品待办列表中所有项目所需要的时间。

我的建议是,在没有能够试行第一个Sprint之前,不要轻易给出答案。但是,我们总是要应对各种特殊情况的。在我们无法试行一个Sprint的情况下,可以举行一到多次的承诺驱动的(commitment-driven)的Sprint计划会议,然后根据这些数据来预计可能的速率。

当然,有的人总是喜欢使用小时,而不是速率,他们希望能够估计出完成产品待办列表所需的小时数,从而估算出整个项目周期(然而通过速率反而能够更直接的估算项目周期)。但是,既然这是一个普遍问题,我就希望能够解决它。

下面是经过我简化和提炼的实际问题:

我们没有历史的速率数据。我们有一个包含300个用户故事的产品待办列表。所有的用户故事都已经完成估算了,大多数都在3到13个故事点数左右。下面的方法合理吗?
1. 随机选择40个用户故事。
2. 把这些用户故事都分割成任务,然后对人物进行估算。
3. 然后可以得出每个用户故事的平均小时数。

例如,假设我们随机选择了40个用户故事,总共有150个用户故事点数,然后通过估算,完成这40个用户故事总共需要600小时。那么我们就可以得出每个用户故事点数大概是4个小时了吗?

嗯,是的,但是这种方法有下面两个问题:

1. 千万要记住故事点数和小时数并不是对等的关系,不能相互转换。我们不能够像上面的例子那样说1个故事点数就等于4小时。1个故事点数大约等于4个小时加上标准差,假设是45分钟。这就是说,在68%的情况下,1个故事点数等于3个小时15分钟到4个小时45分钟,在98%的情况下,1个故事点数等于2个半小时到5个半小时,也就是2个标准差。
2. 以上的方法假设1个故事点数的用户故事和13个点的用户故事是按照相对估算的。也就是说,如果1个故事点数为1的用户故事如果需要4个小时,那么一个13点的用户故事就需要13X4=52个小时。由于各种原因,这种推断并不成立。根据我收集的很多团队的数据表明,正如我们所预期的一样,团队并不是完美的。

那么我们怎么样才可以解决这些问题呢?第一个简单的解决方案就是,我们计算出每种大小的用户故事所需要的平均小时数,而不是把所有大小的用户故事合起来一起计算。例如,在上面的例子里40个用户故事总共是150个故事点数和600小时,然后得出每个点数等于4小时的结论。但是,如果我们把所有故事点数为1的用户故事来做计算,我们有可能会发现1个故事点数等于3.2个小时。同样的道理,我们可能发现2个故事点数的用户故事可能是1个故事点数等于4.3个小时,而用3个故事点数计算的时候,1个故事点数等于4.1个小时。

然后,我们就可以将平均小时数和对应的用户故事个数相乘得出每种大小的用户故事所需要的总时间。如下表所示:

 

 故事点数  每个用户故事对应小时数   用户故事个数   总时间
 1   3.2   5   16.0
 2  8.6  8  68.8
 3   12.3   7  86.1

我们首先要注意的是,在上表中的第二列是每个用户故事对应的小时数而不是每个故事点数对应的小时数。一个故事点数为2的用户故事每个故事点数等于4.3小时,所以一个这种大小的用户故事总共需要8.6小时。

 

这个表格告诉我们,故事点数为1的用户故事一共有5个,每个需要3.2小时。最后把最后一列的总时间相加就是170.9个小时。

在这里需要注意的是,这种方法会包含所有在分割任务和估算时间中的缺点。由于通常团队会无法一次过确认所有任务,所以这种方法只能估算出能够在会议上找出的任务所需要的总时间。因此,这种估算方法将需要后续的调整工作。我将会在后续的文章中讨论对这种简单方法的改进方案。

作者:Mike Cohn

原文地址:http://blog.mountaingoatsoftware.com/estimating-a-full-backlog-based-on-a-sample

是有序!不是按优先级排序!

scrumcn1314947432

在过去,Scrum指南里面通常使用优先级来描述产品待办列表,或者写明产品待办列表是根据优先级来排序的。当产品待办列表必须是有序的时候,优先级排序是仅有而且难得的好办法。但最近,新的Scrum指南里面使用了有序(ordered)这个术语,而不是按优先级排序(prioritized)。这反映了很多在Scrum社区中的领导者长期以来的理解。让我们来看看改变的原因。

按优先级排序就是说根据各个项互相之间的重要程度之间的差异来进行排序。其中优先级驱动着两个在列表中的项目的比较。这很容易让人想起使用冒泡排序来进行对产品待办列表的排序:比较最顶端的两项,如果它们的顺序就是错的就交换它们,然后对接下来两项进行比较,然后重复这种操作直到所有项都到达了正确的位置上。排列优先级和排序之间的关系十分紧密。

在给产品代表列表排序时,Scrum团队和Product Owner会按照最大化投资回报率或者价值的目标进行排序。然而,很多人普遍认为投资回报率就是优先级。其实,投资回报率是对待办列表的长期投入和产出的结果,而并非简单地将待办列表中的各项的投资回报率相加。在某种程度上这是正确的,因为待办列表中的一项的投资回报率取决于其在待办列表中的位置。例如,假设有一个用户故事是要在网站的首页上显示一个会跳舞的圣诞老人。这个用户故事能够在十一月底到十二月期间带来一定的回报,但是如果是在七月或者是一月,回报就会大大减少了。当你改变用户故事在待办列表中的位置的时候,实际上你已经改变了它的投资回报率了,因为由于它的位置的改变,其发布的日期也会有所变化。

因此,产品待办列表必须要排序,顺序决定了产品待办列表中的项目的交付次序。团队可以就待办列表中的顺序和Product Owner进行讨论,但是当团队从中拿出用户故事的时候,必须先从最顶端的开始拿。其实,产品待办列表并不能保证其反映的一定就是其中各项的价值或者优先级。你不能因为某一项的投资回报率或者商业价值就直接给定其优先级,你必须要通盘地考虑待办列表中的所有项,才能够使得最终的投资回报率最大。

比如说,你要在热带里建一座房子,你要考虑到每天午后的大雨。你能够预见到一座房子必须有墙、窗户和门,但是屋顶才是你最关心的问题。然后,假如你要给你建造的房子建立一个产品待办列表,这时候很显然屋顶是最需要考虑到的,但是你真的会把建造屋顶放在第一位吗?这个就是要对代表列表进行排序来最大化长期投资回报率的时候了。这个过程需要对产品待办列表中的商业、市场以及工程学依赖关系都有清晰深刻的了解。这很明显是一个比单纯的冒泡排序要复杂得多的过程。

使用“排序”而非“排列优先级”就是为了要让Product Owner知道,他们必须要对用户故事的顺序做决定,而不是只是简单的说“这五个用户故事优先级是1,那三个优先级是2”。
Product Owner必须交付一个已经完成排序的产品待办列表。

当然,你完全可以使用优先级来作为排序的依据,因为“排列优先级”也是其中一种排序的方法。使用“优先级”来排序有可能会导致投资回报率的降低。Jeff Sutherland经常说,如果你的产品待办列表的顺序足够好的话,你甚至可以让你的投资回报率翻倍。当然,有些例外的情况,例如有时候你的团队需要给一些客户做一些固定成本的项目(详情请查阅Change for Free 和 Money for Nothing),这些只是一些特殊的情况,并不是对所有团队和公司都适用。Scrum指南也不提倡这种做法。总而言之,你不应该使用优先级来进行排序。

作者:James O. Coplien

原文地址:http://www.scrumalliance.org/articles/367-its-ordered–not-prioritized