介绍：
对于story来说，一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估中的Function Point,因为story point只是用来粗略的相对的估计story的大小，而Function Point则是用来衡量功能模块的精确大小并且要参与到公式计算的，这里澄清下。
story point的估算是一门很深的学问，而且我们不能马虎，因为如果我们估算少了，那么就会导致实际我们的花费时间远高于估算时间从而导致team加班加点，如果估多了，会导致我们team很闲，team productivity很低，从而会面临削减resource的风险，因为这个很关键，所以我们估算必须要慎重， 而且都必须让一些很有经验的人估算，比如在我们team,这件事情多数由我和一个最资深的前端工程师来共同完成。
实现方式：
其实估算story point要根据历史数据，这些历史数据来源于我们的过去的报表，我们跑了几十个Sprint了，然后我们可以通过很典型的若干的sprint的比较，然后看那些sprint我们团队的运行能力来粗略的估算出我们团队能容忍的合理的story point的区间。
比如我们列出如下的历史数据报表：
就拿最近5个sprint （S35-S39） 来说，我们可以比较 "Planned Story Point"和"Actual Total Effort" 2列。然后结合发生过的事情，有如下的证据：
(1)Sprint 39是一个非常糟糕的例子，因为在这个sprint我在休婚假，所以并没有参与到Sprint Setup Meeting ,然后并没有去估算story point，事后也没时间去重新review, 所以整个团队在一个预先估计的一个很乱的story point下工作，大家都累瘫了。所以，虽然planned story point才22 ，但是实际上团队一共贡献了356.5小时去完成这些分配的story和sub-tasks,以至于最后3天我一看形势不对，我自己都去参与开发写代码了，因为我的主要职责是领导team和技术方面的support,很少能逼我冲到一线去写代码的。最终虽然按时完成了，但是实在太累，我后来反思了下，这个sprint应该安排在40个story point才算合理。
(2)Sprint 35是另外一个极端的例子，这个sprint中，我们team接受了3个新成员，因为他们需要一定的上手期和获得可以使用的账号，权限等，所以这个数据毫无参考价值。
(3)从纵观Sprint 36,37,38，总的说来这3个sprint都是运行的比较稳健的3个sprint,分别是276.2,276,269小时的总effort, 但是Sprint 36,team 非常忙，就算在code frozen day,我们还在做最后的bug fixing.而Sprint 37,我们有很高的质量，ST 只报告了1个defect, Sprint 38，虽然team 不紧不慢，但是我们是在最后一天才完成所有任务的。
所以综上所述，我觉得对于我们的团队来说，放22-26个story point是一个很合理的区间。
总结：
在估算Story Point时候，一定要参考历史数据，历史数据越多，那么分配Story Point总量时给出的数据就更合理，否则无论算多或者算少，对于团队都是不利的。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
