背景：
M阅读是业内知名的一款阅读APP，从今年8月份起，为了适应快速的市场变化，版本规划从以往的4周一版，演变为2周一小版，4周一大版的方式发布。需求的下发，按月度规划，由版本经理和需求经理统一安排下发。
长期以来一直存在一个问题，版本经理和需求经理与团队对于工作量的裁定是以人天作为单位，采用团队能承接多少人天需求来安排需求。迫于市场，运营，甚至总部的压力，会给团队安排更多人天的需求，而团队为了能准时完成的交付任务，避免延期的风险，往往在人天估算中加入很多Buffer，或者以超出团队承载能力为由，拒绝接收需求。长此以往进入了一种恶性循环，一方面版本经理/需求经理观察到人天估算里有水分，会敦促团队承接超出团队承载量的需求，一方面团队会在下一次人天估算里加入更多水分，以减缓超出承载的需求交付压力。
人天估算的构成：
人天估算的构成中往往包括两个部分，一是客观的实际工作量，二是团队的主观因素，比如个人技能水平，团队联调等待，数据准备，团队公共人力等。这些因素的存在让人天估算不能准确的反映客观的工作量，同时也遮盖了团队开发过程中存在的浪费，浪费本身反而成为团队输出的工时构成之一，这很不合理。
如何以更科学的方式，让团队愿意承接更多的需求？如何避免估算的工作量越来越多，而产出却毫无变化？如何让估算本身成为敏捷团队有意义有价值的活动？
引入故事点估算：
故事点估算实际上是一个综合的对于用户故事的复杂度，工作量，风险或不确定性等，针对不同的用户故事类型设计不同的基准故事点。
Story Point＝f(E,R,U,C)
工作量（Effort）：开发一款个人信息的web页面 VS 多款web页面
复杂度（Complexity）：页面包含不同的组件，比如包含日期，信用卡号，省份等复杂度不同
风险（Risk）：改动底层敏感模块，破坏现有功能。
不确定性（Uncertain）：需求开发初期不清晰的情况。
相对大小
故事点估算是相对概念，所以它允许即使具备不同能力的人，也可以达成一致的故事点估算。
假设孩子和成年人从家里出发到学校（1x距离），可能孩子走20分钟才能到达，大人只需要10分钟，但如果他们在这个距离上达成一致意见，即这就是1个故事点，同理在从家到医院的路程上（3x距离）大人和孩子都可以给出3个故事点的估算。
相对大小是团队估算的基础，有了相对估算，团队估算才可以有效实施。
团队估算：
故事点估算采用团队估算的方式进行，个人觉得这是故事点估算最大的意义。
以往一个需求只有一个专家分析，大部分团队成员只负责写代码，需求分析的质量全取决于专家。首先专家的资源有限，经常会成为团队的瓶颈，其次专家是人不是神，也会存在分析遗漏。其次团队其他成员每个迭代每个迭代接触的需求有限，往往各人自扫门前雪，开发哪个需求关注哪个需求，各自独立作战，团队能力成长缓慢。
团队估算的引入，一来会给与更多团队成员分析需求的机会，激发了团队分析思考的热情，促进了团队分析能力的快速培养。二来，在估算的过程中，团队一起碰撞讨论需求，使得对需求的理解更加清晰，更贴近用户的需求，开发风险暴露的越充分。
估算如何在团队间对齐：
故事点估算并不是基于公式的定量估算，因此没有准确的标尺，明确的告诉所有的团队多少工作量是一个故事点。一般来说，故事点一般用作团队内部，团队与团队之间的故事点基准可能完全不同。
但在项目组内，一个特性组的组长往往带领多个团队，在一个特性组内部的多个团队，有统一故事点的需求。因为需求的下发到一个特性组场后，经常在不同团队之间调配，如果一个团队估算完需求故事点，调配到另一个团队的时候需要重新估算，很浪费时间。因此在应用上，一个特性组内部的多个团队之间，形成统一的故事点标准。
首先，为了方便起见，估算我们采用的是在一个“理想人天”里可以完成的工作量作为一个基准故事点。以此为基准，团队和团队之间差别不会特别大了。
其次，由组长作为各团队对齐的一个标杆，组长会参与到各组的故事点评估，如果有发现各组标准不一致，组长可以当场提出来进行故事点调整。
需求太小，必须做团队估算吗？
在我们的团队中，存在这样一种情况，往往一个迭代，团队要接纳4，5个或者更多的需求，而这些需求大小不一。有些需求较大，需要好几个开发测试配合才可以在一个迭代内部完成。大部分都是小的需求，这样的需求只需要一个人很短的时间内就可以完成。而针对这些小的需求，往往只需要一个团队成员进行分析即可。如果让所有的团队成员都去了解，分析，并进行估算，团队会认为没有必要，属于浪费时间。
针对这种需求，其实很简单，因为需求本身不复杂，只需要分析人员给大家稍微做下介绍，就可以由团队一起帮其做评估，而且不会花费太多时间。因此建议即使是小的需求，也务必采用团队估算的方式。
估算的时间点：
故事点估算可以发生开发过程中的任何时间，但不是说没有准入条件，要做到一个比较准确的故事点估算，需要团队预备以下条件：
需求基本已经定稿，团队对于需求本身，以及实现的方案的理解，至少达到了80%的程度。
有些团队对于开发模块比较熟悉，这样的团队能力水平较高，在需求讲解完成的后，立即可以对需求进行估算。但有些团队模块熟悉程度不高，或者团队成员能力较差，并不能在需求讲解后马上进行故事点估算，还取决于对需求的分析程度。对于这样的团队，我们一般在需求分析初稿完成之后进行。也就意味着通过对需求的了解，代码的分析之后，实现方案基本已经敲定，因此此时的估算才稍微准确一些。
团队估算是否需要全员参与？
对于估算是否全员参与，个人认为还是看情况，因为这涉及到一个收益和成本的问题。
有些团队把估算的过程，和需求讲解的过程结合在一起，这种情况下建议由团队全员参与，先决条件是团队能力较强。相反有些团队为了避免新手开发在估算中无法给出较准确的值，把估算的过程安排在一部分具备分析能力的团队成员间进行，这些人相当于团队的专家小组进行高效估算。在各个团队，情况都不一样，选择的方案也不一样。当然在版本压力不大，大家学有余力的情况下，全员参与是有必要的。
