课后有同学，对于故事点和持续时间，不是特别理解，所以我就写了点东西，供大家参考！
最开始，我们那个小团队，用的是敏捷开发（但是没有用类似jira这种系统，只是在开发的时候借鉴了敏捷的思想，在管理需求上，还是使用excel）
由于大部分产品经理不是研发出身，所以并不能评估确切的开发时间，其实即便是研发出身，也很难给出确切的时间节点，而即便是给，研发也往多了说，比如，2天能做完的，研发往往会说，这个东西，得3到4天。
为什么会有“
往多了说”
这种情况呢！其实不是研发“
磨洋工”，在我接触的这些工程师中，绝大多数人，都是非常非常实在的，自己的工作做完了，主动要任务（往事不堪回首 ，
在我刚做产品经理那阵，经常出现，我规划的速度赶不上研发的开发速度
），之所以往多了说，其实大部分原因是
，
软件产品具备不确定性
，
尤其是业务比较复杂，或者/并且产品经理需求梳理的不清楚的情况
。所以针对于这样的问题，研发为了保证有充足的时间重构代码/修复bug/应对产品经理临时改需求…… 往往是“往多了说”。
企业，为了人尽其用 / 更加精准的监测项目开发进度 / 增加开发的效率 ……等诸如因素吧，就引入了敏捷开发（故事点自然也包含在其中）。
其实所谓的故事点，就是产品经理站在用户的角度，去讲“故事”。确切的说就是讲需求。
1、国内某大型教育培训集团，在原业务基础上，重新设计新信息系统，涉及到>财务管理-总部、财务管理（分校-财务）、学籍查询、考勤管理、班级管理（分校-班主任、教质经理）、班级管理（总部-教务）、价格体系管理（总部）、产品体系管理（总部-产品总监）、分期管理（总部-市场总监）、校区管理（总部-信息专员）、报名管理（分校-咨询、班主任）、讲师管理（分校-教质经理）、讲师管理（总部-教务）、POS机管理（总部-财务）、优惠管理（总部-市场总监）等业务模块。
2、
公司在工作群发布消息：
周五下午4点开会，此次开会集中评估，下次迭代涉及到的xx
个故事点，请相
关负责人提前准备
。
3、
参会人员有：
研发部门经理（李总
）、技术经理（闫哥
），后端工程师（小明，大喜
），前端工程师（小慧），测试工程师（老冯
及助手小影）产品经理（大饼，小霞，老郭
）
1、由于此次会议，评估的故事点较多，我下面以通用价格管理为例
2、用户故事：作为产品研发部的总监，我想对通用价格进行管理
3、
故事描述：
通用价格的数据展示，导出数据，通用价格的调价功能，调价的记录
故事点评估：
1、产品经理先讲一遍“故事”，对于那些较为复杂的“故事”，可辅助原型，架构图，流程图……然后团队发表意见，小问题会议结束后，产品经理自行优化，方案没大问题，则开始评估故事点。
2、玩法有很多，我们当时采取的是，团队成员举牌（认为值几个故事点，就写几个，不能交头接耳，要全凭自己感觉）不能交头接耳这一点很重要。
3、去除最高的故事点，去除最低的故事点，举最高和最低的人，要站起来说一说自己的理由。这样做的好处是，1、研发就不敢往多说了（发明敏捷开发的真是个天才）2、举最低的人，要么是工作效率极高，要么是对项目/技术点认知不足
4、假设，价格体系管理这个故事点，最终团队投票表决是个4故事点（4个故事点，赞成的人数多，假设大家无异议），后期在开发的时候，研发花了2个工作日完成了4个故事点，那么2个工作日，就是持续时间。这样我们就可以得出一个大致结论，单个故事点的持续时间是，2/4 =0.5天
5、好！咱们再假设，后面你又评估了一个需求，这个需求的故事点是9，研发花了 3个工作日做完，那么单个故事点的持续时间就是 3/9=0.3天
6、以此类推后面，我们就可以用( 0.5+0.3+X3+X4+X5+……+XN)/N 得到一个平均数，这个平均数就是 单个故事点的持续时间（数据越多，这个平均值是就越有参考价值）
结论：
这样，当团队联手做了1~N个完整的项目之后， 我们就会根据一大堆历史数据，推算出一个相对比较准确的单个故事点的持续时间（所以说敏捷开发这件事，需要团队之间有较长的磨合时间，要不然，估算单个故事点的持续时间不准确）。
后续，产品经理描述完一个需求之后，比如，大体估算是20个故事点，那我们就可以根据以往的经验，知道要完成这20个故事点需求花费多长时间了，
这就是为什么，即便是咱们产品经理不懂技术，但是根据工作经验，我们也可以大体估算出，完成一个功能/页面需要花费多久的原因了
但是这个时间，仅限于当前开发团队，拿到其他团队里面，可能就不适用了，所以我在录课的时候才说，产品经理没有项目经理/技术经理的配合是很难把控项目开发进度的。
