一、什么是估点，专业术语其实叫故事点？

是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个符合完成定义的PBI的复杂度，是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队这个PBI的复杂度。 复杂度包括:功能的难易程度、技术熟练程度、纯粹的板砖耗时、风险等。

二、为什么要估点，以及如何估？

在每个迭代的plan meeting会议中，PO将指定PBI做完需求澄清之后，Scrum Team成员确认都理解用户故事的前提的下，进行估点。这个时候，我们需要一个基准用户故事作为参照。这个基准不一定很复杂，也不一定很简单。有个前提是，是提前大家达成的共识。并且把这个基准点作为1个故事点。 当大家使用这个基准点估点的时候，每个人都会思考，这个PBI和基准点比较，应该是基准故事点的多少倍。前面已经说了，这个点数就是复杂度(功能难易、熟练程度、风险等)。 因为每个人对这个PBI的复杂度共识最终还是可能存在差异。导致大家估出的点数还是不一致。这个可能会因为2个点或者5个点而产生争执。有的人考虑的多，有的人考虑的少，有的人踩过坑，有的人还是很茫然。这个时候就需要大家解释和说明自己估算的原因。直到大家达成共识。重新估点。填上大家都认可的故事点数。 所以估点的最大作用是让大家对这个PBI的故事点达成共识。这个共识很重要，因为在团队不管谁来完成这个PBI,他都是认可这个故事点的。避免了胡乱评估，盲目跟风，一家之言，和多明显的风险。

三、常见的误区和风险？

1、把故事点（story point）和预估时间（estimated）当成一样来理解。

故事点是一种相对的估计，并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。 以我们团队举个例子。有A，B，C三个研发。A的能力是B的两倍，B是C的两倍。 同一个点数的用户故事，A只需要0.5天，B就需要1.0天，C就需要2.0天。每个人的能力不同，会影响完成这个PBI的速率。并不会降低这个故事点的复杂度。如果每个人都是简单的这么直接把故事点换算成预估时间。一个迭代按照10天算，每个只需领满自己10天的工作量就可以了。会有产生什么问题呢？ a、各自为战，把自己那部分做完就可以了。不用关心团队其他成员，更不关心团队进度。 b、抗风险能力差。如果能力强的A突然临时请假，其他成员接手他的工作需要更多的时间才能完成，势必会影响整个团队的正常节奏。 c、看不到团队的真实速率。每当PO询问某些用户故事能不能安排到下个迭代时，通常得到的答案是“这要看谁有没有空”。 d、不利于团队成员的成长。C君很难有机会做一些复杂的，对自己能力有提升的工作，因为出于时间成本的考虑，复杂的工作都交给A君来处理。

2、直接粗暴的将故事点数换成小时，或者人天，获取平均值作为评估工作效率的参考或者指标。

a、每个迭代的故事总点数差不多。但是业务内容不同，导致即使相同复杂度的点数，实际的速率也是不同的。 b、每个不能完全排除其他外界干扰。比如on call,临时需求变更，人员请假，延长工时等。

3、以专家顾问或者指定开发预估点数作为PBI的故事点参考

首先专家顾问可以给出一个预估参考值，但是不能作为最终值，因为实际开发的人并不是专家顾问。预估值不能作为共识点。 如果是指定开发预估点数。又会产生把故事点作为预估时间的误区。因为指定开发预估的点数，并不能代表其他研发的共识。如果这个需求分配给其他开发，这将是一个巨大的风险。