前两篇文章介绍的是 搜集故事和编写估算，本篇文章接着前面的文章往下说，有了story（故事）之后如果对故事进行估算
下面主要是进行估算的大体checkLists
对与一个故事的估算方法应该具有如下特点
1、运行改变估算结果
2、适用于所有的故事
3、很容易很简单的进行估算，不需要花费太多时间
4、提供进度和剩余工作的主要信息
5、计算不准确也不会有大问题
6、估算的结果可以用来指定发布计划
一、以故事点的形式进行估算
故事点估算可以很好的满足上面的特点的估算方法。团队可以自定义合适的故事点，我们组内偏好把一个完美工作日作为一个故事点进行故事估算。
完美工作日就是理想工作日，一天8个小时内一直在编码没有任何其他的情况。当然现实情况可能不太相同.所以一个完美工作日！=一天
二、以团队估算
故事点应该是由整个团队进行估算，团队中的大部分成员都要参与故事的故事点估算，每个人都把自己的估算结果说出来，最后大家再定一个所有人都认可的故事点
三、如何进行估算
1、所有参与的客户和开发人员聚在一起
2、从第一个故事开始，详细讲解故事直到所有的人都清楚了解这个故事
3、每个开发人员都先写下自己估算的值，一故事点为单位 ，例如 2完美工作日(2天)
4、大家都展现自己的估算，然后每个人都说一下为什么估算出这个值
5、最后经过论证团队估算出一个所有人都认可的值
6、继续下一个故事的估算
有了解SCRUM的朋友应该可以感受到上面的流程基本上和SCRUM估算故事的流程是一样的.
四、对评估的结果做三角测量
在做了几个估算以后，对估算结果做三角测量，具体做法如下
在估算一个故事时，根据这个故事与其他一个或多个故事的关系来估算，假定一个故事估算为4个故事点，第二个故事为2个故事点，把这2个故事放在一起考虑的时候，程序员都应该认可 4个故事点的故事是2个故事点的故事的2倍
其他3个故事点的故事的大小应该介于4个故事点的故事和2个故事点的故事之间。
如果上面的三角测量的结果不对，团队就应该重新估算。
五、结对编程对故事点的影响
如果使用结对编程，故事点的估算应该是结对后进行的估算
小结
用故事点估算故事，故事点是故事复杂度，工作量或工期的相对估算
应由团队进行估算故事，估算属于团队而不是个人
听过其他估算进行比较做三角测量
团队是否使用结对编程对故事点估算没有影响，结对编程影响的是团队的速率，不是他们的估算
开发人员的职责
负责用一个方式定义故事点，并且对团队可用和相关的，努力保证这个定义是一致性
负责给出诚实的估算，不屈服于诱惑活压力而给出低的估算
负责以团队估算
负责估算应与其他估算一致，即所有相同故事点的故事的大小都是差不多的
客户职责
参与估算会议，回答问题和澄清故事细节。
