关于UserStory故事点的一点疑问，
按照标准定义团队评估故事点，主要包括3层含义：
1 工作量（开发时长）
2 难易程度
3 风险（比如技术不熟悉，方法不确定等）
而实际情况，一般都演化为一个故事完成需要的时长，并且也能随着时间推移迭代速率是趋于稳定。
疑问：这种方式是否是正确的方向？
2018.11.7 补充
观察团队估算过程，总结了下“换算”故事点的过程：
当PO讲解完User Story后
A:I have a “pen”（基准故事，一般是故事点为1的故事）
A: I have a “apple”（PO刚讲完的新故事）
（内心独白：我上次做pen好像用户了3个小时，这个apple看起来比pen长，那就加1个点吧，不对，这次apple还得改ui设计，那再加2个点，这次合作的前台or后台貌似新生，估计坑比较多，那再加点吧……）
A: Ah! Apple pen!=8个点
2018.12.10 补充
故事点估算是一个工具，“迫使”参与计划会的人员思考PO传递的故事，“迫使”与自己已经做过的任务进行比较，进而深入思考即将做的这个user story的可行性和复杂性。
