story points应该怎么使用

故事点是一个度量单位，用于表示完成一个产品待办项或者其余任何某项工做所需的全部工做量的估算结果。

当采用故事点估算时，咱们为每一个待办项分配一个点数。待办项估算结果的原生数据并不重要，咱们只关注最后获得的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另外一个估算值为3的用户故事的三分之二。

团队不要采用100、200、300，或者1百万、2百万、3百万，而要使用一、二、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对开发过程的重要性不用多解释了吧。