基本使用方式

故事点的基本做法是：把一些常见的“标准任务”给出一个“标准点数”，形成比较基线，估算的时候只要是同一类型的任务，直接写上故事点数而非天数。比如：

1. 对单个表进行增删改查

2. 为一个已经存在的数据表增加一个复杂报表

3. 修改一个中等难度的BUG

……

在刚开始的时候，“点数”可以就是以往完成任务的平均天数。比如曾经有4次对单个表进行增删改查，查看历史记录发现天数大约是15天，则可以定为15点。以后再碰到类似任务，直接写下“15点”，而不再做太细节估算。

若故事点使用了6个月，假设团队人数不变，而每个月完成的故事点分别为76/82/92/81/102/98，则表明开发效率不断改进。

当然导致故事点生产率变化的不只是开发效率，比如到末期可能测试/部署占用了一些可用开发时间导致故事点减少。因此一般会同步跟进可用时间的变化。

目标

使用故事点后团队工作可能发生一些有益的变化，这是主要的目的，比如：

1. 团队间会横向比较标准点数，并因此获得一定动力

尽管不同团队会选择不同的标准任务，但其间难免有所重合，若一方设置某任务为10点，而另一方为20点，则双方需要进行一定的沟通。

当然不能粗暴地认为两者点数应该相同，但与其说其间的差异反映了团队人员生产率的差异，更可以认为表明了双方架构的易维护性/已有模块的可复用性等方面的差异。对这些差异的合理分析和处理，会带来积极的改进。

2. 估算过程整体可以不太纠结于人员能力差异，而在于“这是什么任务”

在敏捷生态系统（将另有博文详述）中曾提到，估算的目标不在于一个数字，而在于“这是什么任务”及“用什么方式实现最优”。故事点在这一点上比天数更好一些。

一个附加价值是：若一个任务看上去比某标准任务难一些，可以在点数上额外估计几点，防止错过明显的差异。这一点数差异是建立在任务的差异上的，而任务差异的评价过程对未来确定这个任务的范围/标准/方法是很有用的。

3. 借助故事点生产率的变化，可以观测实际生产率的变化

在本文开始已经提到，这是直接用天数无法实现的。

4. ……（任何用直接天数达不到的目标）

倘若在实施故事点后并未达到上述目标（甚至在实施故事点前并没有想好有哪些目标），实施故事点基本上会失败。

国内在业界极少见到使用故事点成功的案例，难点包括：

1. 故事点的项目或产品特征很明显，几乎无法跨团队比较

2. 若没有历史数据，很难设定标准任务

3. 在标准任务没有那么多种类时，很难判断一个新任务到底像哪个标准任务；而太多的标准任务又令人迷惑

有鉴于此，笔者觉得在尝试故事点前，不妨先使用一种中间状态的估算过程：

1. 每个迭代后都记录所有任务的实际完成情况，并形成所有任务的历史完成情况集合

2. 每个计划会仍只估计天数，但大家要随时可以感觉新任务像以往哪个任务，并迅速查找历史（打印一个小册子），根据任务差别在历史数据上增减天数

这种方式无法直接打到故事点的目标，但却可以逐渐建立标准故事集（那些最常被查找的故事），或至少可以帮助大家在脑海中把生产率具象化（“哦，单表增删改查原来要花费15天啊”）。