是工作量，而不是复杂度
有个客户问我，“我的团队什么时候才能完成这个项目？”我已经被问过千百次类似的敏捷项目管理问题了。
但却从来没人问过我，“开发这个项目我的团队要费多少工作量去进行思考？”
客户，老板，顾客以及干系人只会关心一个产品要耗时多久，却不会去理会要交付该产品我们得多么殚精竭虑地思考，除非这些必要性的思考会带来时间或成本风险。
我提到这个是因为我发现许多团队认为故事点代表的是用户故事或特性的复杂度，而不是开发时的工作量。
这样的团队经常会将“故事点”重新定义为“复杂度点数”。我猜这更好听一点，也许，也更易接受。
但这是不对的。故事点并不是代表开发一个特性的复杂度，而是开发一个特性所要付出的工作量。
几年前的一堂课上，我碰到了一个很棒的例子。假设一个团队由一个小孩和一个脑外科医生组成。
他们的产品backlog包含了两个条目：粘贴1000张邮票和做一场简单的脑外科手术—剪开，缝上。
选择的这两个条目大概会耗费相同的时间。如果你不同意，可以简单的调整一下邮票的数量。
尽管存在截然不同的复杂度，这两个条目还是应当设置同样的故事点数——因为每个条目预计会花费相同的时间。
这个例子还指出了敏捷估算的另一个方面，就是一般而言，我们认为适合这个任务的人才会去做这个任务。
我们不会去假设那个小孩去读完书，进医学院,然后住院实习七年期满之后才开始大脑手术，
而与此同时我们的一个技术高超的外科医生一直坐在隔壁间贴邮票。
当然，现实中,偶尔会有人做着不该他做的工作,但这很少会像例子中那么戏剧性。
所以，故事点是针对要花费的工作量的。请基于风险和不确定因素等，对需要的花费工作量进行估算值调整。
但是基于故事点的估算是针对花费的时间的，而那才是我们的委托人、老板，客户以及干系人所关心的。
（Scrum中文网经授权翻译及转载，不得复制）
