克强在“敏捷中国”讨论组中引发对敏捷的估计的讨论（“Scrum sprint plan中规模估算的做法调查”，“关于story point的单位”）。我想分享一下我自己对敏捷估计方法的理解以及对于“故事点”的认识。
在敏捷开发中，团队通过两种方法对迭代做计划。
基于承诺”Commitment”。做法很简单：
Product Owner从Product Backlog中取下一个用户故事（按照优先级），对这个用户故事进行解释，
团队对用户故事进行讨论，明确需要解决的问题，
整个团队确定是否能够在下一个迭代周期中完成这个故事，
如果团队没有信心完成该故事，计划会议结束，或者把这个用户故事进一步划分成更小的用户故事重复第一步。
如果团队有信心完成该任务，重复第一步。
基于速率”Velocity”
确定Product Backlog中用户故事的规模（用“故事点”）
确定团队迭代的开发速度（“昨天的天气”）
从Product Backlog中取出相应量的用户故事。
基于速率的估算中，需要确定一个“故事点”，也就是确定一个速度的单位。而在敏捷计划与估计中，这个“故事点”是没有单位的。为什么？首先来看一下传统的规模估计的方法（标准日、代码行数）的问题。
绝对估计 vs. 相对估计
传统的方式是通过计算出一个绝对值（有单位，比如多少人天，多少代码行）。然后，做出计划。很大的问题是，人天生不擅长做绝对估计，人们更擅长做相对估计，更容易在相对估计值上达成共识。举一个简单例子，估算从上海市人民广场到徐家汇的距离，如果使用公里或者米等绝对单位，多个估计者很难达成共识，往往陷入没有必要的讨论和争吵。而如果用相对距离，比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离，人们就很容易、很快达成共识。因此对一个需求点来说，关注于相对大小也更容易使整个团队在估计值上达成共识。
关注规模（而不是将不同维度的概念混淆）
比较合理的估计方法是，首先估计整个规模，然后有一定的历史数据，知道速度，从而可以做出计划，推算出时间。比如我们看书，一共三百页，一天看十页，很容易就算出是三十天。如果使用理想日（时间维度），其实就是把这个过程搞反了，从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等，基于故事点的规模估计是在综合考虑各种因素之后的综合估计。而用代码行数很难对复杂度、不确定性等作出估算
忽略个人能力的不同
不同人的理想日和代码行数估算是不同的，是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子，每个人的能力是不同的（有人步行、有人跑步、有人公车、有人地铁、有人开法拉利），但是所有人得出的相对规模值还是一样的。因此使用相对规模估计就可以不需要考虑这种个人能力因素。
不可相加
传统估算方式的一个很大的问题是，估计不能相加。每个人的理想日是不一样的，这样成员甲的估算（理想日）就不能和成员乙的估算（理想日）相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中，需要整个团队一起对任务进行估计，因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此，为什么“故事点”没有单位？
首先，故事点是一个相对量，相对值是没有单位的；小学乘法：被乘数 × 倍数 = 积。故事点估计值就是这个倍数。
其次每个团队的单位“故事点”是不同的，很难也不需要统一。
最后，其实敏捷的计划估计与传统的计划估计很大的不同是对计划的态度。在敏捷开发中，计划估计只是一个对未来的预测，因为是一个预测，所以总是有不确定性。敏捷开发计划承认这种不确定性，因此对计划估计的态度应该是不断根据新的发现，对计划进行不断的调整，但是不需要过于关注预测的准确性（我们的工作是为客户开发有用的软件，而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效，那其实大家也该考虑换一个地方了，这又是一种局部优化）。