最近听到了关于Story Point的不少讨论，结合前一段时间跟User story Applied一书中文版译者之一张博超的讨论，写这篇文章，希望能够回答一些问题。

什么是story point？

《敏捷估算与计划》这本书里给出的定义如下：Story points 是描述用户故事 (user story)、特性(feature)或者其他工作的总体规模的计量单位。

为了有助于理解这个稀奇古怪的定义，举个例子：

 

小刘：小王，你住哪里？

小王：世纪公园

小刘：这么爽，地铁3站路就到了

小王：是啊，以前几年前世纪公园房价还不贵，正好就买了一套，你呢？住哪？

小刘：我啊，我现在房子租在东昌路了，上班比你远两倍呢

小王：还好啦，你那边房租多少钱？

小刘：2000块，我打算最近换个房租便宜点的房子，在共康路那边，和朋友合租

小王：共康路在哪，好像没去过啊？

小刘：要二号线换一号线，过来有将近20站呢

小王：看你这换的，跑这么远，以后上班有得你折腾了

小刘：是啊。没办法，物价太贵了，只能舍近求远了

 

类似地铁站提到了“站”的概念，大家对一站路有了共同的认识，才能通过几站这个描述来指代距离；相反，如果小刘跟一个刚从圣地亚哥过来的美国人说距离20站地铁，对于惯于开车的老美，他也许只会笑笑就过了。

用Story Point干什么？

 

Story Point跟“站”的概念类似，它就是用来衡量User Story的规模的。在一个团队的理解中，一个5点的User Story在规模上比2点的要大，估计在2倍左右。

 

对Story Point能够在发布计划(Release plan)中有效的帮助评估风险。

 

还是铁的例子，假如小王要在浦东机场坐11：40出发的飞机，除去安检、登机的手续，他要11：00前到机场。

小王如何计划自己的行程并且不会误点？同事告诉小王，从他家世纪公园站出发到浦东机场大概得有十四五站的样子，中间还要换一次车，根据以往的经验，小王知道大概一个站路需要三到四分钟左右，小王比较保守，他算下来地铁上得花15*4=60分钟，一个小时左右，考虑要换乘，小王决定多留点缓冲时间，提前了一个半小时出门，所以他9：30就赶到世纪公园地铁站等车了。

 

同样的道理，Release plan时期，假设根据历史数据，一个release的容量为150个Story Point，团队很有可能在下一个Release里面完成150个点左右的User story，这样Backlog里面优先级最高的总和为150个Story Point左右的那些User story是最有可能完成的。

可以用时间来估算吗？

 

用时间来估算User story，简单且易于理解，甚至团队外的人也能很快明白User Story的规模，好处是老板和相关人心里都比较有数。目前很多团队也在用时间作为User story的计量单位。

 

小王：小刘，你爱看NBA吗？

小刘：偶尔看看，上次看了场马刺对快船的，打打停停，前后算下来40分钟的比赛打了两个半小时。

小王：是啊，马刺采用对中锋犯规战术，一会就要罚球，快船的中锋都被侵犯得没脾气了，这中间停顿就花了不少时间，算下来一场40分钟的球40分钟肯定是打不完的，至少都得要2个小时。

 

在开发团队里面有类似的事情，团队成员每天不仅仅是坐在座位上开发和测试，还有许多与计划的User story没有直接贡献的事情，比如花时间跟PO一起做Backlog grooming、开会、休假、打电话、发邮件、培训、给客户演示、面试等等。因为这些原因团队经常遇到的问题是，估算的1天User story或许要花2天甚至更多时间才能完成。

用时间来估算User story，可以精确到某个时刻。一个1天半的User story，如果今天早上开始工作，理想状态下后天中午1：00这个Story可已完成，这是个很精确的数据，却没有人会相信这个数据的正确性，很有可能这个User story是在后天早上或者第三天晚上才能完成。

 

时间估算虽然更加精确，谁都知道这个估算精确而不准确。因此有的团队在估算的时候会预留一些缓冲以平衡估算误差，比如有的团队会留30%的团队总时间，用作会议等等对当前团队Backlog没有直接贡献的活动，这种做法很大程度上缓解了对时间的精确估算的偏差带来的风险。

 

Story Point是一个相对数值，User story随着时间的推移，其规模不会有显著的变化。随着项目推进和团队技术与知识的积累，团队在第10次迭代中单位时间里面能够完成的工作量跟第一次迭代能够完成的工作量是有所不同的，而在发布计划 (Release Plan) 中规划的事项越往Release后期实际情况跟预估差别会越大，导致相对更大的风险。

其实用时间做估算再往前推进一步就成了Story Point的方法了，根据过去的数据统计团队的容量(Capacity)，而非仅仅只是算可用的时间；用比较倍数的方法考量User story的大小，而非考量完成所需的时间。

 

理想时间还是故事点？

尽管Story Point有很多好处，它的理解和真正实施起来是需要有个适应摸索过程的，需要由团队共同努力找到都比较舒服的平衡点。

即使是Mike Cohn也仅仅只是建议用Story Point，如果团队对时间感觉比较舒服的话不必过多纠缠于此。目前对于敏捷团队来说，如何准备backlog，如何把大User story拆分成小粒度的User  story组合，TDD等软件工程实践较之是否使用Story Point带来的回报更大。

团队间共享Story Point？

各团队间是否需要统一Story Point的规模？地铁的一站和公交车的一站是不一样的计量单位，对于不同的产品线上的团队，二者一般也不会混为一谈；如果对于工作在相同Backlog上的不同团队，采用统一的基准是有价值的。

现实例子

有这么个例子，两个User Story分别叫A和B，其内容是开发结构类似的报表，这两个如何估算？

在Release Plan时，对A和B的规模估算都是8。开发过程中，迭代1期间团队花了很多研究的时间把A完成了，那么迭代二B的规模是否应该继续为8？此处需要一分为二的回答，迭代1末期，PO需要跟团队一起对Backlog进行重整，此时，如果团队对B仍然没有足够的自信，B的估算可以保持在8，否则B的规模可以变成5或者更少，取决于团队在此的领域知识。

疑问在于如果对B的估计变成3，团队此时能够发布的价值更多，但是在Story Point层面并没有体现出来。换句话说，对B的估算保持8点是否会让团队效率感觉更高？

 

仔细想想，其实做A的时候已经把B的很多东西相应的做掉了，因此B的不确定性降低，风险也降低了，对B的规模估算降低是合理的。另外Story Point并不能用来衡量团队的效率，团队实际生产速率是会保持在一个相对稳定的统计学数值上的，一个团队在一个迭代周期实际完成的Story Point跟速率相差过大，非但不能说明团队的效率高，反而能看到团队之前估算不准确，这是个问题，需要在回顾会议里面讨论问题的原因并做出改进。

那速度怎么办？

 

 

 

 

 

 

 

团队速度(velocity) 是团队进展速率的度量。它是通过对团队已完成的迭代里面所以User story的点数总和计算的出的；随着项目往前推进，团队速度变得更加明晰，速度也会相对稳定。团队的目标也是达成相对稳定的速率以保持release的风险更加可控。