故事点这个概念，看起来鬼鬼祟祟的。
提到故事点，必然讲到，“不是基于时间的度量（如小时或天数），而是一种相对的估算方法，用来比较不同用户故事的复杂性或工作量”。
谁懂你为什么不用具体时间，而是用相对量？
敏捷联盟不是鼓励勇气和以客户为中心吗？客户真的看到你的故事点，然后如何和他的时间期限比较呢？
我问过一个行业内标杆实践企业的员工，当你估计了一个故事点的点数后，你怎么估计它的时间？
他说，我们项目组约定好，都是一个点就是一天。
这不是障眼法？…干脆一点，你这个月底能不能完成？当你故作专业的时候，客户就只能流氓起来。
我一度以为这个肯特贝克的发明，因为故事点和故事两个概念太接近了。因此我有点怀疑肯特贝克了，然而不是，我查了下，是Ken Schwaber和Mike Cohn主要再说。好像他们两个都是搞Scrum的。
确实，在《极限编程解释》一书中，肯特贝克并没有直接介绍故事点（Story Points）这个概念。
你看，敏捷联盟如果剿灭董卓的18路诸侯一样，也不是铁板一块。