本文为您详细如何用好 CODING 中的故事点功能。
什么是故事点？
在传统 IT 项目中，项目经理往往会对即将开展的项目做出非常精细的成本估算，包括工作量、软硬件设备以及其它成本。不少团队会发现，花了很长时间做好的成本估算，在项目结束回顾时往往与预期大相径庭。传统软件团队通常使用工时估算工作量。工时是一种绝对估值的方式，它的估算方法常常会依赖于历史经验信息。对于流程较为固定、需求较为稳定的团队来说，工时估算方法是适合的。但这种精细的估算往往会制约那类面临着多变复杂情况的团队，因为团队每走一步都要和原来的计划进行比对：工时超了没？deadline 到了没？原计划达到了没？
敏捷估算方法与传统工时估算方法的一个核心区别在相对估算这个概念。在敏捷估算中，没有绝对的估算天数或小时数，而是通过故事点。故事点是敏捷开发模式中一种常见的相对估值方式。也就是说，针对两个需求，我们可以估计这个需求比另一个需求更大，大多少倍，但我们不确定每个需求的准确工作量。
使用故事点有什么好处？
团队成员往往会对日期有情感上的依恋。相对估计消除了这种情感依恋。
每个团队的工作量估算会略有不同，这意味着他们的速度（以点为单位）自然会有所不同。
一旦就每个故事点值的相对价值（或难度）达成共识，就可以快速分配点，而无需太多辩论。
故事点让团队基于难度而非时间来解决问题。这使得团队成员专注于创造价值，而不是专注于花了多少时间。
在实际使用过程，工时和故事点估算没有优劣之分，只有适不适合。但总而言之，良好的估算实践有助于团队掌握项目的成本和盈利能力，还有助于团队对要交付的需求规模、优先级以及价值达成共识，从而更好地作出业务决策。接下来我们来看看如何使用故事点评估。
怎么用好故事点？
使用前提
我们建议使用故事点的团队尽量做到：
采用固定迭代周期（通常是 2 周）。
团队人员相对稳定。
首次使用
首次使用时要做的：团队商量出 1个故事点与此前做过的哪个需求规模等价，让团队有个基准点。
例如：一个“创建xxx页面”功能，算 1 点。那么修改 xxx 功能大概也是 1 点，那么简单搜索功能大概 2 点；也就是说搜索功能在规模上是创建页面功能的两倍。
说明：
故事点用斐波那契数列来度量：1、2、3、5、8 （CODING 用的是改进型）。在近似斐波那契数列中，当数字越大相邻数之间的间隔也会越大，方便识别和对比需求难度。例如：21 与 34 之间的差距非常能够说明差异，但过度纠结于 34 还是 35 就很不敏捷。
主要步骤
在新迭代开启前全体成员开会评估需求故事点。
这里假定团队有敏捷扑克牌（每张牌都写着一个故事点）
每一名团队成员（产品负责人除外）取一种颜色的卡片。
产品负责人描述待预估的 Backlog 项目，并解答团队成员的提问。
团队讨论。
每一名团队成员根据自己的判断进行预估，将预估结果倒扣在桌上。
当所有团队成员都完成预估，大家同时把卡片估值翻转过来。
如果所有人的预估值相等或相近，该值即为 Backlog 项目的点值。
如果团队成员估值差异较大，则需要对预估结果进行讨论。
重复上面的过程，直到团队意见一致。
产品负责人选择下一个 Backlog 项目进行预估。
之所以先把预估结果倒扣，是为了避免成员的从众效应（或服从权威），导致在评估时候随意更改自己的评估结果。
迭代后
迭代回顾会议检查完成的总故事点数并记录下来。
下次迭代能做的总故事点数会参考之前完成的总点数，通常会让每次迭代都稍比上次迭代完成的故事点更多，让团队逐渐提高效能。
写在最后
在实际敏捷开发过程，由于业务本身的不确定性、以及经常会出现新的变化因素、个人的主观因素等原因，导致估算的点数与最终实际情况出入较大。那么以下几个提高故事点效率的方式希望能启发到您：
让任务相关人都参与到估算中。 了解的信息越发全面，得到的结果也更加成熟。同时估算的过程让团队成员们分享各自的逻辑、经验与假设，也有助于团队的步调协同。
参考之前的实际工作。 在回顾迭代时，也回顾和反思估算的准确性，让下一次的迭代估算更加的准确和容易。
选择适合的故事点估算方法。 对于不同类型、规模的项目，所适用的估算方法也不一样。比较受欢迎的估算方法包括：计划扑克（Planning Poker）、T-恤尺寸（T-shirt size）、点投票（Dot Vote）等等。
是
否
本页内容是否解决了您的问题？