共计 1109 个字符，预计需要花费 3 分钟才能阅读完成。
故事点是一个度量单位，用于示意实现一个产品待办项或者其余任何某项工作所需的所有工作量的估算后果。
当采纳故事点估算时，咱们为每个待办项调配一个点数。待办项估算后果的原生数据并不重要，咱们只关注最初失去的绝对估算后果。一个估算值为 2 的用户故事应该是估算值为 1 的用户故事的 2 倍。而它也应该是另一个估算值为 3 的用户故事的三分之二。
团队不要采纳 100、200、300，或者 1 百万、2 百万、3 百万，而要应用 1、2、3。估算后果是比值，而不是绝对值。
故事点包含什么内容
因为故事点数代表了开发用户发故事所需的全副工作量，所以团队的估算必须思考到影响工作量的所有因素。这可能包含：
要发展的工作的数量
工作的复杂度
要发展的工作中存在的任何危险或不确定性
在用故事点估算时，必须要思考以上每一个因素。让咱们看看每个因素是如何影响故事点的。
要发展的工作数量（The Amount of Work）
如果要发展的工作越多，工作量的估算值当然就会越大。思考两个网页开发的案例。第一个网页只有一个字段和一个要求输出姓名的标签。第二个网页有 100 个只须要输出一小段文本的字段。
第二个网页并不比第一个网友更简单。字段之间是不存在交互的，每个字段只不过是一点文本而已。因而第二个网页并不存在额定的危险。这两网页之间的惟一区别就是第二页有更多的事件要做。
应该给予第二个网页更多的故事点数。但它即便有多了 100 倍的字段数，可能依然得不到多 100 倍的点数。毕竟，因为规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的 2 或 3 或 10 倍。
1 story point 是用来评估一个工作（Product Backlog）的难度，跟小时数没有必然的关系。Story point 须要应用斐波那契数列来示意（1,2,3,5,8…）。只所以用这个序列是要更好的显示差别。
2 对管理层和 team 的作用是，你一个 sprint 实现了多少个 point 能进行显示，那么通过多个 sprint 之后你就能看到这个 team 的 velocity 了！
3 Scrum 是头对头，因而是所有的 team 成员进行投票。每人一副 12358 的扑克牌，进行投票并对决探讨为什么这个 story point 是这个数字。此时不晓得谁是执行人，缩小认知偏差。
4 不蛋疼。a. 如果是一个难度是 3 的 PBI，甲程序员实现可能 10h，乙程序员可能须要 8h，这个是一个方面。b.Sprint planning 的时候你须要输出每个人的 capacity 吧，输出这个小时数就能看见一个程序员是不是超工作量了。c. 输出完 orginal time 和 remaining time 就能产生 burning down chart。这个 chart 对开发过程的重要性不必多解释了吧。
